conntrack for samba/netbios-ns

conntrack for samba/netbios-ns

[Goetz Bock]

Dear list,

as googeling did not turn up anything nor did a browsing through the
lists archive turn up anything usefull, I'll just have to ask.

I'm running (well tried to) a very restricted samba server using the
excelente fireHOL firewalling script. I allow pc1 (a.b.c.17) to connect
to the samba server on pc2 (a.b.c.24), everything happens in a /27
subnet (e.g. a.b.c.31 is broadcast).

It produces some rules, and the relevant lines are:

> # Setting up rules for SAMBA/NETBIOS-NS (server)
> /sbin/iptables -t filter -A in_internet_samba_s2 -p udp -s pc1 --sport netbios-ns --dport netbios-ns -m state --state NEW\,ESTABLISHED -j ACCEPT
> /sbin/iptables -t filter -A in_internet_samba_s2 -p udp -s pc1 --sport 1024:65535 --dport netbios-ns -m state --state NEW\,ESTABLISHED -j ACCEPT
> /sbin/iptables -t filter -A out_internet_samba_s2 -p udp --sport netbios-ns -d pc1 --dport netbios-ns -m state --state ESTABLISHED -j ACCEPT
> /sbin/iptables -t filter -A out_internet_samba_s2 -p udp --sport netbios-ns -d pc1 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

further down all RELATED traffic is allowed. but that's basically it
(well, ssh and dns are allowed, too)


Without a firewall a connection attemp looks like this:

> 01:10:18.364212 a.b.c.17.32769 > a.b.c.31.netbios-ns: ...
> 01:10:18.364637 a.b.c.24.netbios-ns > a.b.c.17.32769: ...
> 01:10:18.673435 a.b.c.17.32781 > a.b.c.24.netbios-ssn: ...

so pc1 looks for the samba server using broadcasts, and pc2 replies.
Than pc1 talks to netbios-ssn and everything is fine.

With the firewall the following happens:

> 01:18:44.850282 a.b.c.17.32769 > a.b.c.31.netbios-ns: ...
> 01:18:45.159103 a.b.c.17.32769 > a.b.c.31.netbios-ns: ...
> 01:18:45.459074 a.b.c.17.32769 > a.b.c.31.netbios-ns: ...

at the same time dmesg logs:

> OUT-server:IN= OUT=eth1 SRC=a.b.c.24 DST=a.b.c.17 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=32769 LEN=70
> OUT-server:IN= OUT=eth1 SRC=a.b.c.24 DST=a.b.c.17 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=32769 LEN=70
> OUT-server:IN= OUT=eth1 SRC=a.b.c.24 DST=a.b.c.17 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=32769 LEN=70

It looks like if the conntacking modules (all from stock 2.4.22) are not
ablel to relate the reply a.b.c.24.netbios-ns > a.b.c.17.32769 to the
request a.b.c.17.32769 > a.b.c.31.netbios-ns.

Is there a conntrack_netbios-ns or am I doing something wrong?

BTW: I know that this can be fixed by allowing NEW connections from
     pc2:netbios-ns to pc1:<highports>. In this scenario this would be
     basicaly save/sound. But it breaks down if I want to run a simmilar
     strict firewall (and I want to, on pc1 to be exact) on the client.
     Than I would have to allow all incomming connections from port
     netbios-ns to local high ports. And that is not realy desired.
-- 
/"\ Goetz Bock at blacknet dot de  --  secure mobile Linux everNETting
\ /                     (c) 2003 as GNU FDL 1.1
 X   [ 1. Use descriptive subjects - 2. Edit a reply for brevity -  ]
/ \  [ 3. Reply to the list - 4. Read the archive *before* you post ]

Re: conntrack for samba/netbios-ns

[Ted Kaczmarek]

udp is connectionless, not sure where you can get a state on it.
I am actually surprised that the udp lines with state even took
or do they only show up on the script.

Anyone else on the list, is their something I am not aware of?
If udp ports are really tracked, then it would have to be done on the
application layer, is their a module or something I am unaware of?

try dropping the -m state --state NEW, ESTABLISHED

and see what happens.

Leave the suffix -j ACCEPT though :-)

Ted

On Tue, 2003-11-04 at 19:34, Goetz Bock wrote:
> Dear list,
> 
> as googeling did not turn up anything nor did a browsing through the
> lists archive turn up anything usefull, I'll just have to ask.
> 
> I'm running (well tried to) a very restricted samba server using the
> excelente fireHOL firewalling script. I allow pc1 (a.b.c.17) to connect
> to the samba server on pc2 (a.b.c.24), everything happens in a /27
> subnet (e.g. a.b.c.31 is broadcast).
> 
> It produces some rules, and the relevant lines are:
> 
> > # Setting up rules for SAMBA/NETBIOS-NS (server)
> > /sbin/iptables -t filter -A in_internet_samba_s2 -p udp -s pc1 --sport netbios-ns --dport netbios-ns -m state --state NEW\,ESTABLISHED -j ACCEPT
> > /sbin/iptables -t filter -A in_internet_samba_s2 -p udp -s pc1 --sport 1024:65535 --dport netbios-ns -m state --state NEW\,ESTABLISHED -j ACCEPT
> > /sbin/iptables -t filter -A out_internet_samba_s2 -p udp --sport netbios-ns -d pc1 --dport netbios-ns -m state --state ESTABLISHED -j ACCEPT
> > /sbin/iptables -t filter -A out_internet_samba_s2 -p udp --sport netbios-ns -d pc1 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
> 
> further down all RELATED traffic is allowed. but that's basically it
> (well, ssh and dns are allowed, too)
> 
> 
> Without a firewall a connection attemp looks like this:
> 
> > 01:10:18.364212 a.b.c.17.32769 > a.b.c.31.netbios-ns: ...
> > 01:10:18.364637 a.b.c.24.netbios-ns > a.b.c.17.32769: ...
> > 01:10:18.673435 a.b.c.17.32781 > a.b.c.24.netbios-ssn: ...
> 
> so pc1 looks for the samba server using broadcasts, and pc2 replies.
> Than pc1 talks to netbios-ssn and everything is fine.
> 
> With the firewall the following happens:
> 
> > 01:18:44.850282 a.b.c.17.32769 > a.b.c.31.netbios-ns: ...
> > 01:18:45.159103 a.b.c.17.32769 > a.b.c.31.netbios-ns: ...
> > 01:18:45.459074 a.b.c.17.32769 > a.b.c.31.netbios-ns: ...
> 
> at the same time dmesg logs:
> 
> > OUT-server:IN= OUT=eth1 SRC=a.b.c.24 DST=a.b.c.17 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=32769 LEN=70
> > OUT-server:IN= OUT=eth1 SRC=a.b.c.24 DST=a.b.c.17 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=32769 LEN=70
> > OUT-server:IN= OUT=eth1 SRC=a.b.c.24 DST=a.b.c.17 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=32769 LEN=70
> 
> It looks like if the conntacking modules (all from stock 2.4.22) are not
> ablel to relate the reply a.b.c.24.netbios-ns > a.b.c.17.32769 to the
> request a.b.c.17.32769 > a.b.c.31.netbios-ns.
> 
> Is there a conntrack_netbios-ns or am I doing something wrong?
> 
> BTW: I know that this can be fixed by allowing NEW connections from
>      pc2:netbios-ns to pc1:<highports>. In this scenario this would be
>      basicaly save/sound. But it breaks down if I want to run a simmilar
>      strict firewall (and I want to, on pc1 to be exact) on the client.
>      Than I would have to allow all incomming connections from port
>      netbios-ns to local high ports. And that is not realy desired.

Re: conntrack for samba/netbios-ns

[Goetz Bock]

On Tue, Nov 04 '03 at 21:30, Ted Kaczmarek wrote:
> udp is connectionless, not sure where you can get a state on it.
Just because the udp is connectionless, does not mean you can not track
the "state" of a "connection" between two machines.

> I am actually surprised that the udp lines with state even took
> or do they only show up on the script.
Yes they do work. Have a look at /proc/net/ip_conntrack.
-- 
/"\ Goetz Bock at blacknet dot de  --  secure mobile Linux everNETting
\ /                     (c) 2003 as GNU FDL 1.1
 X   [ 1. Use descriptive subjects - 2. Edit a reply for brevity -  ]
/ \  [ 3. Reply to the list - 4. Read the archive *before* you post ]

Re: conntrack for samba/netbios-ns

[Cedric Blancher]

Le mer 05/11/2003 à 03:30, Ted Kaczmarek a écrit :
> udp is connectionless, not sure where you can get a state on it.

Connection <> state

State tracking applies to UDP and is based on timers. See Iptables
Tutorial for UDP state tracking :

http://iptables-tutorial.frozentux.net/chunkyhtml/udpconnections.html

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread! 

Re: conntrack for samba/netbios-ns

[Ted Kaczmarek]

Ah, just like the Checkpoint implementation.
So their is still no state tracking per say, but a hash table
based on SA/port DA/port, and a 180 second timer.

Doesn't 180 seconds seem a tad long?
I kinda vaguely remember Checkpoint default on this being 40 seconds.

I remember being in a discussion with some developers on this and the
consensus was 30 second heartbeats ( strange, they almost always end up
with 30 second heartbeats for everything, hehe ).

Could the developers enlighten me as to why they ended up with 180?
Not a big deal, but it never hurts to learn something :-)

Thanks,
Ted

PS By the way your tutorials are great.

On Wed, 2003-11-05 at 02:23, Cedric Blancher wrote:
> Le mer 05/11/2003 à 03:30, Ted Kaczmarek a écrit :
> > udp is connectionless, not sure where you can get a state on it.
> 
> Connection <> state
> 
> State tracking applies to UDP and is based on timers. See Iptables
> Tutorial for UDP state tracking :
> 
> http://iptables-tutorial.frozentux.net/chunkyhtml/udpconnections.html

Re: conntrack for samba/netbios-ns

[Cedric Blancher]

Le mer 05/11/2003 à 13:30, Ted Kaczmarek a écrit :
> Doesn't 180 seconds seem a tad long?
> I kinda vaguely remember Checkpoint default on this being 40 seconds.

You can tweak all timers using /proc/sys/net/ipv4/netfilter/* settings
introduced by ip_conntrack-proc patch from pom (submitted). See :

http://www.netfilter.org/documentation/pomlist/pom-submitted.html#80_ip_conntrack-proc

PS : haven't tried it yet, so I can't assure UDP timers are available.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread! 

Re: conntrack for samba/netbios-ns

[Chris Brenton]

On Wed, 2003-11-05 at 07:30, Ted Kaczmarek wrote:
>
> Ah, just like the Checkpoint implementation.
> So their is still no state tracking per say, but a hash table
> based on SA/port DA/port, and a 180 second timer.

<shrug> There's not a whole lot else you can do. Its the nature of UDP
as well as many other transports. 

If the UDP based application has a defined header (like DNS), you could
probably tighten this down with string matching, but that would depend
on the app.

> Doesn't 180 seconds seem a tad long?
> I kinda vaguely remember Checkpoint default on this being 40 seconds.

I can't confirm that iptables is 180 seconds for UDP (too lazy to look
it up ;-) but I can tell you that I still see traffic getting blocked
due to state table time outs. The most common occurrence I see is
someone with a slow DNS that posts to a large mailing list. They get
nailed with a flood of queries in order to verify their domain and
sometimes the name server becomes slow to respond. I also see state
table time outs due to slow game servers from time to time.

> I remember being in a discussion with some developers on this and the
> consensus was 30 second heartbeats ( strange, they almost always end up
> with 30 second heartbeats for everything, hehe ).

I doubt _every_ application does this and a firewall should work with
the lowest common denominator. For example I've seen FW-1 and IOS break
large FTP file transfers because the state table times out before the
transfer is complete (thus killing the command session). Netfilter does
not have that problem because it keeps state on established for 5 days.

HTH,
C

Re: conntrack for samba/netbios-ns

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

On Wed, Nov 05, 2003 at 01:34:01AM +0100, Goetz Bock wrote:
> 
> Dear list,
> 
> as googeling did not turn up anything nor did a browsing through the
> lists archive turn up anything usefull, I'll just have to ask.

i think the issue of a smb connection tracking and/or nat module has
already been discussed 2-3 years ago.  It's just that nobody has written
one so far. patches welcome ;)

> It looks like if the conntacking modules (all from stock 2.4.22) are not
> ablel to relate the reply a.b.c.24.netbios-ns > a.b.c.17.32769 to the
> request a.b.c.17.32769 > a.b.c.31.netbios-ns.

no, of course not.  connection tracking can just deal with symmetric
connections (a.b.c.d:e -> v.w.x.y:z and replies v.w.x.y:z ->a.b.c.d:e).
Everything else can only be achieved with connection tracking helpers.

> Is there a conntrack_netbios-ns or am I doing something wrong?

no, as indicated above, nobody has contributed one yet.

> /"\ Goetz Bock at blacknet dot de  --  secure mobile Linux everNETting
-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]