[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Iptables

>> I try to authorize the host to connect to samba  but the
>> server host won't let me with the following statement :
>> ************************************************************************
>> iptables -A INPUT -i eth0 -p udp -s -d
>> --dport 137 -j ACCEPT
>> iptables -A INPUT -i eth0 -p udp -s -d
>> --dport 138 -j ACCEPT
>> iptables -A INPUT -i eth0 -m state --state NEW,ESTABLISHED -p tcp -s
>> -d --dport 139 -j ACCEPT
>> iptables -A INPUT -i eth0 -m state --state NEW,ESTABLISHED -p tcp -s
>> -d --dport 445 -j ACCEPT
>> ************************************************************************
>> So I enabled the CIFS profile in UFW, which is more permissive and does
>> work (yes the whole SAMBA configuration is.. :) ). But I'd like to make
>> those iptables rules work as they are more efficient.
>> Any clue ?
> I don't know Samba ports very well, but I would try to use the RELATED
> state ; if, as I guess, connections on ports 139 and 445 are made after
> others on ports 137 and 138, the RELATED state must be used instead of
> the NEW state. In fact, using --state NEW-ESTABLISHED is useless,
> because these cumulated states will match every connection on ports 139
> and 445, as TCP packets are always in an ESTABLISHED connection, except
> the first one which will be NEW.
> That said, maybe this filter is too strict ; maybe you only need to get
> these ports opened ; in addition, did you also opened ports for output
> packets ? That can seem silly, but one can easily forget them without
> noting.
> Besides, /32 masks can be omitted in your rules ; without mask, /32
> is assumed and I think this should make your commands more readable

I modified in consequence. See below.

> Clues, sure. It probably doesn't matter but establishing state in the
> middle of your rules looks weird.

Why weird ?

> Second, don't silently drop stuff -
> make a log and drop chain. Last (probably your issue) is you're
> filtering out broadcasts. But if you log your drops, that'll be very
> apparent

It seems that with those modifications made, and a few rebooting (??),
the rules now apply and function. I did put a "log and drop" feature at
the end of the INPUT chain and place the same at the end of the OUTPUT
one. I saw somewhere that I could manage the flow with the limit module.

The rules :

# Allow incomings for SAMBA
iptables -A INPUT -i eth0 -m udp -p udp -s -d
--dport 137 -j ACCEPT
iptables -A INPUT -i eth0 -m udp -p udp -s -d
--dport 138 -j ACCEPT
iptables -A INPUT -i eth0 -m tcp -p tcp -s -d
--dport 139 -m state --state RELATED -j ACCEPT
iptables -A INPUT -i eth0 -m tcp -p tcp -s -d
--dport 445 -m state --state RELATED -j ACCEPT

# LOG AND DROP for INPUT chain
iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -j LOG --log-prefix "INPUT-DROPPED :  " --log-level 7
iptables -A LOGGING -j DROP

> Please don't hijack an existing thread when you open a new topic. You
> have done this twice on this thread which was originally titled
> "Resizing LVM issue".

I didn't or at least not on purpose. I just reply to the list on a
random message and make a new topic of it for light convenience. I
didn't know it could do any harm. And actually, I even don't understand
how you can know that ? Please explain, I will sleep a bit light less
dumber tonight. ;)

Thanks to all for stopping by. :)
“One original thought is worth a thousand mindless quotings.”
“Le vrai n'est pas plus sûr que le probable.”

                                              Diogene Laerce

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: