Automatic blocking of attackers' IP

In comp.os.linux.security Walter Schiessberg <nospam.news@arcor.de> wrote:
: FEEB wrote on 07.09.2004 15:53:

:> I would like to have the following scenario implemented on my network:
:>
: You might want to look at swatch <http://swatch.sourceforge.net/>.

Be very careful doing this. It provides a very easy way for someone to
get you to DOS yourself.

Very few sites do this sort of automatic blocking for this reason. Certainly
I wouldn't do it on a public access site.

Arthur

--
Arthur Clune http://www.clune.org
"Technolibertarians make a philosophy out of a personality defect"
- Paulina Borsook

On 2004-09-07, Bill Unruh <unruh@string.physics.ubc.ca> wrote:
>
> Then why are you asking how to close yourself to some?
> Sounds like a DOS would be possible if you impliment what you want (ie from
> a machine that you need, an attacker tries to log onto your system a number
> of times, and thus closes off that machine entirely). .
> Anyway, why does it matter? Is your root password weak enough that you are
> afraid someone could guess it? Also you could just institute norootlogins
> in ssh and then they could not succeed even if they got the password.
>
I was about to mention this. Lots of people get excited by the idea of
automagical blocking (and also MIRROR responses, where you replace the
destination address with the source one and send it on its merry way back to
the 'attacker').

Imagine the scenerio:

1) someone does something to your machine which trigger the IP block

2) they repeat and notice the behaviour

3) they start repeating the attack but spoofing source IP addresses, note
that this does not have to be at a 'fast' (noticable/traceable) rate

4) your script faithfully keeps blocking IP address as their are 'bad'
attacks originating from them

5) next think you know an entire /8 is unreachable due to your automation

There are ways around this problem (only blocking 'SYN, SYN-ACK, ACK'
attacks and such) however as pointed out already, surely its better to invest
your time/resources in making sure your equipment is locked down anyway?

I think you need to consider the security actually 'gained' from in relation
to the cost. The above scenerio (and there are plenty of others) shows that
the potential cost can be very high, but what have you
achieved....effectively no more security.

> What I am far more concerned about is that places are putting up firewalls
> which block out ssh. I was just in an airline lounge in Sao Paulo, where
> their firewall blocks outgoing ssh, which meant I could not log onto my
> home machine at all.
>
not a great solution but I normally put ssh on port 443 which means even if
you have nasty proxy servers in the way you can 'glide' through.

Luckily my work place is not fascist.....besides its an ISP and I have the
root password :)

Cheers

Alex

On 7 Sep 2004 18:48:39 GMT, Bill Unruh wrote:

>"FEEB" <feeb@chem.utoronto.ca> writes:
>
>]On 7 Sep 2004 15:07:27 GMT, Mark A. Odell wrote:
>
>]>"FEEB" <feeb@chem.utoronto.ca> wrote in
>]>news:srropurzhgbebagbpn.i3obx7d.pminews@news1.che m.utoronto.ca:
>]>
>]>> Hi,
>]>>
>]>> I would like to have the following scenario implemented on my
network:
>]>>
>]>> 1.
>]>> Someone tries repeatedly and illegally to log in as 'admin', 'root'
or
>]>> whatever from some IP using SSH (or any other means).
>]>
>]>Why not just set hosts.deny to ALL: ALL and then open up only those IPs
>]or
>]>domains you wish to allow in hosts.allow?
>
>]We must be open to anyone. That's our business :-)
>
>Then why are you asking how to close yourself to some?
>Sounds like a DOS would be possible if you impliment what you want (ie
from
>a machine that you need, an attacker tries to log onto your system a
number
>of times, and thus closes off that machine entirely).

To himself. Yes. That's exactly what I want. And not just that machine.
The entire 4 C-blocks network.


Frank Bures, <feeb@chem.utoronto.ca>

On 7 Sep 2004 12:57:32 -0700, P Gentry wrote:

>http://www.cipherdyne.org/index.html

Thanks


Frank Bures, <feeb@chem.utoronto.ca>

On Tue, 07 Sep 2004 17:27:40 GMT, Geoffrey King wrote:

>On Tue, 07 Sep 2004 09:53:31 -0400, FEEB wrote:
>
>> Hi,
>>
>> I would like to have the following scenario implemented on my network:
>>
>> 1.
>> Someone tries repeatedly and illegally to log in as 'admin', 'root' or
>> whatever from some IP using SSH (or any other means).
>>
>> 2.
>> When the number of attempts reaches a predefined trigger level, an
action
>> occurs (a script is executed, etc.)
>>
>> The definition of attempts, the trigger level and the resulting action
>> should be configurable.
>>
>> Is a watchdog like that that would fulfill my requirements available
>> somewhere out there or do I have to sit down and start scripting?
>
>1. Rate Limit SSH connections with IPTables. You can use Traffic shaping
>to get fine grain control if that isn't enough.
>
>2. Use Swatch to monitor your SSH log file for failed connections. Tell
it
>to use IPTables to drop traffic from IP's that appear too often. There's
>an example in the config that almost does this for you already.
>
>http://swatch.sourceforge.net/


Thanks. That's what I was looking for. You just save me a lot of time!


Frank Bures, <feeb@chem.utoronto.ca>

Walter Schiessberg wrote:
> FEEB wrote on 07.09.2004 15:53:
>
>
>>I would like to have the following scenario implemented on my network:
>>
>>1.
>>Someone tries repeatedly and illegally to log in as 'admin', 'root' or
>>whatever from some IP using SSH (or any other means).
>>
>>2.
>>When the number of attempts reaches a predefined trigger level, an action
>>occurs (a script is executed, etc.)
>
>
> You might want to look at swatch <http://swatch.sourceforge.net/>.
> I use it for triggering alarms. You can use it to trigger a blocking
> script for iptables. ;)
>
> Walter

Just be very careful because this kind of systems are prone to
DOS attacks spoofing the source address of the attacker.


--

Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
-- Jack Kerouac, "On the Road"

On Tue, 07 Sep 2004 09:53:31 -0400, FEEB wrote:

> Hi,
>
> I would like to have the following scenario implemented on my network:
>
> 1.
> Someone tries repeatedly and illegally to log in as 'admin', 'root' or
> whatever from some IP using SSH (or any other means).
>
> 2.
> When the number of attempts reaches a predefined trigger level, an action
> occurs (a script is executed, etc.)
>
> The definition of attempts, the trigger level and the resulting action
> should be configurable.
>
> Is a watchdog like that that would fulfill my requirements available
> somewhere out there or do I have to sit down and start scripting?
>
> Thanks
>
>
> Frank Bures, <feeb@chem.utoronto.ca>

Take a look at PortSentry. It will key off actions you can specify and
automatically block / close the port for a period of time. It can also be
scripted to insert the attacker's IP address into the hosts.deny thereby
blocking that IP from that daemon.

Bill

On Mon, 11 Oct 2004 03:12:52 +0000, William B. Cattell wrote:

> On Tue, 07 Sep 2004 09:53:31 -0400, FEEB wrote:
>
>> Hi,
>>
>> I would like to have the following scenario implemented on my network:
>>
>> 1.
>> Someone tries repeatedly and illegally to log in as 'admin', 'root' or
>> whatever from some IP using SSH (or any other means).
>>
>> 2.
>> When the number of attempts reaches a predefined trigger level, an action
>> occurs (a script is executed, etc.)
>>
>> The definition of attempts, the trigger level and the resulting action
>> should be configurable.
>>
>> Is a watchdog like that that would fulfill my requirements available
>> somewhere out there or do I have to sit down and start scripting?
>>
>> Thanks
>>
>>
>> Frank Bures, <feeb@chem.utoronto.ca>
>
> Take a look at PortSentry. It will key off actions you can specify and
> automatically block / close the port for a period of time. It can also be
> scripted to insert the attacker's IP address into the hosts.deny thereby
> blocking that IP from that daemon.
>
> Bill

Yes portsentry is an excellent way to do this, just don't forget to add a
whitelist so you don't accidently block yourself out, or so that attackers
don't spoof an IP and make you block lots of other hosts you want to get
to (DNS server/gateways etc).

For the mega paranoid I would recommend implementing some form of TCP Door
knocking, an example of this is cdoor from the clever people at
phenoelit.de

Or for a more robust implementation SADoor
(http://cmn.listprojects.darklab.org/)

This way you can have a DENY ALL type rule on the firewall, but still get
into the box if you need to by sending specially crafted packets.

--
http://www.lucidit.co.nz

In article <pan.2004.10.19.01.16.58.25789@mangled.lgw.co.nz >, moo wrote:
> For the mega paranoid I would recommend implementing some form of TCP Door
> knocking, an example of this is cdoor from the clever people at
> phenoelit.de
>
> Or for a more robust implementation SADoor
> (http://cmn.listprojects.darklab.org/)

To avoid having to deal with TCP timeouts, most of these 'port knocking'
programs use UDP. The problem is, they tend to depend on the order of
delivery of packets, and this isn't guaranteed with UDP; indeed, even
their arrival isn't guaranteed.

They are nice and stealthy, but the more complex (and hence, secure) you
make the 'knock', the less reliable the system will be. To avoid replay
attacks, you need to add some kind of cryptographic payload (or *really*
complicate the knock sequence), further increasing the complexity. SADoor
actually implements something like shell access, handling varying amounts
of data. Now you've got at least the potential for buffer overflows.

I took a different route with my own approach, Ostiary. It does listen
on a port, and can therefore be detected, but the protocol it uses is so
simple it can't be effectively hacked (though it can be DOSed, of course),
and it's immune to buffer overflows. It's also so easy on resources that
it runs just fine on my Palm client and my Mac SE/30 webserver:

http://ingles.homeunix.org/software/ost/

It can be used to do anything port knockers do. I use it to selectively
enable and disable SSH, among other things.

--
Sincerely,

Ray Ingles (313) 227-2317

If you have any trouble sounding condescending,
find a Unix user to show you how it's done.
-- Scott Adams: DNRC Newsletter 3.0

In article <pan.2004.10.19.01.16.58.25789@mangled.lgw.co.nz >,
moo <moo@mangled.lgw.co.nz> wrote:

>For the mega paranoid I would recommend implementing some form of TCP Door
>knocking...

I've heard it pointed out that door knocking is just another form of
security-by-obscurity.