server got compromised need help in reading audit.log
 

Dear all
I was observing some changes in one of my program so i decided to read the logs . throughout my search i didn't found any abnormal penetration inside my server . all of the logins were from my own trusted IP address but then when i read /var/log/audit/audit.log i found an ip address which does not belong to me and from what i understand i think it has got success in entering i have read a lot about it but cant find any clear answer. is there somebody who can help me out in reading the below log? (xxx represents my own ip address)

user pid=314 uid=0 auid=4294967295 msg='op=start direction=from-client cipher=aes128-ctr ksize=128 rport=36386 laddr=xxx.xxx.xxx.xxx lport=22 id=4294967295 exe="/usr/sbin/sshd" (hostname=?, addr=175.138.80.134, terminal=? res=success)'

If your system is broken into by a pro, one of the first things they usually do is install their own versions of administration programs that would report their existence. These versions work like the originals, except they don't report the hacker's presence.

Thanks for your input . I have also found a user inside /etc/passwd which have information like this but i dont know what it is used for
oprofile:x:16:16:Special user account to be used by OProfile:/home/oprofile:/sbin/nologin
I really want to learn what this log file says

The log entry means: a secure shell (ssh) connection from 175.138.80.134. If you look further you'll see if they succeeded in logging in.

Thank you so much for your input .i have 3 different ype of logs for the same ip address
Type 1=user_login in which the last line res=failed
Type2=user_auth the last line is res=failed
Type3=crypto session the last line says res=success
Whats the difference between these 3 ?
type=CRYPTO_SESSION msg=audit(1498552946.716:663727): user pid=6123 uid=0 auid=4294967295 msg='op=start direction=from-client cipher=aes128-ctr ksize=128 rport=36301 laddr=xxx.xxx.xxx.xxx lport=22 id=4294967295 exe="/usr/sbin/sshd" (hostname=?, addr=175.138.80.134, terminal=? res=success)'

https://www.tcpiputils.com/browse/ip...175.138.80.134 shows Malaysia.
That may or may not be "helpful". (I'm not asking where you at geographically speaking).

Thanks for your reply .yes i too have digged it and found that the ip is not from my place and its from malaysia .but the question is whats crypto_session ?is it the same like uuser_login and was he successful. in breaking into my server ?like i dont want to know what he did the only question is if this ip succeeded or not

I don't have an answer for that, it certainly appears like they got on the system.
I usually assume the worst and that is the position I take. But that is me.

Your experience and others may be different.

LQ Security References.
You should at the very least control access to port 22 on the "server". There are numerous methods.

Good Luck.

Once you are sure your system is clean (or have reloaded a clean, secure system) look into fail2ban please.

It will (ideally) detect multiple failed logon attempts and interact with your firewall to lock the source IP before they can brute-force a password and break in.

My systems have 78% of China,50% of Africa, 20% of Europe proper, 20% of Russia, 33% of South America, 10% of the U.S.A., two guys in Canada and one guy in Australia blocked right now.

In the log, user login failed. User authorization failed. But the system did set up a secure shell. That doesn't mean the hacker got in to your system. But you might want to block that IP. And, in doing system analysis, go to a good machine, copy the /bin directory to a CD (unwritable), and /usr/bin, /sbin/ /usr/sbin too.

Then set the path for the CD on the compromised? machine to the CD. You can't rely on the tools on that system. If you find anything wrong, you'll probably have to scrap the whole installation minus data files and configs.

Since you haven't mentioned (I don't think) the OS, all I has is text and a couple of links.
Strong ssh-key that you author with no password on it.
https://www.digitalocean.com/communi...on-a-linux-vps
http://www.cyberciti.biz/faq/tcp-wra...deny-tutorial/
https://ubuntuforums.org/showthread....6#post13459876

Add fail2ban and your are well on your way.

Let us know!

How are your backups? Tested? Recently?

How would anyone go about a successful SSH attack if:-

1) You don't use the default port of 22
2) You don't use a passphrase
3) You use a moderately secure key?

1. Moving the port makes you a harder target, but if someone gets network access anywhere that they can scan packets they will find you anyway. (Or if they have inside information.) Running nonstandard ports helps, but is not much more secure than the standard ones. (Filters out some of the criminal "script kiddies".

2. I think you mean "disallow password access", forcing key access. If you require pass phrases to use your keys, it does add a significant level of protection. This is unsuitable for using for automation, but for some accounts makes very good sense to USE pass phrases for your keys. Disabling passwords and requiring keys may be more secure in many cases and should not be discarded as an option. The greatest threat, if you have no software or service vulnerabilities, is the BRUTE FORCE attack using a dictionary based password generator. Fail2ban is one way to close that door, key-only access is another.

3. Moderately secure keys should be the minimum. I like 2K (2048 byte) keys myself, but check your software documentation before you try to go much larger to make sure that they are supported. DO NOT use keys below 1024 bytes if you can help it.

In all cases, if your software is not up to a patch level that closes vulnerability doors an attacker may be able to use that vulnerability to either gain access directly or corrupt other processes to gain access indirectly.
I recommend running rootkit detection and intrusion detection software and checking the logs daily. I also recommend regular and generational backups if you have any critical functions or data at all.

If someone is smart enough, focused enough, and you give them TIME enough, they WILL get in one way or another.
Deny them any vulnerable services you can, detect the attempts, and give them no TIME to succeed if possible. A focus on ONE service or vulnerability,ignoring all others, is as good as giving them a free detour into your data.

I don't know about that. My boxes that have SSH open on the default port get hit by a unique IP about every 10 minutes on average, 24/7. My boxes that have SSH open on a non-standard port get hit by unauthorized users literally never. Not once, in any of my logs, going back multiple years.

If you're being specifically targeted and the attacker knows your IP, no it doesn't really matter, but changing to a non-standard port filters out basically every other attacker out there.

I agree. I have had clients that were specifically targeted where it did not help much, but in all other cases it can help a lot. Like I said, it filters out the script kiddies. ;-)