blocking access to port 22 when INPUT policy is ACCEPT

blocking access to port 22 when INPUT policy is ACCEPT

[Maxim Veksler]

Hello,

I have my machine configured to allow all traffic in INPUT table, but
I would like to block access to port tcp22 from all besides several
ip's.

The following rules as the basic of what I'm trying to achieve:

/sbin/iptables -A INPUT -s ! a.b.c.d/29 -p tcp --dport 22 -j DROP
/sbin/iptables -A INPUT -s ! e.f.g.h -p tcp --dport 22 -j DROP

How can I do a "AND" between them as in
 if (-s ! a.b.c.d/29 AND -s ! e.f.g.h) then -j DROP ?

Thank you,
Maxim.

-- 
Cheers,
Maxim Veksler

"Free as in Freedom" - Do u GNU ?

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

[Maximilian Wilhelm]

Am Wednesday, den  1 August hub Maxim Veksler folgendes in die Tasten:

Hi!

> I have my machine configured to allow all traffic in INPUT table, but
> I would like to block access to port tcp22 from all besides several
> ip's.

> The following rules as the basic of what I'm trying to achieve:
 
> /sbin/iptables -A INPUT -s ! a.b.c.d/29 -p tcp --dport 22 -j DROP
> /sbin/iptables -A INPUT -s ! e.f.g.h -p tcp --dport 22 -j DROP

> How can I do a "AND" between them as in
>  if (-s ! a.b.c.d/29 AND -s ! e.f.g.h) then -j DROP ?

You can't.

But what's wrong with the two rules?

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

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

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.

HTH
Ciao
Max
-- 
	Follow the white penguin.

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

[Grant Taylor]

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. . . .

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

[Grant Taylor]

On 7/31/2007 5:04 PM, Maxim Veksler wrote:
> I have my machine configured to allow all traffic in INPUT table, but 
> I would like to block access to port tcp22 from all besides several 
> ip's.

*nod*

> How can I do a "AND" between them as in

Wrong logic operator.  The question could also be written as "How do I 
block all connections not from the set A or B or C or ...".  One way to 
achieve this is with the IPSet match extension (which I have not worked 
with, so this may not be syntactically correct).

iptables -A INPUT ! -m set --set sshclients src -j DROP

In theory this rule will say "if the source ip is not in set sshclients 
DROP the packet".

This will allow you to use the user space utility ipset to control your 
(iphash) set which is your list of allowed ssh clients.



Grant. . . .

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

[G.W. Haywood]

Hi there,

On Wed, 1 Aug 2007 Grant Taylor wrote:

> Wrong logic operator.  The question could also be written as "How do I
> block all connections not from the set A or B or C or ...".
>
> One way to achieve this is with the IPSet match extension (which I
> have not worked with, so this may not be syntactically correct).
>
> iptables -A INPUT ! -m set --set sshclients src -j DROP

Looks good to me.  Here's the most recent addition to my roughly two
dozen ipsets:

iptables -I INPUT 98 -m set --set BLOCKSET08 src -j DROP

(My BLOCKSET08 set blocks /8 IP ranges.  :)

FWIW I have currently block a little over 26,000 IP ranges in 25 sets
and the performance is fine on very modest hardware.

At present I believe there are some issues compiling ipsets and the
latest 2.6 kernels, probably worth looking before you leap.

--

73,
Ged.

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

[Maximilian Wilhelm]

Am Tuesday, den 31 July hub Grant Taylor folgendes in die Tasten:

> >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.

:)

[...]
> >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).

Argh.
I should not write mails when totally tired.
I'm really sorry for the fnord.
Thanks for getting it right.

> 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.
[...]

You're sadly right here, too.
But I have to state that tcpdump (which most probably will be most
often used when debugging network problems) shows this correct.
I think ethereal^Wwhireshark will do so, too.

Ciao
Max
-- 
	Follow the white penguin.