Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've been tearing my hair out trying to get iptables to allow Samba traffic in. My Samba setup is fine, as if I stop iptables, everything works perfectly. From what I've read I need to allow TCP/UDP 137 and 139 in, but I can't work out how to enter it into the table.
I've been using the following, but none seem to work.
iptables -A INPUT -p udp --sport 139 -j ACCEPT (also for tcp and port 137)
also tried
iptables -A INPUT -p udp -s 192.168.0.0/24 - j ACCEPT
I'm making some progress. As far as I can tell 137 and 139 are for file view/access. But some other port is being used for the secure login. I have one PC that was logged in with firewall down and now the firewall is up again it can still browse. However another PC that has not logged in before, is still getting a 'No service is operating' response.
If you are using lokkit then I suggest using it to add ports and not dealing with iptables directly, you just need custom ports:
137/UDP
138/UDP
139/TCP
If you want to get to grips with iptables then scrap your lokkit rules and start from scratch with one of the many iptables tutorials out there, mixing them is just going to cause problems.
As far as I can see lokkit isn't running. I try 'service lokkit stop' and it's not recognised. My iptables now look like below, but still no access for new PCs.
As far as I can see Lokkit is just a GUI for modifying your iptables. I only have the command line to work with, but surely it doesn't make any difference.
lokkit is just a frontend for iptables but personally I htink they look complicated to work with manually. So I would either run "lokkit" and use it or scrap the rules that it has put in place "iptables -F". Then start with your own firewall which is customised for your needs/preferences.
You don't seem to need port 443 like everyone keeps saying. I've not got it open and it's working fine.
The above rules allow traffic on network address 192.168.0.* into the box on ports 137,138 and 139. You might not even need 138 open, but it's all netbios stuff, so I've done it anyway.
I've been playing some more and the following is a more secure foolproof way of setting up a Samba firewall. Notice no port 138 or 443 as some places are saying. The following rules allow any traffic in on port 137 and 139 TCP and UDP:
iptables -F (clears out the current firewall rules)
iptables -P INPUT DROP (by default block all incoming traffic, all forwarded traffic, but allow anything out)
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p tcp --dport 137 -j ACCEPT
iptables -A INPUT -p udp --dport 137 -j ACCEPT
iptables -A INPUT -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -p udp --dport 139 -j ACCEPT
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.