LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 09-25-2007, 01:53 AM   #1
baddah
Member
 
Registered: Feb 2006
Location: Cape Town,South Africa
Distribution: Fedora Core 8
Posts: 183

Rep: Reputation: 30
Possible Hack Attempt


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
 
Old 09-25-2007, 02:37 AM   #2
tredegar
LQ 5k Club
 
Registered: May 2003
Location: London, UK
Distribution: Debian "Jessie"
Posts: 6,017

Rep: Reputation: 369Reputation: 369Reputation: 369Reputation: 369
Have you read the "sticky" thread on this forum titled "Failed SSH login attempts " ?
It is long, but very informative.
 
Old 09-25-2007, 11:22 AM   #3
mlnutt
Member
 
Registered: May 2006
Posts: 34

Rep: Reputation: 15
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.
 
Old 09-26-2007, 06:33 AM   #4
baddah
Member
 
Registered: Feb 2006
Location: Cape Town,South Africa
Distribution: Fedora Core 8
Posts: 183

Original Poster
Rep: Reputation: 30
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..
 
Old 09-26-2007, 07:25 AM   #5
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,790
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
Originally Posted by mlnutt View Post
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.
 
Old 09-26-2007, 09:54 AM   #6
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by Hangdog42 View Post
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).
 
Old 09-26-2007, 10:46 AM   #7
OlRoy
Member
 
Registered: Dec 2002
Posts: 304

Rep: Reputation: 86
Quote:
Originally Posted by Hangdog42 View Post
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.
 
Old 09-26-2007, 01:16 PM   #8
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
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.
 
Old 09-26-2007, 01:46 PM   #9
OlRoy
Member
 
Registered: Dec 2002
Posts: 304

Rep: Reputation: 86
Quote:
Originally Posted by win32sux View Post
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.
 
Old 09-26-2007, 02:04 PM   #10
nomb
Member
 
Registered: Jan 2006
Distribution: Debian Testing
Posts: 675

Rep: Reputation: 58
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 View Post
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

Last edited by nomb; 09-26-2007 at 02:07 PM.
 
Old 09-26-2007, 04:55 PM   #11
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by OlRoy View Post
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.

Last edited by win32sux; 09-26-2007 at 05:33 PM.
 
Old 09-27-2007, 10:44 AM   #12
mlnutt
Member
 
Registered: May 2006
Posts: 34

Rep: Reputation: 15
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.
 
Old 09-27-2007, 12:16 PM   #13
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
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?
 
Old 09-27-2007, 01:36 PM   #14
mlnutt
Member
 
Registered: May 2006
Posts: 34

Rep: Reputation: 15
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.
 
Old 09-27-2007, 02:33 PM   #15
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by mlnutt View Post
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.

Last edited by unixfool; 09-27-2007 at 03:39 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Hack Attempt? keysorsoze Linux - Security 6 05-18-2007 11:32 PM
Apache logs - Hack attempt or not? lawadm1 Linux - Software 6 11-05-2004 11:53 PM
newbie question: do these logs show a hack attempt lucastic Linux - Security 4 08-13-2003 08:07 AM
not linux related, had a hack attempt neo77777 General 13 03-22-2002 04:57 PM
access.log:Possible Hack attempt? plisken Linux - Security 5 01-04-2002 02:40 PM


All times are GMT -5. The time now is 11:00 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration