Minor rpc question ....
William A. Mahaffey III
wam at hiwaay.net
Mon Nov 3 19:42:03 UTC 2014
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" <wam at hiwaay.net> 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 at 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 at kabini1, /etc, 4:34:03pm] 369 %
>
> > > [root at 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 at kabini1, /etc, 4:38:26pm] 337 %
> > >
> > > [wam at 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 at 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 at 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 at 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.
More information about the freebsd-questions
mailing list