>> 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
signature.asc
Description: OpenPGP digital signature
