Date: Fri, 1 Jul 2016 23:24:24 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: "William A. Mahaffey III" <wam@hiwaay.net> Cc: freebsd-questions@freebsd.org Subject: Re: ipfw question Message-ID: <20160701223303.S324@sola.nimnet.asn.au> In-Reply-To: <mailman.109.1467374402.76157.freebsd-questions@freebsd.org> References: <mailman.109.1467374402.76157.freebsd-questions@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In freebsd-questions Digest, Vol 630, Issue 5, Message: 2
On Thu, 30 Jun 2016 10:23:54 -0453.75 "William A. Mahaffey III" <wam@hiwaay.net> wrote:
> 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:
>
>
> [root@kabini1, ~, 10:04:03am] 587 % tail -20 /var/log/security ; date
[.. omitting unrelated entries ..]
> 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.
> 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.
> 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 :)
> ). 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:
You may have opened up a lot more than you bargained for ..
> [root@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 !!!!
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.
> 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.
> [root@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.
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 ..
> [root@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
I'm still running 9.3 too. 6 months to go!
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160701223303.S324>