Discussion:
ipfw question
(too old to reply)
William A. Mahaffey III
1970-01-01 00:00:00 UTC
Permalink
I had an oddball occurence this A.M. I sat down to check E-mails & surf
& found that I couldn't recover any E-mails. I poked around a bit &
found some entries in /var/log/security indicating that traffic from my
DNS server was being dropped by the firewall:


[***@kabini1, ~, 10:04:03am] 587 % tail -20 /var/log/security ; date
May 31 09:18:41 kabini1 last message repeated 6 times
Jun 19 13:23:53 kabini1 kernel: ipfw: 65500 Deny TCP 163.172.131.88:993
192.168.0.27:47277 in via re0
Jun 19 13:23:57 kabini1 last message repeated 4 times
Jun 26 08:34:13 kabini1 kernel: ipfw: 65500 Deny TCP 212.47.233.86:9001
192.168.0.27:28210 in via re0
Jun 26 08:34:17 kabini1 last message repeated 4 times
Jun 26 09:23:39 kabini1 kernel: ipfw: 65500 Deny TCP 193.0.6.135:43
192.168.0.27:60843 in via re0
Jun 26 09:23:42 kabini1 last message repeated 3 times
Jun 27 09:47:14 kabini1 kernel: ipfw: 65500 Deny TCP 212.47.233.86:9001
192.168.0.27:54688 in via re0
Jun 27 09:47:18 kabini1 last message repeated 4 times
Jun 27 11:55:17 kabini1 kernel: ipfw: 65500 Deny TCP 212.47.233.86:9001
192.168.0.27:45670 in via re0
Jun 27 11:55:21 kabini1 last message repeated 4 times
Jun 30 08:24:04 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53
192.168.0.27:46927 in via re0
Jun 30 08:25:30 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53
192.168.0.27:44681 in via re0
Jun 30 08:25:32 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53
192.168.0.27:29687 in via re0
Jun 30 08:27:20 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53
192.168.0.27:51623 in via re0
Jun 30 08:34:56 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53
192.168.0.27:46764 in via re0
Jun 30 08:34:57 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53
192.168.0.27:24172 in via re0
Jun 30 08:48:04 kabini1 kernel: ipfw: 65500 Deny TCP 163.172.131.88:993
192.168.0.27:42869 in via re0
Jun 30 08:48:46 kabini1 last message repeated 17 times
Jun 30 08:50:41 kabini1 last message repeated 5 times
Thu Jun 30 10:04:07 MCDT 2016
[***@kabini1, ~, 10:04:07am] 588 %

I haven't made any changes to my firewall setup in months, maybe a year
or more (so long that I found I had forgotten what to do initially :-/
). I eventually recalled where to tweak & added a line to my rc.fiewwall
file & restarted ipfw. It spit out all rules, including my new one,
which implied that I hadn't botched the syntax. E-mail went back to
working & all is well. However, I want to make sure I didn't open up
more than I think I am. My rule list as echoed out from the restart is
below:

[***@kabini1, /etc, 8:52:59am] 467 % service ipfw restart
net.inet.ip.fw.enable: 1 -> 0
net.inet6.ip6.fw.enable: 1 -> 0
Flushed all rules.
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00400 deny ip from any to ::1
00500 deny ip from ::1 to any
00600 allow ipv6-icmp from :: to ff02::/16
00700 allow ipv6-icmp from fe80::/10 to fe80::/10
00800 allow ipv6-icmp from fe80::/10 to ff02::/16
00900 allow ipv6-icmp from any to any ip6 icmp6types 1
01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
01100 check-state
01200 allow tcp from me to any established
01300 allow tcp from me to any setup keep-state
01400 allow udp from me to any keep-state
01500 allow icmp from me to any keep-state
01600 allow ipv6-icmp from me to any keep-state
01700 allow udp from 0.0.0.0 68 to 255.255.255.255 dst-port 67 out
01800 allow udp from any 67 to me dst-port 68 in
01900 allow udp from any 67 to 255.255.255.255 dst-port 68 in
02000 allow udp from fe80::/10 to me dst-port 546 in
02100 allow udp from any 53 to me in # <-------- my new
rule !!!!
02200 allow icmp from any to me icmptypes 8
02300 allow ipv6-icmp from any to any ip6 icmp6types 128,129
02400 allow icmp from any to me icmptypes 3,4,11,13
02500 allow ipv6-icmp from any to any ip6 icmp6types 3
02600 allow tcp from 192.168.0.0/24 to me
02700 allow udp from 192.168.0.0/24 to me
02800 allow udp from 192.168.0.0/24 513 to 192.168.0.0/24 dst-port 513
02900 allow udp from 192.168.0.0/24 525 to 192.168.0.0/24 dst-port 525
65000 count ip from any to any
65100 deny { tcp or udp } from any to any dst-port 111,137,138 in
65200 deny { tcp or udp } from 192.168.0.0/24 to me
65300 deny ip from any to 255.255.255.255
65400 deny ip from any to 224.0.0.0/24 in
65500 deny udp from any to any dst-port 520 in
65500 deny tcp from any 80,443 to any dst-port 1024-65535 in
65500 deny log logamount 50000 ip from any to any
Firewall rules loaded.
[***@kabini1, /etc, 8:53:11am] 468 %


with my new rule marked. I noticed that the dropped DNS packets were
destined for oddball ports on my box, so I have no port specification in
my rule. Am I just allowing DNS replies back in, or
(humorously/tragically) more :-) ? This box is my daily driver
workstation desktop, *NOT* a public server, so I want it locked down as
much as possible.


[***@kabini1, /etc, 8:53:11am] 468 % uname -a
FreeBSD kabini1.local 9.3-RELEASE-p33 FreeBSD 9.3-RELEASE-p33 #0: Wed
Jan 13 17:55:39 UTC 2016
***@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
[***@kabini1, /etc, 10:22:42am] 469 %


TIA & have a good one.
--
William A. Mahaffey III

----------------------------------------------------------------------

"The M1 Garand is without doubt the finest implement of war
ever devised by man."
-- Gen. George S. Patton Jr.
Ian Smith
2016-07-01 13:24:24 UTC
Permalink
In freebsd-questions Digest, Vol 630, Issue 5, Message: 2
Post by William A. Mahaffey III
I had an oddball occurence this A.M. I sat down to check E-mails & surf
& found that I couldn't recover any E-mails. I poked around a bit &
found some entries in /var/log/security indicating that traffic from my
[.. omitting unrelated entries ..]
Post by William A. Mahaffey III
Jun 30 08:24:04 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:46927 in via re0
Jun 30 08:25:30 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:44681 in via re0
Jun 30 08:25:32 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:29687 in via re0
Jun 30 08:27:20 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:51623 in via re0
Jun 30 08:34:56 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:46764 in via re0
Jun 30 08:34:57 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:24172 in via re0
This usually indicates that responses from an upstream DNS server are
arriving after the keep-state rule that allowed your DNS request packet
out has since timed out, which usually indicates some perhaps temporary
problem with the link, the upstream server, or the phase of the moon.
Post by William A. Mahaffey III
01400 allow udp from me to any keep-state
Consult ipfw(8) about increasing dynamic rule timeouts, if it's a
regular occurrence. Usually your {mail,web,whatever} client will just
try again .. UDP is not expected to be reliable, by definition.
Post by William A. Mahaffey III
I haven't made any changes to my firewall setup in months, maybe a year
or more (so long that I found I had forgotten what to do initially :-/
I see that it's based on rc.firewall 'workstation' rules, as reference.
Does rc.conf specify firewall_type="workstation" or have you copied that
to custom rules? At first glance it looks stock, but I'm not up for a
line by line comparison :)
Post by William A. Mahaffey III
). I eventually recalled where to tweak & added a line to my rc.fiewwall
file & restarted ipfw. It spit out all rules, including my new one,
which implied that I hadn't botched the syntax. E-mail went back to
working & all is well. However, I want to make sure I didn't open up
more than I think I am. My rule list as echoed out from the restart is
You may have opened up a lot more than you bargained for ..
Post by William A. Mahaffey III
net.inet.ip.fw.enable: 1 -> 0
net.inet6.ip6.fw.enable: 1 -> 0
Flushed all rules.
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00400 deny ip from any to ::1
00500 deny ip from ::1 to any
00600 allow ipv6-icmp from :: to ff02::/16
00700 allow ipv6-icmp from fe80::/10 to fe80::/10
00800 allow ipv6-icmp from fe80::/10 to ff02::/16
00900 allow ipv6-icmp from any to any ip6 icmp6types 1
01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
01100 check-state
01200 allow tcp from me to any established
01300 allow tcp from me to any setup keep-state
01400 allow udp from me to any keep-state
01500 allow icmp from me to any keep-state
01600 allow ipv6-icmp from me to any keep-state
01700 allow udp from 0.0.0.0 68 to 255.255.255.255 dst-port 67 out
01800 allow udp from any 67 to me dst-port 68 in
01900 allow udp from any 67 to 255.255.255.255 dst-port 68 in
02000 allow udp from fe80::/10 to me dst-port 546 in
02100 allow udp from any 53 to me in # <-------- my new rule !!!!
Don't do this! Anyone and his dog can send UDP packets to any UDP port
or service they like on your machine, by (trivially) forging the source
port as 53. Now you've outed this hole publically, best fix it soon ..

Given you're using dynamic rules, the way it was is the correct way to
use external UDP services.
Post by William A. Mahaffey III
02200 allow icmp from any to me icmptypes 8
02300 allow ipv6-icmp from any to any ip6 icmp6types 128,129
02400 allow icmp from any to me icmptypes 3,4,11,13
02500 allow ipv6-icmp from any to any ip6 icmp6types 3
02600 allow tcp from 192.168.0.0/24 to me
02700 allow udp from 192.168.0.0/24 to me
02800 allow udp from 192.168.0.0/24 513 to 192.168.0.0/24 dst-port 513
02900 allow udp from 192.168.0.0/24 525 to 192.168.0.0/24 dst-port 525
65000 count ip from any to any
65100 deny { tcp or udp } from any to any dst-port 111,137,138 in
65200 deny { tcp or udp } from 192.168.0.0/24 to me
65300 deny ip from any to 255.255.255.255
65400 deny ip from any to 224.0.0.0/24 in
65500 deny udp from any to any dst-port 520 in
65500 deny tcp from any 80,443 to any dst-port 1024-65535 in
65500 deny log logamount 50000 ip from any to any
Firewall rules loaded.
with my new rule marked. I noticed that the dropped DNS packets were
destined for oddball ports on my box, so I have no port specification in
my rule. Am I just allowing DNS replies back in, or
(humorously/tragically) more :-) ? This box is my daily driver
workstation desktop, *NOT* a public server, so I want it locked down as
much as possible.
After removing that bogus rule, if you see more of this and increasing
timeouts somewhat doesn't help, try running tcpdump on port 53 to watch
what's happening .. you will see DNS requests from mail pickup, browsing
etc do use 'oddball' high ports; watch 'em go and responses come back ..
Post by William A. Mahaffey III
FreeBSD kabini1.local 9.3-RELEASE-p33 FreeBSD 9.3-RELEASE-p33 #0: Wed
Jan 13 17:55:39 UTC 2016
I'm still running 9.3 too. 6 months to go!

cheers, Ian
William A. Mahaffey III
1970-01-01 00:00:00 UTC
Permalink
Post by Ian Smith
In freebsd-questions Digest, Vol 630, Issue 5, Message: 2
Post by William A. Mahaffey III
I had an oddball occurence this A.M. I sat down to check E-mails & surf
& found that I couldn't recover any E-mails. I poked around a bit &
found some entries in /var/log/security indicating that traffic from my
[.. omitting unrelated entries ..]
Post by William A. Mahaffey III
Jun 30 08:24:04 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:46927 in via re0
Jun 30 08:25:30 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:44681 in via re0
Jun 30 08:25:32 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:29687 in via re0
Jun 30 08:27:20 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:51623 in via re0
Jun 30 08:34:56 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:46764 in via re0
Jun 30 08:34:57 kabini1 kernel: ipfw: 65500 Deny UDP 209.244.0.3:53 192.168.0.27:24172 in via re0
This usually indicates that responses from an upstream DNS server are
arriving after the keep-state rule that allowed your DNS request packet
out has since timed out, which usually indicates some perhaps temporary
problem with the link, the upstream server, or the phase of the moon.
Post by William A. Mahaffey III
01400 allow udp from me to any keep-state
Consult ipfw(8) about increasing dynamic rule timeouts, if it's a
regular occurrence. Usually your {mail,web,whatever} client will just
try again .. UDP is not expected to be reliable, by definition.
Post by William A. Mahaffey III
I haven't made any changes to my firewall setup in months, maybe a year
or more (so long that I found I had forgotten what to do initially :-/
I see that it's based on rc.firewall 'workstation' rules, as reference.
Does rc.conf specify firewall_type="workstation" or have you copied that
to custom rules? At first glance it looks stock, but I'm not up for a
line by line comparison :)
Absolutely correct, modified from box-stock workstation rules. From my
rc.conf:


[***@kabini1, /etc, 8:43:43am] 471 % grep -i firewall rc.conf
firewall_enable="YES"
firewall_type="workstation"
firewall_quiet="NO"
firewall_logdeny="YES"
# firewall_nologports="111,137,138,513"
firewall_nologports="111,137,138"
firewall_allowservices="192.168.0.0/24"
firewall_myservices="any"
# firewall_myservices="nfs,111,513,550,lockd,quotad,ssh,ntp,timed,new-rwho"
# firewall_myservices="nfs,lock,quota,ssh,ntp,timed,new-rwho"
# firewall_myservices="nfsd,lockd,quota,ssh,ntp,timed,new-rwho"
Post by Ian Smith
Post by William A. Mahaffey III
). I eventually recalled where to tweak & added a line to my rc.fiewwall
file & restarted ipfw. It spit out all rules, including my new one,
which implied that I hadn't botched the syntax. E-mail went back to
working & all is well. However, I want to make sure I didn't open up
more than I think I am. My rule list as echoed out from the restart is
You may have opened up a lot more than you bargained for ..
Post by William A. Mahaffey III
net.inet.ip.fw.enable: 1 -> 0
net.inet6.ip6.fw.enable: 1 -> 0
Flushed all rules.
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00400 deny ip from any to ::1
00500 deny ip from ::1 to any
00600 allow ipv6-icmp from :: to ff02::/16
00700 allow ipv6-icmp from fe80::/10 to fe80::/10
00800 allow ipv6-icmp from fe80::/10 to ff02::/16
00900 allow ipv6-icmp from any to any ip6 icmp6types 1
01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
01100 check-state
01200 allow tcp from me to any established
01300 allow tcp from me to any setup keep-state
01400 allow udp from me to any keep-state
01500 allow icmp from me to any keep-state
01600 allow ipv6-icmp from me to any keep-state
01700 allow udp from 0.0.0.0 68 to 255.255.255.255 dst-port 67 out
01800 allow udp from any 67 to me dst-port 68 in
01900 allow udp from any 67 to 255.255.255.255 dst-port 68 in
02000 allow udp from fe80::/10 to me dst-port 546 in
02100 allow udp from any 53 to me in # <-------- my new rule !!!!
Don't do this! Anyone and his dog can send UDP packets to any UDP port
or service they like on your machine, by (trivially) forging the source
port as 53. Now you've outed this hole publically, best fix it soon ..
Hmmmm .... OK, glad I asked :-/ ....
Post by Ian Smith
Given you're using dynamic rules, the way it was is the correct way to
use external UDP services.
Post by William A. Mahaffey III
02200 allow icmp from any to me icmptypes 8
02300 allow ipv6-icmp from any to any ip6 icmp6types 128,129
02400 allow icmp from any to me icmptypes 3,4,11,13
02500 allow ipv6-icmp from any to any ip6 icmp6types 3
02600 allow tcp from 192.168.0.0/24 to me
02700 allow udp from 192.168.0.0/24 to me
02800 allow udp from 192.168.0.0/24 513 to 192.168.0.0/24 dst-port 513
02900 allow udp from 192.168.0.0/24 525 to 192.168.0.0/24 dst-port 525
65000 count ip from any to any
65100 deny { tcp or udp } from any to any dst-port 111,137,138 in
65200 deny { tcp or udp } from 192.168.0.0/24 to me
65300 deny ip from any to 255.255.255.255
65400 deny ip from any to 224.0.0.0/24 in
65500 deny udp from any to any dst-port 520 in
65500 deny tcp from any 80,443 to any dst-port 1024-65535 in
65500 deny log logamount 50000 ip from any to any
Firewall rules loaded.
with my new rule marked. I noticed that the dropped DNS packets were
destined for oddball ports on my box, so I have no port specification in
my rule. Am I just allowing DNS replies back in, or
(humorously/tragically) more :-) ? This box is my daily driver
workstation desktop, *NOT* a public server, so I want it locked down as
much as possible.
After removing that bogus rule, if you see more of this and increasing
timeouts somewhat doesn't help, try running tcpdump on port 53 to watch
what's happening .. you will see DNS requests from mail pickup, browsing
etc do use 'oddball' high ports; watch 'em go and responses come back ..
10-4, wilco.
Post by Ian Smith
Post by William A. Mahaffey III
FreeBSD kabini1.local 9.3-RELEASE-p33 FreeBSD 9.3-RELEASE-p33 #0: Wed
Jan 13 17:55:39 UTC 2016
I'm still running 9.3 too. 6 months to go!
cheers, Ian
Yeah, too bad, I do like 9.3, feelin' like old leather by now :-/ ....
--
William A. Mahaffey III

----------------------------------------------------------------------

"The M1 Garand is without doubt the finest implement of war
ever devised by man."
-- Gen. George S. Patton Jr.
Loading...