Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 03 Nov 2014 13:48:16 -0600
From:      "William A. Mahaffey III" <wam@hiwaay.net>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Minor rpc question ....
Message-ID:  <5457DC00.50108@hiwaay.net>
In-Reply-To: <20141104020556.J52402@sola.nimnet.asn.au>
References:  <mailman.73.1415016001.56588.freebsd-questions@freebsd.org> <20141104020556.J52402@sola.nimnet.asn.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5457DC00.50108>