>> I try to authorize the 192.168.0.2 host to connect to samba but the
>> server host 192.168.0.1 won't let me with the following statement :
>>
>> ************************************************************************
>>
>> iptables -A INPUT -i eth0 -p udp -s 192.168.0.2/32 -d 192.168.0.1
>> --dport 137 -j ACCEPT
>> iptables -A INPUT -i eth0 -p udp -s 192.168.0.2/32 -d 192.168.0.1
>> --dport 138 -j ACCEPT
>> iptables -A INPUT -i eth0 -m state --state NEW,ESTABLISHED -p tcp -s
>> 192.168.0.2/32 -d 192.168.0.1 --dport 139 -j ACCEPT
>> iptables -A INPUT -i eth0 -m state --state NEW,ESTABLISHED -p tcp -s
>> 192.168.0.2/32 -d 192.168.0.1 --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 192.168.0.11 -d 192.168.0.10
--dport 137 -j ACCEPT
iptables -A INPUT -i eth0 -m udp -p udp -s 192.168.0.11 -d 192.168.0.10
--dport 138 -j ACCEPT
iptables -A INPUT -i eth0 -m tcp -p tcp -s 192.168.0.11 -d 192.168.0.10
--dport 139 -m state --state RELATED -j ACCEPT
iptables -A INPUT -i eth0 -m tcp -p tcp -s 192.168.0.11 -d 192.168.0.10
--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