deny ssh access from lan with iptables
 

Hi there,

Does anyone know a rule for iptables to block ssh access from a host on the lan?

For example gateway is 192.168.0.1 and i want to deny access to 192.168.0.1:22 from the host 192.168.0.50

How can I do that? Thank you

On the host 192.168.0.1 you would add the following iptables rule to your firewall:
iptables -I INPUT -s 192.168.0.50 -p tcp --dport 22 -j REJECT

thank you very much

i was using -A instead of -I and I assume thats why it didnt work. oh boy :(

you are a life saviour :D

Rule order can be a real "gotcha" sometimes. The -I option will insert the rule at the beginning of the firewall while -A will "append" it to the bottom. So I'm guessing you had a rule earlier on in the firewall that was dropping or rejecting packets before they got to your rule. You can use -A, but you'd need to modify your firewall script and put that rule towards the top.

By the way, you'll need to save your modified firewall rules otherwise the firewall will reset after a reboot. How to save your rules can vary depending on your distro, so which one are you using?

So, do you mean its not enough if I just add that line to the firewall script? If I will reboot, when firewall will be launched, then that line would be executed too, right?

I use a custom firewall, nothing fancy (didnt really get what you mean by that sir), and distro is slackware, firewall resides in /etc/rc.d/rc.firewall

Thank you again for helping me:)

So, do you mean its not enough if I just add that line to the firewall script? If I will reboot, when firewall will be launched, then that line would be executed too, right?
If you are adding it to a script, then yes it should be loaded on boot. I wasn't sure if you were doing that or just running the command from the command line. So you should be all set.

Thank you again for helping me:)
No problem.

one more newbie question from me, Capt_Caveman


if i want to allow ssh only from one host ( for example 192.168.0.80) i tried to do...

iptables -I INPUT -p tcp -s 192.168.0.80 --destination-port 22 -j ACCEPT

and to drop the packets from the rest of the hosts on the lan i tried, right after the above rule:

iptables -I INPUT -p tcp -s 192.168.0.0/24 --destination-port 22 -j DROP

I am obviously doing something wrong, because after i insert this rule the host 192.168.0.80 cannot connect either

Please help me solve it :)

It would probably help if you posted your firewall script, but based on the above I'd guess that the problem has to do with rule order. Since you're using the -I option, whichever rule is entered last is inserted at the top. Like this:

Here is our example firewall script:

iptables -A rule X
iptables -A rule Y
iptables -A rule Z

If you look at the order these rules appear in the actual firewall, it will look like this:

rule X
rule Y
rule Z

So when a packet is received, it will be processed in the order X->Y->Z

So let's add your first rule (the one with the ACCEPT target), which I'll just call rule 1:

iptables -A rule X
iptables -A rule Y
iptables -A rule Z
iptables -I rule 1

Since that rule uses the -I option it is added to the beginning of the firewall, so if you look at the rule order in the firewall using iptables -L you would see this:

rule 1
rule X
rule Y
rule Z

And packets would be processed in the order 1->X->Y->->Z

Now add the second rule (the one that drops packets from the rest of the LAN) which I'll call rule 2:

iptables -A rule X
iptables -A rule Y
iptables -A rule Z
iptables -I rule 1
iptables -I rule 2

This time the firewall looks like this:

rule 2
rule 1
rule X
rule Y
rule Z

So rule 2 is actually coming before rule 1 and packets are processed like this 2->1->X->Y->Z. So all our packets are getting dropped.

Now just to use an example in order to clarify -I vs -A, say you had a third rule (rule 3) and you decided to use -A instead. You enter the rules like this:

iptables -A rule X
iptables -A rule Y
iptables -A rule Z
iptables -I rule 1
iptables -I rule 2
iptables -A rule 3

When you look at the firewall, it would look like this:

rule 2
rule 1
rule X
rule Y
rule Z
rule 3

and our packets would get process in the order 2->1->X->Y->Z->3

Hopefully that clears up -A vs -I and rule ordering a bit.

You can fix this by switching the order you are entering rule 1 and 2 or what you really should do is use the -A option for *all* the rules, but just make sure everything is in the proper order. If you post your firewall ruleset, I'll give you a hand doing that. Make sure to remove any public IP addresses from your rules before posting.

Thank you again, Capt_Caveman

The firewall I use its "inherited" if i can say so from the former network administrator, who is a good friend of mine but he will be gone for the next 4 months out of the country so he cannot help me much. His firewall is much "scripted" and "automated" - hey, im the newbie here :p - think he has declared some variables like nat...internal interface, ext interface, spoof, DOS protection, syn.. etc.. etc... and using those. I think this is the part where the firewall does not need to be modified. BUT the firewall loads a file called "custom-rules" where I'm supposed to be able to insert some rules...the custom-rules file is not loaded neither at the beginning or the end of the firewall execution script... somewhere in the middle (after some spoofing/dos/syn protection thingy)

I think I have tried adding the rules with -A instead of -I to that custom-rules file.. restarted firewall but I think it didnt work.... have not tried using -I and reversing the order as you suggested because I'm not logged into that machine, but I might be able to try it tomorrow.

So, if that won't work either.. I'm lost :(

Thanks God its friday :D

been tampering with the firewall (the custom-rules part I have) after you were so kind to explain to me the order and using -A INPUT to allow ssh from one ip then -A INPUT to deny for the rest of the LAN. Actually at first i was just adding the rules from command line and they didnt seem to work. After I inserted those lines into the custom-rules and restarting the firewal... TADAAAA.. it was working.

Think you heard that before, but you rule Capt_Caveman :p

Problem solved. Thank you.

Think you heard that before, but you rule Capt_Caveman :p
Lol. Not really, but thanks for saying so ;)

Problem solved. Thank you.
Cool. Glad I could help.