server got compromised need help in reading audit.log
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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)
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.
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)'
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
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.
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.
Distribution: Debian testing/sid; OpenSuSE; Fedora; Mint
Posts: 5,524
Rep:
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.
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.
Running nonstandard ports helps, but is not much more secure than the standard ones.
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 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. ;-)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.