www server hit by dictionary attack - suggestions?

Hi,

We run a www server on an ADSL line.

It's been running a little slow lately, and the logs show a dictionary
attack going on, all the time.

*Most* of the source IPs are faked so no two-way connection would have
happened anyway, making that a DOS attack.

The server is FreeBSD v4.10.

The logins are coming in on port 22, standard for ssh. We will change
this anyway now.

Is there a simple way to reduce the CPU workload? Say put in a
straight 10 second delay on the login response? If so, where is this
configured? (what do microsoft.com do?? they must be inundated)

We need the port accessible but could block the logins except from a
specific IP; this would cause other problems though. A VPN (and
blocking the port totally) is another option, but we already have that
(with a VPN router, IPSEC, 3DES and all that stuff) and the config is
pretty dreadful.

The server goes to the outside via a Draytek 2900 router. Perhaps one
could do something in that, but I can't see what.

The FTP port is not open; we use rsync over ssh for everything
including telnet, and the passwords are very secure.

Any suggestions much appreciated.

On Mon, 05 Dec 2005 12:42:29 +0000, Peter wrote:

> *Most* of the source IPs are faked so no two-way connection would have
> happened anyway, making that a DOS attack.

Do you have hosts.allow and hosts.deny set up? I'm asuming they are used
in freebsd. Keeps most of the crap out on my system.

--
Regards
Tony
(Take out the garbage to reply)

Tony Hogarty <(E-Mail Removed)> wrote:

>> *Most* of the source IPs are faked so no two-way connection would have
>> happened anyway, making that a DOS attack.
>
>Do you have hosts.allow and hosts.deny set up? I'm asuming they are used
>in freebsd. Keeps most of the crap out on my system.

Not really useful; the IPs are regularly changing.

The router has a port scan DOS attack detection but that would be
useful only if we moved the ssh port number away from 22 (which will
mess up various rsync scripts).

Unfortunately the ssh function in FreeBSD doesn't appear to have a
configurable login delay.

On Mon, 05 Dec 2005 14:41:35 +0000, Peter wrote:

>
> Tony Hogarty <(E-Mail Removed)> wrote:
>
>>> *Most* of the source IPs are faked so no two-way connection would have
>>> happened anyway, making that a DOS attack.
>>
>>Do you have hosts.allow and hosts.deny set up? I'm asuming they are used
>>in freebsd. Keeps most of the crap out on my system.
>
> Not really useful; the IPs are regularly changing.
>
> The router has a port scan DOS attack detection but that would be useful
> only if we moved the ssh port number away from 22 (which will mess up
> various rsync scripts).
>
> Unfortunately the ssh function in FreeBSD doesn't appear to have a
> configurable login delay.

So set up hosts.deny to all:all and then only open the specific ports
and hosts you want. I had exactly the same problem as you and this has
reduced the attempts to log on to the server to maybe one every day.

--
Regards
Tony
(Take out the garbage to reply)

Tony Hogarty <(E-Mail Removed)> wrote:

>So set up hosts.deny to all:all and then only open the specific ports
>and hosts you want. I had exactly the same problem as you and this has
>reduced the attempts to log on to the server to maybe one every day.

I am not sure how this would help. The login attempts are all to port
22 which is easily detected with a quick port scan. We can't enable
only specific host IPs because I could be logging in from various
locations, including over GPRS, so the IP could be anything.

On Mon, 05 Dec 2005 15:23:11 +0000, in uk.telecom.broadband ,
(E-Mail Removed) (Peter) wrote:

>
> Tony Hogarty <(E-Mail Removed)> wrote:
>
>>So set up hosts.deny to all:all and then only open the specific ports
>>and hosts you want. I had exactly the same problem as you and this has
>>reduced the attempts to log on to the server to maybe one every day.
>
>I am not sure how this would help. The login attempts are all to port
>22 which is easily detected with a quick port scan. We can't enable
>only specific host IPs because I could be logging in from various
>locations, including over GPRS, so the IP could be anything.

Enable blocks of IPs, eg your ISP?

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Mark McIntyre <(E-Mail Removed)> wrote:

>>I am not sure how this would help. The login attempts are all to port
>>22 which is easily detected with a quick port scan. We can't enable
>>only specific host IPs because I could be logging in from various
>>locations, including over GPRS, so the IP could be anything.
>
>Enable blocks of IPs, eg your ISP?

If accessing over GPRS, the IP would be that of the GSM network
provider. Could be anything on the day.

There's a lot of stuff on google under "ssh login attack freebsd" etc.
A fairly recent problem.

On Mon, 05 Dec 2005 15:40:07 +0000, Peter wrote:

>
> Mark McIntyre <(E-Mail Removed)> wrote:
>
>>>I am not sure how this would help. The login attempts are all to port 22
>>>which is easily detected with a quick port scan. We can't enable only
>>>specific host IPs because I could be logging in from various locations,
>>>including over GPRS, so the IP could be anything.
>>
>>Enable blocks of IPs, eg your ISP?
>
> If accessing over GPRS, the IP would be that of the GSM network provider.
> Could be anything on the day.
>
> There's a lot of stuff on google under "ssh login attack freebsd" etc. A
> fairly recent problem.

Same gsm provider or multiple? The alternative is to load hosts.deny with
a list of ip addresses from regions that are know to be troublesome. So
unless you have a specific need to allow connections from Korea, Taiwan
and China I have a list of netblocks that you can put in hosts.deny that
willl probably go a long way towards easing your problem. If you want the
list mail me.

--
Regards
Tony
(Take out the garbage to reply)

On Mon, 05 Dec 2005 12:42:29 +0000, (E-Mail Removed) (Peter) wrote:


>The logins are coming in on port 22, standard for ssh. We will change
>this anyway now.

Pointless security through obscurity.

>Is there a simple way to reduce the CPU workload? Say put in a
>straight 10 second delay on the login response?

Waste of time.

>Any suggestions much appreciated.

There's a number of scripts about which check the contents of
/var/log/auth.log for failed entries and dynamically add block rules to
kick off the offending shotgunner via ipfw or if you run 5.x->CURRENT, pf.

10 seconds googling shows

http://bsdwiki.com/wiki/Blocking_rep...tempts_via_SSH






greg
--
"Access to a waiting list is not access to health care"

On Mon, 05 Dec 2005 15:40:07 +0000, in uk.telecom.broadband ,
(E-Mail Removed) (Peter) wrote:

>
> Mark McIntyre <(E-Mail Removed)> wrote:
>
>>>I am not sure how this would help. The login attempts are all to port
>>>22 which is easily detected with a quick port scan. We can't enable
>>>only specific host IPs because I could be logging in from various
>>>locations, including over GPRS, so the IP could be anything.
>>
>>Enable blocks of IPs, eg your ISP?
>
>If accessing over GPRS, the IP would be that of the GSM network
>provider. Could be anything on the day.

<egg sucking lesson>
Providers are allocated blocks of IPs, eg 81.100.1.1 through
81.100.255.255. Determine your GSM ISP's block, and permit that
through. I doubt anyone will try DOSing you from a mobile phone (can
you even get an ssh client for a mobe? presumably yes, if it were in
Java...)
</lesson>
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----