SSH and iptables

I am looking for iptables rules to do the following:

When an SSH connection attempt (at the standard port) from a given IP
address fails, no further SSH connections will be accepted from that IP
address for 60 seconds.

If, on the other hand, the connection attempt succeeds, then that IP
address is free to start as many (successful) SSH connections within the
next 60 seconds (and beyond, in fact).

Is this possible? I am aware of numerous iptables rules that can do
something similar. The catch is that they can't tell whether or not a
connection attempt was unsuccessful.

On 2006-03-08, Steven Jones <(E-Mail Removed)> wrote:
> I am looking for iptables rules to do the following:
>
> When an SSH connection attempt (at the standard port) from a given IP
> address fails, no further SSH connections will be accepted from that IP
> address for 60 seconds.
>
> If, on the other hand, the connection attempt succeeds, then that IP
> address is free to start as many (successful) SSH connections within the
> next 60 seconds (and beyond, in fact).
>
> Is this possible? I am aware of numerous iptables rules that can do
> something similar. The catch is that they can't tell whether or not a
> connection attempt was unsuccessful.


Hmmm... I'm not taking into account the possible cpu overhead related
to doing this, but you can likely work up something the the recent
match:
iptables -A INPUT -i <interface> -p tcp --dport 22 -m state --state \
ESTABLISHED -m recent --set --rsource --name SSH_EST -j ACCEPT
iptables -A INPUT -i <interface> -p tcp --dport 22 -m state --state \
NEW -m recent --rcheck --rsource --name SSH_EST -j ACCEPT

Note that this is untested, written from memory, and may not have
a chance of working, even if load concerns are irrelevant - it does,
however, give you something on which to chew...

RW

--

http://rlworkman.net

On Thu, 09 Mar 2006 02:19:20 GMT, Robby Workman <(E-Mail Removed)> wrote:

>On 2006-03-08, Steven Jones <(E-Mail Removed)> wrote:
>> I am looking for iptables rules to do the following:

>> If, on the other hand, the connection attempt succeeds, then that IP
>> address is free to start as many (successful) SSH connections within the
>> next 60 seconds (and beyond, in fact).

To OP:
So, once you're cracked you're screwed, that's how you want it?

>> Is this possible? I am aware of numerous iptables rules that can do
>> something similar. The catch is that they can't tell whether or not a
>> connection attempt was unsuccessful.

A shell script may directly load --recent's named tables with IP addresses
as a feedback mechanism:

grant@deltree:~$ for x in /proc/net/ipt_recent/*; do echo $(basename $x); cat $x; done
calm
src=68.200.42.52 ttl: 109 last_seen: 31731944 oldest_pkt: 1 last_pkts: 31731944
src=83.247.32.72 ttl: 43 last_seen: 32150622 oldest_pkt: 1 last_pkts: 32150622
deny
src=68.142.251.128 ttl: 52 last_seen: 31027663 oldest_pkt: 0 last_pkts: 28973057, 31027663
src=68.142.250.77 ttl: 52 last_seen: 28973092 oldest_pkt: 1 last_pkts: 28973092
src=72.30.111.140 ttl: 51 last_seen: 35948801 oldest_pkt: 0 last_pkts: 29281661, 35948801
....
233 lines

>Hmmm... I'm not taking into account the possible cpu overhead related
>to doing this, but you can likely work up something the the recent
>match:

grant@deltree:~$ uptime
15:31:04 up 4 days, 7:39, 4 users, load average: 0.00, 0.00, 0.00

This on a Pentium classic/233 with 128MB RAM, but I'm on a small
connection, I've not noticed --recent loading CPU too much

One may adjust how many visits per IP are stored, I use 400 x 2
(entries x visits) per named table (for data collection by class),
eg:

Classify junk:
66 drop MSFT exploit port, repeat
52 reject MSFT exploit port, new
10 drop probe from privileged port, new
8 drop deny access from ban list, repeat
7 reject deny access from ban list, new
6 drop probe from privileged port, repeat
6 reject random port, new
2 drop random port, repeat
1 pong ping touch

Grant.
--
Cats are smarter than dogs. You can't make eight cats pull
a sled through the snow.

On Thu, 09 Mar 2006 02:19:20 +0000, Robby Workman wrote:

> On 2006-03-08, Steven Jones <(E-Mail Removed)> wrote:
>> I am looking for iptables rules to do the following:
>>
>> When an SSH connection attempt (at the standard port) from a given IP
>> address fails, no further SSH connections will be accepted from that IP
>> address for 60 seconds.
>>
>> If, on the other hand, the connection attempt succeeds, then that IP
>> address is free to start as many (successful) SSH connections within the
>> next 60 seconds (and beyond, in fact).
>>
>> Is this possible? I am aware of numerous iptables rules that can do
>> something similar. The catch is that they can't tell whether or not a
>> connection attempt was unsuccessful.
>
>
> Hmmm... I'm not taking into account the possible cpu overhead related to
> doing this, but you can likely work up something the the recent match:
> iptables -A INPUT -i <interface> -p tcp --dport 22 -m state --state \
> ESTABLISHED -m recent --set --rsource --name SSH_EST -j ACCEPT
> iptables -A INPUT -i <interface> -p tcp --dport 22 -m state --state \
> NEW -m recent --rcheck --rsource --name SSH_EST -j ACCEPT
>
> Note that this is untested, written from memory, and may not have a chance
> of working, even if load concerns are irrelevant - it does, however, give
> you something on which to chew...

Hmm... Are these rules able to tell between successful and nonsuccessful
login attempts?

On Thu, 09 Mar 2006 15:40:11 +1100, Grant wrote:

> On Thu, 09 Mar 2006 02:19:20 GMT, Robby Workman <(E-Mail Removed)>
> wrote:
>
>>On 2006-03-08, Steven Jones <(E-Mail Removed)> wrote:
>>> I am looking for iptables rules to do the following:
>
>>> If, on the other hand, the connection attempt succeeds, then that IP
>>> address is free to start as many (successful) SSH connections within
>>> the next 60 seconds (and beyond, in fact).
>
> To OP:
> So, once you're cracked you're screwed, that's how you want it?

Are you saying that, without such hypothetical rules, once you are
cracked you are not screwed?

I have my reasons to wish to have such rules.

>
>>> Is this possible? I am aware of numerous iptables rules that can do
>>> something similar. The catch is that they can't tell whether or not a
>>> connection attempt was unsuccessful.
>
> A shell script may directly load --recent's named tables with IP
> addresses as a feedback mechanism:
>
> grant@deltree:~$ for x in /proc/net/ipt_recent/*; do echo $(basename
> $x); cat $x; done calm
> src=68.200.42.52 ttl: 109 last_seen: 31731944 oldest_pkt: 1 last_pkts:
> 31731944 src=83.247.32.72 ttl: 43 last_seen: 32150622 oldest_pkt: 1
> last_pkts: 32150622 deny
> src=68.142.251.128 ttl: 52 last_seen: 31027663 oldest_pkt: 0 last_pkts:
> 28973057, 31027663 src=68.142.250.77 ttl: 52 last_seen: 28973092
> oldest_pkt: 1 last_pkts: 28973092 src=72.30.111.140 ttl: 51 last_seen:
> 35948801 oldest_pkt: 0 last_pkts: 29281661, 35948801 ... 233 lines
>
>>Hmmm... I'm not taking into account the possible cpu overhead related
>>to doing this, but you can likely work up something the the recent
>>match:
>
> grant@deltree:~$ uptime
> 15:31:04 up 4 days, 7:39, 4 users, load average: 0.00, 0.00, 0.00
>
> This on a Pentium classic/233 with 128MB RAM, but I'm on a small
> connection, I've not noticed --recent loading CPU too much
>
> One may adjust how many visits per IP are stored, I use 400 x 2 (entries
> x visits) per named table (for data collection by class), eg:
>
> Classify junk:
> 66 drop MSFT exploit port, repeat 52 reject MSFT exploit port,
> new
> 10 drop probe from privileged port, new
> 8 drop deny access from ban list, repeat 7 reject deny access
> from ban list, new 6 drop probe from privileged port, repeat 6
> reject random port, new
> 2 drop random port, repeat
> 1 pong ping touch
>
> Grant.

Hi,

Steven Jones wrote:
> When an SSH connection attempt (at the standard port) from a given IP
> address fails, no further SSH connections will be accepted from that IP
> address for 60 seconds.
>
> If, on the other hand, the connection attempt succeeds, then that IP
> address is free to start as many (successful) SSH connections within the
> next 60 seconds (and beyond, in fact).

For this job I use the skript from http://fail2ban.sourceforge.net
With default settings it will block any traffic from an address from
which the authentification fails 3 times within 10 minutes for another
10 minutes.

HTH,
Josef