smb browsing broken by firewall

[Charles R. Anderson]

On Mon, Jan 19, 2004 at 10:15:30PM -0800, shane at geeklords.org wrote:
> This is a lot of effort for little/no gain.  A simple iptables 
> rule allowing netbios only from the local broadcast network is 
> just as secure and a lot less complicated/involved.  Granted, what you 

No, it is not as secure.  Stateful firewalls are more secure.  By your
method, we would be reverting to a non-stateful firewall that allows
incoming packets to all ephemeral ports, all the time.  You can't know
ahead of time which ports to open, because they are chosen from the
ip_local_port_range each time a client makes a query.  The netfilter
conntrack modification would also be a general solution to ALL
protocols, not just SMB, for outbound client broadcast/multicast
queries.

> are requesting would theoretically decreased how often port 137 is available 
> for inbound connections (assuming the timeout value is less than the 
> netbios broadcast frequency and that we are dealing with a private lan). 

Port 137 is not the source port that the client uses when making a
query, and queries by the client system only happen when the user
requests such action, i.e. by opening smb:/// in Nautilus, or by using
smbclient.  Perhaps you are confusing the SMB *server* with the
client.  I'm talking about the *client*, i.e. no samba server running. 
Client only systems need not show up in browse lists...

The SMB client sends a udp broadcast from port 32768-61000 (default
ip_local_port_range) to port 137.  Since there are no OUTPUT chain
rules, this goes through fine.  One or more servers on the local LAN
reply to the client, from port 137 to port 32768-61000.  The INPUT
chain needs to accept this reply, or the client doesn't work.  You can
either accept this always for all possible local ports (stateless
firewall) or only accept this in response to a client's initial
outbound query, for the specific ports used in that query (stateful). 

Now do you see why a stateful firewall is more secure?

> However in practice I see this scheme leaving you more exposed, not less 
> as shown by the example below:
> 
> Simple Example:
> 
> I am a hacker and I have cable Internet.  I notice that my localnet is 
> 24.16.80.0 with a subnet mask of 255.255.240.0 (sadly this is my real 
> cable subnet).  I configure and run tcpdump to export the IP 
> addresses of all netbios broadcasts to a file called victim.txt.  I write 
> a simple script to parse this file every second and kick off my 
> exploit program whenever a new victim is found.

You could do the same thing with a unicast protocol and the current
stateful firewall rules by spoofing source IP addresses, especially
combined with ARP spoofing or similar.

> In the above example you just got rooted.  At least with the current 
> netfilter code the end user/sysadmin is required to think about what it is 
> they really want to happen. They can then build firewall rules that 
> reflect their intent.  The solution you propose will only make the 

End users do not build firewall rules.  The current
system-config-securitylevel reflects this thinking.  They expect
*clients* to just work.  If the smb *client* doesn't work in the
default Fedora Core firewall setup, they will just disable the
firewall and open up themselves to attack.  The average end user is
not smart enough to make smart firewall rules to solve this problem in
a secure way.  This is why we must make these rules for them in the
default set up.  Handling outbound client connections automatically
with a stateful firewall is the way to do this.

> above example less visible to the would be victims allowing them to 
> assume that enabling this nifty netbios hack (or worse yet it coming 
> enabled by default) is protecting them, when really all it did was expose 
> them needlessly.

Nonsense.  Security needs to be balanced with convenience and 
functionality.