Results 1 to 10 of 11
A couple of weeks ago I ran lastb on my server, and it came out with nothing. Long story short, Today I ran this: Code: lastb | wc -l 88202 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 06-27-2008 #1
I'm under attack (sweeps)
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
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.Can't tell an OS by it's GUI
- 06-27-2008 #2
- Join Date
- May 2008
get a firewall and allow port access only from your ip from no-ip.com .
- 06-27-2008 #3
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.
- 06-28-2008 #4Originally Posted by proprietarysucks
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!
Originally Posted by Dapper Dan
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.Can't tell an OS by it's GUI
- 06-30-2008 #5
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:
Protocol 2, 1
i think the code is something like
ssh -p 2254 <ip>
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.
- 07-02-2008 #6
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.
- 07-02-2008 #7Originally Posted by Geeth
I'm not really sure if it works like that though.
Originally Posted by SagaciousKJB
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:
Originally Posted by SagaciousKJB
(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.Can't tell an OS by it's GUI
- 07-03-2008 #8
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
sudo passwd -u root
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
- 07-03-2008 #9
- Join Date
- Nov 2004
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...
- 07-04-2008 #10
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 preciousssCan't tell an OS by it's GUI