SEO

I can't seem to find any information regarding pf's default behaviour
regarding broadcasts. If I have a normal NAT:ed private network and the
rule:

pass out on $ext_if from any to any keep state

What will happen with netbios broadcasts for example? pfctl -s state doesn't
list any active states to ports 137 or 139 so I suppose pf drops broadcasts
automatically but I'd really like to know if I need to explicitly block them
or if I can stop worrying...

Regards
PP

"PP" <someone@microsoft.com> writes:

> pass out on $ext_if from any to any keep state
>
> What will happen with netbios broadcasts for example? pfctl -s state doesn't
> list any active states to ports 137 or 139 so I suppose pf drops broadcasts
> automatically but I'd really like to know if I need to explicitly block them
> or if I can stop worrying...

What reaches the external interface at least to some extent depends on
how you filter on the internal interface. If you don't let the netbios
traffic past the internal interface (and assuming you do not run any
netbios traffic generating service on the firewall), you don't need to
worry about it spilling out through the external one.

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"

> What reaches the external interface at least to some extent depends on
> how you filter on the internal interface. If you don't let the netbios
> traffic past the internal interface (and assuming you do not run any
> netbios traffic generating service on the firewall), you don't need to
> worry about it spilling out through the external one.
>

So...

pass all on $int_if

is probably not a good idea then, if I understand you correctly? Does this
mean I'm leaking netbios info to the rest of the world? Shouldn't there be
any states in pf revealing this? Even the sample ruleset in the PF user
guide passes all traffic on the internal interface what I can see and
doesn't mention the need to filter anything. I believe my network setup with
one or more Windows machines on the private network and an OpenBSD firewall
to protect them is not an uncommon setup so any extra steps in the guide to
secure such a setup would be highly appreciated.
However, the various public netbios tests (grc.com for example) claims that
nothing is leaking from my net so I haven't been _that_ concerned so far but
I would really like to understand _why_ netbios doesn't leak or actually see
some rules to block it... I'm confused here.

/PP

Ooops :-P

Just studied my macros more carefully. My $nonroutable contains
255.255.255.255/32... I'm getting old...

/PP

"PP" <someone@microsoft.com> wrote in message
news:9n7Md.129387$dP1.462682@newsc.telia.net...
> Ooops :-P
>
> Just studied my macros more carefully. My $nonroutable contains
> 255.255.255.255/32... I'm getting old...
>
> /PP

The $priv_nets macro in the PF example ruleset however does not so I assume
_that_ ruleset _would_ be leaking netbios, wouldn't it?

http://www.openbsd.org/faq/pf/example1.html#allrules

/PP

On 2005-02-02, PP <someone@microsoft.com> wrote:
> I would really like to understand _why_ netbios doesn't leak or actually see
> some rules to block it... I'm confused here.

I'll ask a question rather than give you the answer directly ... Ignoring
PF for a moment, how would broadcast packets (of any variety) get from the
internal to external interface?

Not so subtle hint: I've got a very large steel structure with a paved flat
surface on top of it I'm willing to sell you.

--
ratfood@food.skaterat.net
All foods should be removed to reply

> I'll ask a question rather than give you the answer directly ... Ignoring
> PF for a moment, how would broadcast packets (of any variety) get from the
> internal to external interface?
>

I'm not an expert in the inner workings of TCP/IP and the only way for me to
learn is to ask stupid questions that hopefully get read by someone willing
to explain it to me.
To me there is really no difference between the address 255.255.255.255 and
any other address outside my private network. I _know_ 255.255.255.255 _is_
different because someone who designed the TCP/IP-stack decided it would be
and the answer to my question is probably that this special address
therefore _is_ handled differently. But right now, with my limited
knowledge, I can't see why a packet destined to 255.255.255.255 would be
treated any differently by my NATing and forwarding OpenBSD router than any
other package destined for an address on the outside of my external
interface. I _do_ understand that a package destined to 192.168.0.255
ofcourse would stay inside my private network and if _this_ is how netbios
broadcasts, well then I have the answer there.
The only reference I have on this particular matter is from my old Netgear
RT314 router which provided the exact same functions. In this router there
_were_ by default several filters applied which removed incoming and
outgoing netbios requests. This is why I assume I need to block the same
traffic in PF. If this assumption is flawed I would appreciate very much to
learn why and if this is something proprietary to OpenBSD or if my Netgear
router implemented NAT and forwarding in an non-standard way.

Kind regards
PP

"PP" <someone@microsoft.com> writes:

> The $priv_nets macro in the PF example ruleset however does not so I assume
> _that_ ruleset _would_ be leaking netbios, wouldn't it?
>
> http://www.openbsd.org/faq/pf/example1.html#allrules

That rule set lets machines on the inside start any connection they
desire to the outside world and receive return traffic (the main use of
'keep state').

Hosts on the outside would as far as I can see not be able to contact
hosts on the inside on any ports other than $tcp_services.

It looks like the PFUG authors had mainly OpenBSD machines in mind

With Microsoft machines on the inside, I would tend to allow outgoing
connections on only a short list of ports.

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"

>> http://www.openbsd.org/faq/pf/example1.html#allrules
>
> That rule set lets machines on the inside start any connection they
> desire to the outside world and receive return traffic (the main use of
> 'keep state').
>

Exactly. And this is where my understanding doesn't suffice. Wouldn't a
broadcast to 255.255.255.255 from a computer on the private net also create
a state in the firewall, effectlively accepting traffic from any outside
computer? Without the "static-port" argument on the NAT rule the mapped port
would of course be different so in the case of netbios it would be difficult
for an outsider to find the way in but _with_ "static-port" it would be
easier assuming a broadcast can create a state.
/PP

> To me there is really no difference between the address 255.255.255.255 and
> any other address outside my private network.

255.255.255.255 is an address, yes. But, without a netmask it is meaningless.


> But right now, with my limited
> knowledge, I can't see why a packet destined to 255.255.255.255 would be
> treated any differently by my NATing and forwarding OpenBSD router than any
> other package destined for an address on the outside of my external
> interface.

The answer is wrapped up in the class differeences between hubs, bridges,
switches, and routers. I say classic because these days the lines
between the various layers and hardware roles are blurred.

By default, most routers (I've worked with) won't transfer broadcast traffic
between their interfaces. Most can be configured to do so. In the case
of OpenBSD, you won't get broadcast traffic forwarded across interfaces
when you have the sysctl net.inet.ip.forwarding enabled unless you've
also configured a bridge (man bridge and brconfig for starters).

Note that an internal computer that attempts to connect to external
windows resources may generate a state in your firewall allowing the
external windows resource to connect back to the internal computer.

Given the large number of exploits associated with windows resources, many
consumer firewalls and home gateways prevent traffic destined to/from
ports associated with windows resources by default. This is the likely
reason your old gateway had such rules.

--
ratfood@food.skaterat.net
All foods should be removed to reply