Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ssh attacks and prevention 4

Status
Not open for further replies.

Nostradamus

Technical User
May 3, 2000
419
0
0
SE
My messages file is flooded with people trying to access my suse server using ssh. I guess it's a good thing they appear in this file instead of getting access, but...

Is it possible to drop connections from people guessing/trying different user-id's? I have iptables enables so a rule there perhaps? Something you can enable in the ssh daemon?

Is this all automated scripts (script-kiddies) or something I should take serious? No idea looking up the connecting ip´s I guess.

Anyone know any good anti-root-kit or intrusion detection software that I can/should install?

/Sören
 
I have the same thing in my logs on a Mandrake system I have
been looking into doing exactly what you have suggested and I have found some solutions which are basically a script that runs and checks you logs for invalid/illegal user/login attempts, then using that info you can update iptable I guess. Since i am using Shorewall and iptable freaks me outIm working on a script that will update the blacklist file with offending ip's.

Of course you also want to flush out blacklisted ip's every once in a while too.
 
Another thing, I have disabled root login in sshd_config
with "PermitRootLogin no"

As well I have disabled ssh access to all but one user which is a really long name so the chances of some script kiddies guessing a actual valid login name is small.

in sshd_config u set 'AllowUsers myuser1 myuser2' to allow
a limited set of users.

Also u could set:

PasswordAuthentication no
PubkeyAuthentication yes

So that passwords can't be used only keys.

Still annoying to see all thoughs crack attempts though.
 
thanks sos. very helpful indeed *star*

I'm a lazy man posting here before looking into the possibilities of sshd_config but this was excellent information. When I see what kind of uid´s those people are guessing I can see that they're very unlikely to enter. And then again guessing the right password...

I think I'll tighten up the security by only allowing certain users though and disable root login.
The pubkey authentication sounds also very interesting.

Perhaps I should take a look at the shorewall, cause I must admit I stroke my chin more then one time, when manipulating my firewall rules. I don't have the whole blacklist thing either which sounds very convenient.

/Sören
 
I had a similar thing happening many years ago, and they eventually got in, but the bot was trying a buffer overflow exploit rather than random userids.

I saw the attempts at about 2 per day, and then they just went away. About a week later I saw that the exploit had been identified and a patch was available. But it was too late for me. I ended up rebuilding the box. Data was still good, but I couldn't trust any of the binaries.

I'd keep a statically linked copy of chkrootkit around, just in case.


pansophic
 
Does the server need to be accessible to the public via SSH? I'd start there.

You could check out Guardian, which works with Snort but could probably be adapted to work with a logging utility like LogDog or perhaps the Simple Event Correlator.
 
Personally I think the first idea (iptables rule) is the best option... I don't use it so can't remember the syntax, but surely someone here can provide it... or the documentation.

Annihilannic.
 
Firestarter by default puts some cool rules that limit the rate at which an IP can connect to your box. The look like this:

Code:
LOG        tcp  --  anywhere             anywhere            tcp \
    flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 LOG level info

You could easily tweak those to DROP instead of log and block those attempts dynamically in the IP stack.
 
thanks a lot for all your input. That is a lot of useful information.
I think I need to take the time to configure/secure the machine properly. It's not the most critical machine (just running some small web-apps), but why give them the possibility?

ericbrunson: how do you write that rule using iptables at the prompt? I guess I can figure it out by reading the manual, but...

/Sören
 
Something like "iptables -A rule specification" The rulespec can be many, many things, but my first posting contains a pretty complete spec for the limit rule.
 
Do you only ssh into your system from a limited number of networks? Create a rule to only allow ssh access from those networks.
 
I was browsing the web and came across a wiki with a sample python script that monitors ssh logins, and modifies iptables to ban the offending IPs for a period of time.

The author of the script built in behaviour that can be changed by editing variables in the script.

This wiki details some things using the gentoo distribution, but it doesn't look like it'd be difficult to use on another distro. He details on the wiki what all the configurable variables do in his script, so it would be a good starting point if people are interested.

It's located here.
 
Hardware firewall, blocking any and all ports that don't have services running. Especially PING.

Use IPTables to block all ports that don't have services running.

Use IPTabled and set a rule to block any traffic that isn't from a trusted computer (use IP and/or MAC address)... If you have a need to allow a block of IPs, do so.

All else fails, move SSH to run on a different port.

[plug=shameless]
[/plug]
 
If/when you move SSH off port 22, remember to adjust the hardware firewall and IPTables to block 22 and allow whatever port you've moved it to from trusted sources only.

[plug=shameless]
[/plug]
 
I long ago posted the same question


I think that the best and quicker solution is to move SSH to a different port

When you log in remember to use the

ssh -p xxxx host.domain

if you use scp

scp -P xxxx host.domain

I have not had any attack since.


Bye


Qatqat

Life is what happens when you are making other plans.
 
public Key authentication is another way to do it too. Then you can turn off password logins.
 
I didn't realize that moving it to another port would be a sollution. That is by far the easiest way for me to deal with this problem.
I always thought that these script-kiddies had automated portscanners looking through every port for open services... not just looking for known ports.
I'll give this a go... Very helpful input, so thanks again everybody.

/Sören
 
I think the advice of denying ping is very good too, since I have done that I didn't have any more attacks.

Kiddies sometimes just try pinging around to find a target, and then when they find one they start port-scans,...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top