Possible Hack Attempt

baddah · 09-25-2007, 02:53 AM

Hi,

I've notice the following in my /var/spool/mail/root file.This is just a smal part of the file,There's quite a few lines...

Code:

 pam_succeed_if(sshd:auth): error retrieving information about user ethan
 pam_succeed_if(sshd:auth): error retrieving information about user roxane
 pam_succeed_if(sshd:auth): error retrieving information about user anthony
 pam_succeed_if(sshd:auth): error retrieving information about user baptiste
 pam_succeed_if(sshd:auth): error retrieving information about user ryan
 pam_succeed_if(sshd:auth): error retrieving information about user carine
 pam_succeed_if(sshd:auth): error retrieving information about user nicholas
 pam_succeed_if(sshd:auth): error retrieving information about user emillie
 pam_succeed_if(sshd:auth): error retrieving information about user alexander
 pam_succeed_if(sshd:auth): error retrieving information about user pierre
 pam_succeed_if(sshd:auth): error retrieving information about user tyler
 pam_succeed_if(sshd:auth): error retrieving information about user lucie
 pam_succeed_if(sshd:auth): error retrieving information about user jamex
 pam_succeed_if(sshd:auth): error retrieving information about user serge
 pam_succeed_if(sshd:auth): error retrieving information about user james
 pam_succeed_if(sshd:auth): error retrieving information about user ferrell

Am i right that this looks like some attempted logins.Is there any way i can trace this?i.e what other files can i look at?

Thanks

tredegar · 09-25-2007, 03:37 AM

Have you read the "sticky" thread on this forum titled "Failed SSH login attempts " ?
It is long, but very informative.

mlnutt · 09-25-2007, 12:22 PM

Yes, somebody is trying to access your machine via ssh; this looks like an automated attack.

Take a look at /var/log/secure. It will show you the time and ip of the attempts.

If you change your ssh port to some off the wall port you can pretty much eliminate non-authorized ssh login attempts.

baddah · 09-26-2007, 07:33 AM

Hi,

Thanks for the replies.I've changed the SSH port and blocked all ports not getting used to the box(including port 22) on the firewall.Hopefully this will stop the bugger..

Hangdog42 · 09-26-2007, 08:25 AM

Quote:

Originally Posted by mlnutt

If you change your ssh port to some off the wall port you can pretty much eliminate non-authorized ssh login attempts.

I wish people would stop giving this advice. Security through obscurity only stops the least skilled script kiddies and does absolutely nothing to stop someone who actually has a clue.

What you really need to focus on is locking down SSH so that no matter what port it is on, it is difficult to crack. That means restricting users with the AllowUsers directive, or restricing IP addresses through hosts.allow and hosts.deny, or even better, moving to key-based authentication.

And at VERY least, make sure you've got good, strong passwords for ALL users if you must use password authentication.

unixfool · 09-26-2007, 10:54 AM

Quote:

Originally Posted by Hangdog42

I wish people would stop giving this advice. Security through obscurity only stops the least skilled script kiddies and does absolutely nothing to stop someone who actually has a clue.

I saw that post but decided to leave it alone and let the guys with 1000+ posts say something. To me, it was obvious that the advice wasn't quite sound, but people don't tend to listen to the people who aren't as active as others in the forums.

That said, I agree, a layered approach is best (as the sticky thread suggests).

OlRoy · 09-26-2007, 11:46 AM

Quote:

Originally Posted by Hangdog42

I wish people would stop giving this advice. Security through obscurity only stops the least skilled script kiddies and does absolutely nothing to stop someone who actually has a clue.

What you really need to focus on is locking down SSH so that no matter what port it is on, it is difficult to crack. That means restricting users with the AllowUsers directive, or restricing IP addresses through hosts.allow and hosts.deny, or even better, moving to key-based authentication.

And at VERY least, make sure you've got good, strong passwords for ALL users if you must use password authentication.

Security through obscurity can be an effective layer of security, the problem is when it's your only layer of security. Most attacks on the Internet are similar to a drive by. Skiddies and worms or botnets scanning for vulnerable services on the default port. So you can see by changing the port you can in fact reduce your risk which means you are more secure. Not having to worry about the most common type of attack is a good thing.

Camouflage is a form of security through obscurity and as you know, it is an important and effective layer. However, for example a tank doesn't just rely on camouflage (STO), it has armor, smoke screen, tactical maneuvers, offensive weapons, etc.

win32sux · 09-26-2007, 02:16 PM

For the record, suggesting that SSH should be changed to a non-default port is okay. I would just ask that anyone that does suggest this please make sure you mention that it is NOT a measure that will increase real security. It is indeed very effective at reducing the number of annoying brute-force attacks, but it does not in any way shape or form increase the real security of the box.

OlRoy · 09-26-2007, 02:46 PM

Quote:

Originally Posted by win32sux

For the record, suggesting that SSH should be changed to a non-default port is okay. I would just ask that anyone that does suggest this please make sure you mention that it is NOT a measure that will increase real security. It is indeed very effective at reducing the number of annoying brute-force attacks, but it does not in any way shape or form increase the real security of the box.

Anything that reduces risk, including STO is "real security." However, I think that we can agree that there is considerable residual risk after implementing a countermeasure like changing the port, which is why no one should advocate STO being the only countermeasure.

nomb · 09-26-2007, 03:04 PM

Changing the port of SSH is not increasing the security of SSH, but I would also say it is increasing the security of the box as a whole.

With that said, while doing everything already mentioned on here, I would also suggest using something like fail2ban. It works for SSH, among others, right out of the box. Basically, you pick the number of login attempts to allow. I have mine set to three, and a time period. When a hacker/script kiddie/bot/work/etc trys to login three times and fails, then their ip address is put into iptables to drop all packets from it for the time period specified. Mine is 3 attempts and 3 hours. I used to get attempts on my box all the time, and this was a huge help.

Quote:

Originally Posted by unixfool

I saw that post but decided to leave it alone and let the guys with 1000+ posts say something. To me, it was obvious that the advice wasn't quite sound, but people don't tend to listen to the people who aren't as active as others in the forums.

That said, I agree, a layered approach is best (as the sticky thread suggests).

Who cares how many posts you have. For all we know you are super duper admin of some hardcore security forum. If you have input, then, well, input it...

nomb

win32sux · 09-26-2007, 05:55 PM

Quote:

Originally Posted by OlRoy

Anything that reduces risk, including STO is "real security." However, I think that we can agree that there is considerable residual risk after implementing a countermeasure like changing the port, which is why no one should advocate STO being the only countermeasure.

I was not addressing any other countermeasure, only the port-change, which has never been intended to increase security in the first place. After doing the port-change, one is still vulnerable to the same security threats one was vulnerable to before the port-change (which is why you've suggested additional countermeasures). In other words, your camouflaged tank will be just as damaged as the black-colored one when it gets hit by an RPG. This needs to be made clear to anyone who is receiving this type of advice here, because if not, then we risk giving people a false sense of security - which is something we most definitely don't want to do. I know that security through obscurity is a hotly debated matter, it's all good. My only request is that we give people the whole picture when giving this type of advice. I believe you can do that without having to let go of your security through obscurity beliefs. Essentially, I'm just asking people to be more verbose if possible, that's all.

mlnutt · 09-27-2007, 11:44 AM

Changing the default port is one of the most effective measure one can do to minimize the number of attacks. This should be one of the first configuration changes made. Is this the only measure one should take? No. I didn't say it was.

Since changing my ssh port 2 years ago I've had zero (count them: zero) attempts to log onto ssh. Prior to that I had, on average, several a month. All of which were automated brute force attacks. Do I feel more secure? Yes. Am I invulnerable? No. Do I use other counter measures? Yes.

Always:

Change the port.
Don't permit root access.
Restrict use to authorized users/groups.
Restrict use of protocol version 1 and legacy support.
Use strong key based authentication.
Require strong passwords (and strong user names).
Keep the ssh server up to date.
Create detailed logs.

If possible:

Turn off the port when not needed.
Restrict access based on IP.
Require relaying in.
Detect probes and lock the IP out.
Detect unauthorized access attempts and lock the IP out.

unixfool · 09-27-2007, 01:16 PM

Analogy:

If someone were breaking into homes and a homeowner notices that most of the break-ins involved homes with black doors, would you paint your door white to avoid future break-ins? Or would you add a lock, an alarm, and buy a dog and/or gun? Which option has the most potential to lessen the impact of a break-in?

mlnutt · 09-27-2007, 02:36 PM

The black door/white door is a poor analogy at best.

Is it easier to open a *locked* door that you know where it is or a *locked* door that you don't know where it is? In order to knock you have to know where the door is.

If you are a soldier would you rather stand in an open field and yell "Here I am" when the enemy calls? Or would you hide and be quiet? *Of course* you always wear body armor and carry a gun. But you also try to conceal yourself.

Again, as I stated previously, changing the port is NOT the only thing one should do.

unixfool · 09-27-2007, 03:33 PM

Quote:

Originally Posted by mlnutt

The black door/white door is a poor analogy at best.

Is it easier to open a *locked* door that you know where it is or a *locked* door that you don't know where it is? In order to knock you have to know where the door is.

If you are a soldier would you rather stand in an open field and yell "Here I am" when the enemy calls? Or would you hide and be quiet? *Of course* you always wear body armor and carry a gun. But you also try to conceal yourself.

Again, as I stated previously, changing the port is NOT the only thing one should do.

I gave an example of a layered approach. I think the example sufficed, as I gave examples of several methods that enhance the house's security overall.

Changing a port to dodge brute force attempts just changes a port that could be found by an nmap scan. The port is still there, open to the world. Without using things such as key authentication, port knocking, allowing only authorized hosts and firewalling the rest...without additional solutions, changing the default port doesn't do much beyond keeping your logs clean (until someone actually actively searches for open ports before bruteforcing).

As a veteran soldier, I understand that cover and concealment are two different things. Cover protects...concealment doesn't, it just hides. Cover is a protected area, while concealment is a bush that a soldier can hide within. Concealment generally doesn't protect, although there are cases where an object can provide both cover AND concealment...changing a service to listen on a non-standard port won't necessarily protect.