Re: blocking access to port 22 when INPUT policy is ACCEPT

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

 



On 7/31/2007 5:18 PM, Maximilian Wilhelm wrote:
You can't.

Yes you can. Well if you understand the concepts of latter logic used when electro-mechanical relays were used to control elevators you can.

But what's wrong with the two rules?

Nothing. The old saying "If it isn't broke, don't fix it..." with it's third stanza "...optimize it!" comes to mind.

What you could do if you like is to pass every connection to port 22 to a subchain like this:

iptables -N filter_ssh_access
iptables -A INPUT -p tcp --dport 22 -j filter_ssh_access

Yes...

iptables -A filter_ssh_access -s ! a.b.c.d/29 -j REJECT --reject-with icmp-admin-prohibited iptables -A filter_ssh_access -s ! e.f.g.h -j REJECT --reject-with icmp-admin-prohibited

Oh, so close.

You might have noticed that I've changed the "DROP" to "REJECT" with fitting type which will make the live of you and other people easier when debugging anything related to ssh access to this box.

The problem with this is that if you have an IP address of e.f.g.h, the first rule will reject the connection. Negative logic does not work quite as you would expect it to. You have to work with inverted positive logic below (invert the result of the entire set of logic).

There is also the fact that fewer and fewer things know how to handle error messages like this, or if they do they do not display them to the end user. (Thanks M$!) You may have better luck with a basic REJECT target than one that specifies the ICMP error code unless you know that you are working with a client application that can correctly interpret.

Try this on for size.

iptables -N filter_ssh_access
iptables -A INPUT -p tcp --dport 22 -j filter_ssh_access

iptables -A filter_ssh_access -s a.b.c.d/29 -j ACCEPT
iptables -A filter_ssh_access -s e.f.g.h -j ACCEPT
iptables -A filter_ssh_access -j REJECT --reject-with icmp-admin-prohibited

In this case, you are jumping to a sub-chain just like Max suggested. However the difference is that you are accepting on known good and then rejecting after the list of known good has been exhausted. This will scale compared to rules conflicting with each other, which is what the OP and Max had happening.



Grant. . . .


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux