I'm under attack (sweeps)

[Freston]

A couple of weeks ago I ran lastb on my server, and it came out with nothing. Long story short, Today I ran this:

lastb | wc -l
88202

From what I see there are patterns discernible. A lot of pouncing from not to many different IP's. With roughly 10~20 login attempts per minute, I think my adversary isn't human. They are also originating from different parts of the world, Latin America, Asia, USA...

Now what should I do? They have not broken in yet. And I've been doing some reading on security. I guess I am a bit shocked right now, sweaty palms and everything. But I know, /I know/, this is nothing out of the ordinary. Just some bots finding a filtered ssh port on their sweeps, and now pouncing on the door.

I've read about these things enough, but as this is Real World, not exercise, I want to make sure I understand the basics and take the necessary precautions.
I am behind a hardware firewall, that forwards port 22 to my server
My server runs Slackware 12.1
It disallows protocol 1 and root logins
My accounts have odd names, not guessable by permutation of my personal details (nor are they 'lesbian' or 'playboy' as one of the attackers thought; he'd wish... I don't even shave my beard on most days )
My passwords are long and secure

What else can I do? Can I run commands when someone logs in to my machine if that someone isn't me? Is there a better way to deal with this than I have done? Without loosing functionality I mean. Can and how do I set a login delay of ~5 seconds on a failed attempt?

What are signs to look for that someone broke in?



Edit: Is it a generally /bad/ idea to sweep back, run a portscan on the incoming IP's? Can I bet the machines (IP's) used are zombies? Real World is different than reading about it.

[proprietarysucks]

get a firewall and allow port access only from your ip from no-ip.com .

[Dapper Dan]

I've experienced this several times. The first time got me in a real panic but now I don't worry too much about it. Like you, I have taken all the precautions you've mentioned. Make all passwords, long, convoluted and unpredictable. When not in use, I simply shut off access through port 22 in my router. If I need it, I'll VNC into that box and open it up.

[Freston]

get a firewall and allow port access only from your ip from No-IP - Dynamic DNS, Static DNS for Your Dynamic IP .

Thanx! That looks good. I'll check that out in more detail.

But the thing is, I need to be able to access my server from remote locations. Right now it's only in testing phase, but I intent to serve valuable data and important services on it. So I can't lock it by IP. I mean, I can configure my hardware firewall to forward any port into nothingness safe for known IP's. But I need to be able to access my machine from unknown IP's. Maybe if you want to comment on that?? I'd appreciate it.





The way I see it, my machine is only secured with a login name and a password. To crack my box you need:
Phase 1: a thousand monkeys scanning IP's at random until hit
Phase 2: a thousand monkeys randomly guessing login names (never knowing when they hit)
Phase 3: a thousand monkeys randomly guessing passwords
Phase 4: ... ehm ...
Phase 4: Profit!

Right (Y/n)?:

I've experienced this several times. The first time got me in a real panic but now I don't worry too much about it. Like you, I have taken all the precautions you've mentioned. Make all passwords, long, convoluted and unpredictable. When not in use, I simply shut off access through port 22 in my router. If I need it, I'll VNC into that box and open it up.

Thanx!
Yeah... I am thinking this is just something you need to put up with if connected. This is just normal (if I may use that word here).

As mentioned above, you'll need a lot of monkeys to permutate every letter (capital or otherwise), number and symbol on the keyboard to get to my long passwords. And that only helps /if/ you get to my login names, which are equally unguessable.

But I'm not not running this server for the heck of it. I intend to build functionality in this after extensive endurance testing. Have I done my utmost? Not to step across proprietarysucks's post here, but how much do I have to fear from these sweeps?
They didn't come close to anywhere near a valid login name, although I have found several holes in other systems I have set up earlier through this exercise. They are guessing common names. I'm glad I'm not called Eric or Patricia for that matter. They are guessing those. That /is/ something to consider.

[Geeth]

You mentioned port 22, if you are using it for ssh, then you could also change the port that ssh uses.

Login to your server and obtain root access through SU.

Edit the file /etc/sshd/sshd_config

At the top of the file, you will see something similar to:
Port 22
Protocol 2, 1

Just remember when you ssh in, you MUST provide the port since pretty much all programs will default it to 22.

i think the code is something like

ssh -p 2254 <ip>

but thats from memory and I'm tired
This may help a little though a port scan will show it open, but theres no way around that unless you close the port of course.

[SagaciousKJB]

I believe the simplest thing you could do, is disable passwords, and use keys instead. This way no matter what, they will not login.


However, if you like passwords over keys ( I do too ), you can use a script called denyhosts. It will take any IP that has over a certain amount of failed login attempts on ssh and then adds them to your /etc/hosts.deny in whatever fashion you wish. I set mine to deny ALL, but I think default is only ssh.

The greatest part about denyhosts is that, the IPs that are collected are pooled, and kept on a community database, and this community database is also preloaded. So, in essence, you will be helping to add these IPs to a massive list of bad IPs, if they're not on it already. By the sounds of it it's just a bot net, so I doubt your server is the only they're trying against; if they ran into one with denyhosts, then they will be on that blacklist.

SourceForge.net: DenyHosts

[Freston]

You mentioned port 22, if you are using it for ssh, then you could also change the port that ssh uses.

Yeah I looked into that. What I think I can do is give SSH a really high port, one that nmap doesn't scan by default and send port 22 to an IP out of my normal DHCP range. It wont help against a human with the intend of entering my system, but it could throw the bots a little off track I think.

I'm not really sure if it works like that though.

However, if you like passwords over keys ( I do too ), you can use a script called denyhosts.

Yeah I want to keep the username/password login combo. It's just easier than carrying keys around.

I doubted the effect of DenyHosts.py as a means to block attacks. My reasoning was that all attackers are zombies. I then thought hosts.deny would eventually outgrow my root partition

But then, I didn't know this:

The greatest part about denyhosts is that, the IPs that are collected are pooled, and kept on a community database, and this community database is also preloaded. So, in essence, you will be helping to add these IPs to a massive list of bad IPs, if they're not on it already. By the sounds of it it's just a bot net, so I doubt your server is the only they're trying against; if they ran into one with denyhosts, then they will be on that blacklist.

I'm gonna try this first then.



____

(after one month)
Unsuccessful attacks > 90,000
Successful attacks = 0
Unique number of attackers = 98
Unique attacks (discarding retries) ~ 49,000

And by far the #1 login name they are attacking = root
That just goes to show you it /is/ a good idea to disable root logins. Not many systems default to this.

[Geeth]

I read your sig, with root being the username they are trying..

If you want to, you could try disabling root log in so only su (and sudo though dont know if slack has it) to get root access

chsh -s /bin/false root

To lock

sudo passwd -u root

To unlock.

If you are going to be logging in from only 1 location then you might want to add
ALL:ALL to /etc/hosts.deny
and only have the ip that you will be logging in from in /etc/hosts.allow.

That it quite limiting.


Also at one point I think you mentioned what to look for... I don't know with slackware but I know with bsd you get daily security audits to the root account. If it doesn't default with that in slackware then you may be able to download something similar or activate it.

Another thing I thought of. If it's a automated system then maybe if you have you modem off for a period of time, it may think you dont exist and stop... thats a big maybe and you will have no connection. But never

[bigtomrodney]

Yeah I looked into that. What I think I can do is give SSH a really high port, one that nmap doesn't scan by default and send port 22 to an IP out of my normal DHCP range. It wont help against a human with the intend of entering my system, but it could throw the bots a little off track I think.

And by far the #1 login name they are attacking = root
That just goes to show you it /is/ a good idea to disable root logins. Not many systems default to this.

These are the best two pieces of advice in running ssh on your box. Most of the scripts out there are bulk attacks by scripts so you don't even need to pick a crazy port up in five digits...a lot of them brute force port 22 in the knowledge that if you're running on 22 chances are you're not using keys and you allow root login.

I used to get up to 300 attempts a day when I ran on 22. With the port I run on now I get absolutely zero...

[Freston]

Although my opinion on denyhost is quite favorable, I don't want to change to many things at the same time. So I gave the ssh daemon a port higher than what nmap scans by default. And since then I haven't had any more attacks.


We likes it...


...yessssss they keep their filthy hands to themselves :cough: my preciousss