RE: how to configure iptables for samba

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

 




> -----Original Message-----
> From: redhat-list-admin@xxxxxxxxxx
> [mailto:redhat-list-admin@xxxxxxxxxx]On Behalf Of Rick Greep
> Sent: Thursday, January 01, 2004 10:54 AM
> To: Redhat List
> Subject: RE: how to configure iptables for samba
>
> The
> client addresses are defined in the lmhost file.
> 
> > Now that we see why your config is a bad idea, let's figure 
> out why it's
> > not working for you.  I don't use wins queries, so you'll 
> need to review
> > your firewall logs to see what traffic isn't making it 
> through.  Mine
> > works fine.
> > 

Well I think you both have hit the nail right on the head.  You don't
use WINS for name resolution and that is why your suggested configuration
won't work in my environment (I have over a thousand DHCP configured
reasons not to use lmhosts for name resolution).

And, although none of the experts have suggested one, there is a better
way than my insecure suggestion of allowing connections based on a source
port.

So, I'll illustrate two scenarios:

You are trying to connect to a client on a different subnet and you can't
use DNS to resolve his name and you don't have an lmhosts entry for him.
You send a WINS query and the WINS server sends two UDP packets from its port
137 to a random high port on your machine.  These two packets are dropped
according to the suggested rules we've seen so far.

You need to connect to a client on a different subnet.  You know the client's
ip address, but not the netbios name.  You can send a query to the client
using nmblookup but, again, according to rules defined, the client's two
UDP packets sent from port 137 to some random high port are dropped.

So, what do you do to circumvent this?  Do you resort to maintaining static
hosts entries for every machine with which you interact?  Not exactly elegant,
but evidently it can work.

How about a rule based on state, which should (I'm assuming) allow bi-directional
communications?  So somewhere before your drop/reject rules, have:

-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

It works for me.

-- 
S C Rigler
RHCE #803003335409754


-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux