Possible Intruder on my Server

z662

z662

Hello,

I am not sure if I am under attack but take a look at my auth.log using the command
Code: 
sudo cat auth.log | grep UNKNOWN

To clarify, I have disabled root login and it seems that the intruder is failing to sign in, however I have a rather restrictive firewall and was trying to figure out if by having the root login disabled that perhaps a cron job or ANYTHING might be causing this problem. Please let me know. (I say cron because you will notice the timing of the 'attacks')

Code: 
Dec 14 03:02:06 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 15 03:02:08 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 16 03:02:07 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 17 03:02:18 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 18 03:02:06 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 19 03:02:07 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 19 04:15:00 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 20 03:02:07 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 21 03:02:07 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 22 03:02:06 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 23 03:02:09 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 24 03:02:06 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 25 03:02:31 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 26 03:02:22 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 26 04:15:01 mercury nologin: Attempted login by root on UNKNOWN                                  
Dec 27 03:02:25 mercury nologin: Attempted login by root on UNKNOWN
 
How did you disable root login?

I am assuming you are using *only* the local password database for authentication (which is the default). If you use networked authentication (against a domain controller etc), disregard this post as I'm unsure if it could cause problems.

If you disabled it by setting roots shell to /bin/false or /usr/sbin/nologin, I'd recommend trying the following:
1) Set roots shell back to /bin/csh
2) Edit /etc/master.passwd. Locate the line starting with 'root', and change the second collumn to * (same as for user 'toor')
3) run the command [CMD="/usr/sbin/pwd_mkdb"]-p /etc/master.passwd -u root[/CMD]

This should still make it impossible to log in as root, since login facilities won't encode (md5, blf etc) a password into a string similar to "*". But it will let cron jobs and such run as root, since roots shell is now valid.

I hope that helps.
 
Yes you are correct, and yes I set it to /sbin/nologin. That is VERY interesting that you mention the cron job, as this is how I noticed it. Long story short my friend got his UBU box hacked and I tracked it down to a php5 exploit that was running as root in a cron job. I will do what you just typed. Will that however cause any problems, will that break sudo or any other unforseen (perhaps legit cron jobs etc.) What is the way to reverse that command if need be? Please elaborate more, I want to learn as much as possible in regards to what is going on. (I think the hacker checked the logs and found my IP as a result and started to focus on my box... you are certainly on the right track with what I did and why I disabled root in the first place. Thanks!
 
Eh, those certainly look like cron timestamps. From /etc/crontab:
Code: 
# Perform daily/weekly/monthly maintenance.
1       3       *       *       *       root    periodic daily
15      4       *       *       6       root    periodic weekly
30      5       1       *       *       root    periodic monthly
 
This looks like the time when periodic has finished running daily and weekly scripts. Not sure why it tries to 'login' though.
 
I gotta go to sleep now and I got work tomorrow but when I get home I am going to DEVOUR my log messages as well as my cron and see what I find....I'll post back tomorrow with my results.
 
IIRC, the cron jobs (legit or not) use the users shell when executing the commands.
Using the nologin shell will cause problems for the legit cron jobs, such as periodic daily and so on which is mentioned earlier in this thread.

If these error messages started showing up after you disabled root login, they don't really mean anything.
What you should rather do is the following:
[CMD="crontab"]-u root -l[/CMD]
and see if there are any foreign jobs listed.

You should also check the cron job of the user running the webserver (usually www), toor (uid0 user as powerfull as root, but login disabled by default, the way I described previously), and any other users which are running services.
 
I see, yeah I will check that out when I get out of work in 8 hours. Assuming there are no cron jobs that I need I should safely be able to disable root login completely with the above command you mentioned, for toor as well correct? How can I reverse that command to enable to root login if needed again? I hope, and kind of have a feeling that the 'intruder' is really just a failed cron job since I had disabled root via /sbin/nologin as a shell. Is this likely?
 
Also one more thing about disabling root login with the above method... By doing it that way as you said the cron jobs will be able to be performed successfully. My question then becomes, my logs will no longer record the failed attempts as you see above. Hence, how would I know that someone didnt exploit my system and set up a bad cron job. Will I be able to tell what should and shouldn't be there by
Code: 
crontab -u root -l
or will it be more difficult to weed out the good from the bad? Thanks
 
If someone is able to modify root's cron you have bigger problems. I wouldn't worry about it too much.
 
Where do you think your security problem lies? Local or remote?

If you trust the local environment of the server, just make sure the remote security is taken care of (e.g. no root logins over ssh, firewalling ssh, using only key-based authentication, disabling all unneeded exposed services etc.).

If it's a local problem, set a password on single-user mode and make sure the root password is strong enough; keep everyone out of the wheel group, and out of other core groups (operator, etc.) and sudo too. This will at least buy you time and alert you to suspicious activity.

You can take this to several levels (encryption, boot files on external media, piranhas, etc.).
 
Yeah I agree, I mean I am of the mindset that once you get hacked, you re format and start all over. I am just kinda concerned because I have a fully patched system and I really dont know what else to do to secure my system besides install an IDS. Although I know I should, I dont really have the time to keep up with the maintenance that one requires. I just have a rather restrictive firewall, ssh key authentication, disabled root (although not proper as of yet), and un needed daemons turned off. The reason this whole thing bothered me is because my friends UBU box (although of course not near as secure as a BSD system) got hacked via some php or mysql exploit (I can not be 100% sure of which) and then the there was a php5 cron job running as root. All of this was happening around the same time so I figured hed have my IP because I frequently ssh in. Then I noticed my logs containing the above entries in my first post. I hope I am just paranoid.
 
z662 said:
The reason this whole thing bothered me is because my friends UBU box (although of course not near as secure as a BSD system) got hacked via some php or mysql exploit (I can not be 100% sure of which) and then the there was a php5 cron job running as root.
Click to expand...
The most likely attack vector is a buggy web application. Forum and CMS software are notorious in that respect. Once they're able to inject code via that bug they would need to use a local root exploit too. All this can be quite easily mitigated, keep your software and your applications up to date. If you run a custom web application, audit the code. Make sure all input send from a client to the server is validated. Never, ever, trust anything a web client sends to your application. If a variable is supposed to be a number check if it's actually a number before shoveling that variable into an SQL query. Filter on the stuff you want and remove everything else.

Fact is about 95% percent of the servers that get hacked are hacked because of bugs in the web application, not the server/services (mysql, apache etc) itself.

With regards to running buggy forum and CMS software, you can get pwned just as quick on FreeBSD.
 
DutchDaemon said:
Where do you think your security problem lies? Local or remote?

If you trust the local environment of the server, just make sure the remote security is taken care of (e.g. no root logins over ssh, firewalling ssh, using only key-based authentication, disabling all unneeded exposed services etc.).

If it's a local problem, set a password on single-user mode and make sure the root password is strong enough; keep everyone out of the wheel group, and out of other core groups (operator, etc.) and sudo too. This will at least buy you time and alert you to suspicious activity.

You can take this to several levels (encryption, boot files on external media, piranhas, etc.).
Click to expand...


Local security is not an issue, I am the only one that uses my server locally. I am really just worried about a service being exploited. I frequently run freebsd-update and use portaudit all the time but there are occasional php vulnerabilities that I cannot patch which cause me concern sometimes. I have apache running, ssh running, and thats about it really....the only time portaudit complains is for php and since my friends server got hacked via php/mysql thats what I am leaning toward if there is ANY possible hack that took place.
 
SirDice said:
The most likely attack vector is a buggy web application. Forum and CMS software are notorious in that respect. Once they're able to inject code via that bug they would need to use a local root exploit too. All this can be quite easily mitigated, keep your software and your applications up to date. If you run a custom web application, audit the code. Make sure all input send from a client to the server is validated. Never, ever, trust anything a web client sends to your application. If a variable is supposed to be a number check if it's actually a number before shoveling that variable into an SQL query. Filter on the stuff you want and remove everything else.

Fact is about 95% percent of the servers that get hacked are hacked because of bugs in the web application, not the server/services (mysql, apache etc) itself.

With regards to running buggy forum and CMS software, you can get pwned just as quick on FreeBSD.
Click to expand...


Makes perfect sense, fortunately for me I don't really have any thing like that. I have php installed just because of a few simple pages, but the links arent public (I know thats not a REAL excuse) but I don't have any forums or anything that anyone would be able to find without writing a spider to find the links to, they are all nested deep in doc root. Also, all the code is rather simple and NONE of it involves allowing a web client to send data. This being the case does it seem like the auth.log results were just due to a failed cron job being executed due to improperly disabling root login?
 
Yeah I saw that probably about a week ago when I was looking for development documentation. I think I got the majority of all those down, other than the IDS...which I should really do anyways. It seems that I over reacted and was alarmed by the cron jobs. As I said before, the only question is really just interpreting the cron jobs from the good and bad. I have NOT modified the default cron. Can someone please tell me if this looks right for a 8.0 default install. *Note that this is the /etc/crontab file, if something else is needed please let me know. I just want to see if the below coincides with my output in the first post. Thanks in advance!
Code: 
# /etc/crontab - root's crontab for FreeBSD
#
# $FreeBSD: src/etc/crontab,v 1.33.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $
#
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
#
#minute	hour	mday	month	wday	who	command
#
*/5	*	*	*	*	root	/usr/libexec/atrun
#
# Save some entropy so that /dev/random can re-seed on boot.
*/11	*	*	*	*	operator /usr/libexec/save-entropy
#
# Rotate log files every hour, if necessary.
0	*	*	*	*	root	newsyslog
#
# Perform daily/weekly/monthly maintenance.
1	3	*	*	*	root	periodic daily
15	4	*	*	6	root	periodic weekly
30	5	1	*	*	root	periodic monthly
#
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time.  See adjkerntz(8) for details.
1,31	0-5	*	*	*	root	adjkerntz -a
 
Excellent, thanks everyone for helping me determine that I was in fact safe...just need to fix the root login part. I learned a lot in the process. On a sidenote I realized that it would probably be a good idea to up my kern.securelevel to 3 as the security thread states. Hopefully that wont cause problems....[LAST QUESTION] What is the recommended kern.securelevel for a PCBSD system, or FreeBSD system being used as a desktop? I need to read more up on them to see what the side effects are but both my server and desktop are all configured properly as I would like them, just dont want to up the kern.securelevel and find out that I shouldnt have done that later down the road when its too late cause something broke. :e
 
You can always lower the security level. But you do have to reboot for it, it cannot be done on-the-fly (as that would defeat it's purpose).
 
Yeah true, I guess I should just change it and monitor my logs, I will know if something needs it to be lowered due to the logs. If I dont see any issues then I will assume I am good to go. Reasonable approach?
 
Better yet. Thanks again to everyone that posted on this thread. As I said earlier I learned a great deal:)
 
You must log in or register to reply here.
Back
Top