From owner-freebsd-questions@FreeBSD.ORG Mon Nov 3 19:42:03 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDF2CBEA for ; Mon, 3 Nov 2014 19:42:02 +0000 (UTC) Received: from fly.hiwaay.net (fly.hiwaay.net [216.180.54.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8A5BFA0 for ; Mon, 3 Nov 2014 19:42:02 +0000 (UTC) Received: from kabini1.local (rbn1-216-180-19-112.adsl.hiwaay.net [216.180.19.112]) (authenticated bits=0) by fly.hiwaay.net (8.13.8/8.13.8/fly) with ESMTP id sA3Jg06f027656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 3 Nov 2014 13:42:01 -0600 Message-ID: <5457DC00.50108@hiwaay.net> Date: Mon, 03 Nov 2014 13:48:16 -0600 From: "William A. Mahaffey III" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: freebsd-questions@freebsd.org Subject: Re: Minor rpc question .... References: <20141104020556.J52402@sola.nimnet.asn.au> In-Reply-To: <20141104020556.J52402@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 19:42:03 -0000 On 11/03/14 11:25, Ian Smith wrote: > In freebsd-questions Digest, Vol 544, Issue 1, Message: 7 > On Sun, 02 Nov 2014 17:06:22 -0600 "William A. Mahaffey III" wrote: > > On 11/02/14 16:43, William A. Mahaffey III wrote: > > > On 11/02/14 11:12, Ian Smith wrote: > > >> William, I've just seen your response at > > >> http://lists.freebsd.org/pipermail/freebsd-questions/2014-November/262026.html > > >> > > >> but as I take questions@ as a digest, I won't get it here till tomorrow > > >> .. I should have asked you to cc me. > > Just got here. If you (or anyone) do respond to this, please cc me! > > Some spring pruning: > > > >> > 02500 18777 23476935 allow tcp from 192.168.0.0/16 to me > > >> > 65000 1795 424041 count ip from any to any > > >> > 65100 1371 269257 deny { tcp or udp } from any to any > > >> dst-port 111,137,138,513 in > > >> > > >> > w/ port 513 obviously being denied. However, I don't know where that > > >> > is happening :-/ & I thought rule 02500 would let all local traffic > > >> > through .... > > > >> Rule 2500 only allows tcp, rwho is udp - but 2500 is a bit sweeping > > >> anyway, perhaps best to enable specific services, even internally? > > >> > > >> Ah, yes - I see firewall_myservices and firewall_allowservices are only > > >> for TCP services. That's a strange omission, if I'm reading it right, > > >> especially re rpc. > > Well, well .. while browsing freebsd-current@ archives earlier, looking > for something else entirely, I came across this PR with commit to HEAD: > > Bug 194292 - Patch for adding firewall_myservices_tcp and > firewall_myservices_udp support to rc.conf: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194292 > > > >> Rather than fixing this properly now for UDP services, I'd just add into > > >> /etc/rc.firewall after what's now your 2500 or at any rate before 65000: > > >> > > >> ${fwcmd} allow udp from ${mynetwork} 513 to me 513 > > Turns out 'me' was an unfortunate choice for this service, see below .. > > > >> You're already enabling udp services outbound, statefully, which is why > > >> you can query other hosts. Now they'll be able to reach you too :) > > >> > > >> 'service ipfw restart' and you should be good to go. You could remove > > >> 513 from firewall_nologports - but now it'll already be passed by then. > > > > Well, I put that rule in & opened logging for that port & now I get > > > ruptime info from other boxen, however, I also get log traffic about > > > denied port 513 traffic: > > > > > > [root@kabini1, /etc, 4:34:01pm] 368 % 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 > [.. as before ..] > > > 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 > [..] > > > 02500 allow tcp from 192.168.0.0/16 to me > > > 02600 allow udp from 192.168.0.0/24 513 to me dst-port 513 > [..] > > > 65500 deny log logamount 5000 ip from any to any > > > Firewall rules loaded. > > > [root@kabini1, /etc, 4:34:03pm] 369 % > > > > [root@kabini1, /etc, 4:37:13pm] 337 % ( tail -20 /var/log/security ; > > > date ) > > > Oct 30 11:00:00 kabini1 newsyslog[9861]: logfile turned over due to > > > size>100K > > > Oct 30 11:00:30 kabini1 kernel: ipfw: 65500 Deny UDP > > > 92.108.103.99:58507 192.168.0.27:63167 in via re0 > > > Oct 30 11:00:49 kabini1 kernel: ipfw: 65500 Deny P:2 192.168.0.27 > > > 224.0.0.22 out via re0 > > > Oct 30 11:00:52 kabini1 kernel: ipfw: 65500 Deny P:2 192.168.0.27 > > > 224.0.0.22 out via re0 > > Your box tries talking IGMP (see /etc/protocols) to a multicast port: > igmp 2 IGMP # internet group management protocol > I know nothing about IGMP, but see there's nothing here to permit it. > > > > Oct 30 11:01:16 kabini1 kernel: ipfw: 65500 Deny UDP 126.43.5.41:6881 > > > 192.168.0.27:63167 in via re0 > > Torrents, eh? You'll need rule/s allowing that, assuming you offer > inbound connections and that your upstream NAT router is forwarding a > chosen port to you. I had to do this for my daughter not long ago :) > and in 'workstation' it's another service - UDP and perhaps TCP too? - > that you'll need to allow inbound .. unicast, so 'me' would be ok. > > [.. more IGMP ..] > > > > Oct 31 10:16:03 kabini1 kernel: ipfw: 65500 Deny UDP 216.180.99.2:53 > > > 192.168.0.27:28277 in via re0 > > Likely a late response to a DNS query, not uncommon. You can adjust the > dynamic timeouts by sysctls if need be, see ipfw(8); the default for > net.inet.ip.fw.dyn_udp_lifetime=5 seconds, often insufficient for DNS. > > > > Nov 2 16:31:12 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.4:513 > > > 192.168.0.255:513 in via re0 > > > Nov 2 16:32:25 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.9:513 > > > 192.168.0.255:513 in via re0 > > > Nov 2 16:32:28 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.7:513 > > > 192.168.0.255:513 in via re0 > > > Nov 2 16:34:12 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.4:513 > > > 192.168.0.255:513 in via re0 > > > Nov 2 16:35:25 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.9:513 > > > 192.168.0.255:513 in via re0 > > > Nov 2 16:35:28 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.7:513 > > > 192.168.0.255:513 in via re0 > > > Nov 2 16:37:12 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.4:513 > > > 192.168.0.255:513 in via re0 > > > Nov 2 16:38:25 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.9:513 > > > 192.168.0.255:513 in via re0 > > Right .. all of these are to 192.168.0.255, the broadcast address for > that /24. 'me' is defined as any address configured on an interface on > the system .. so apparently 'me' doesn't include the broadcast address, > assuming ifconfig shows you have re0 configured as 192.168.0.27/24 with > that broadcast address? > > > > Sun Nov 2 16:38:26 CST 2014 > > > [root@kabini1, /etc, 4:38:26pm] 337 % > > > > > > [wam@kabini1, ~, 9:03:43am] 330 % ruptime -a > > > Q6600 up 299+08:00, 6 users, load 0.03, > > > 0.04, 0.05 > > > athloncube up 45+21:08, 4 users, load 0.00, > > > 0.01, 0.05 > > > kabini1 up 23:01, 1 user, load 0.35, > > > 0.19, 0.10 > > > opty165a up 299+08:00, 4 users, load 0.00, > > > 0.00, 0.00 > > > [wam@kabini1, ~, 4:34:49pm] 330 % ruptime > > > Q6600 down 0:13 > > > athloncube down 0:14 > > > kabini1 up 23:07, 0 users, load 0.21, > > > 0.26, 0.16 > > > opty165a down 0:13 > > > [wam@kabini1, ~, 4:41:57pm] 331 % ruptime -a > > > Q6600 down 0:13 > > > athloncube down 0:14 > > > kabini1 up 23:07, 1 user, load 0.21, > > > 0.26, 0.16 > > > opty165a down 0:13 > > > [wam@kabini1, ~, 4:42:03pm] 332 % > > > > > > > > > err, well, I had it for a second :-/ .... > > I think your outbound queries (yes, to 192.168.0.255) got responses due > to the stateful UDP rule at 1400, but later, when you weren't querying > directly, other systems' broadcast queries were not being allowed in. > > > Sooooo tacky to self reply, but it seems warranted here. Using the ipfw > > command: > > > > ${fwcmd} add pass udp from 192.168.0.0/24 513 to 192.168.0.0/24 513 > > > > gets ruptime traffic in/out *and* cuts out extraneous logging .... Just > > for posterity :-) .... > > Yes that does it, because it allows packets in to the broadcast address. > Sorry I misled you with that 'me' rule; I didn't consider broadcasts, > even while knowing that's how rwhod has always worked :) I've rarely > used 'me', preferring to use specific addresses (including broadcast) > > cheers, Ian > No worries, you put me on the right track, so Thanks !!!! :-) .... -- William A. Mahaffey III ---------------------------------------------------------------------- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr.