ipfw question

Fri Jul 1 13:44:06 UTC 2016

On 07/01/16 08:30, Ian Smith wrote:
> 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 at 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 at 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 :)

Absolutely correct, modified from box-stock workstation rules. From my 
rc.conf:

[root at 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"
[root at kabini1, /etc, 8:46:53am] 472 %

>
>   > ). 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 at 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 ..

Hmmmm .... OK, glad I asked :-/ ....

>
> 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 at 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 ..

10-4, wilco.

>
>   > [root at 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

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.