Hello,
I was not reading my system logs regularly (that's bad!). Today I noticed the following:
---------- Rootkit Hunter 1.2.8 is running Sat, 21 Apr 2007 13:30:40 +0300 Determining OS... Ready
Checking binaries * Selftests Strings (command) [ OK ]
* System tools Info: prelinked files found Performing 'known good' check... /bin/cat [ BAD ] /bin/chmod [ BAD ] /bin/chown [ BAD ] /bin/date [ BAD ] /bin/dmesg [ BAD ] /bin/env [ BAD ] /bin/grep [ BAD ] /bin/kill [ BAD ] /bin/login [ BAD ] /bin/ls [ BAD ] /bin/more [ BAD ] /bin/mount [ BAD ] /bin/netstat [ BAD ] /bin/ps [ BAD ] /bin/su [ BAD ] /sbin/chkconfig [ BAD ] /sbin/depmod [ BAD ] /sbin/ifconfig [ BAD ] /sbin/init [ BAD ] /sbin/insmod [ BAD ] /sbin/ip [ BAD ] /sbin/lsmod [ BAD ] /sbin/modinfo [ BAD ] /sbin/modprobe [ BAD ] /sbin/rmmod [ BAD ] /sbin/runlevel [ BAD ] /sbin/sulogin [ BAD ] /sbin/sysctl [ BAD ] /sbin/syslogd [ BAD ] /usr/bin/chattr [ BAD ] /usr/bin/du [ BAD ] /usr/bin/file [ BAD ] /usr/bin/find [ BAD ] /usr/bin/head [ BAD ] /usr/bin/killall [ BAD ] /usr/bin/lsattr [ BAD ] /usr/bin/passwd [ BAD ] /usr/bin/pstree [ BAD ] /usr/bin/sha1sum [ BAD ] /usr/bin/stat [ BAD ] /usr/bin/top [ BAD ] /usr/bin/users [ BAD ] /usr/bin/vmstat [ BAD ] /usr/bin/w [ BAD ] /usr/bin/watch [ BAD ] /usr/bin/wc [ BAD ] /usr/bin/wget [ BAD ] /usr/bin/whereis [ BAD ] /usr/bin/who [ BAD ] /usr/bin/whoami [ BAD ] -------------------------------------------------------------------------------- Rootkit Hunter found some bad or unknown hashes. This can be happen due replaced binaries or updated packages (which give other hashes). Be sure your hashes are fully updated (rkhunter --update). If you're in doubt about these hashes, contact the author (fill in the contact form). --------------------------------------------------------------------------------
[Press <ENTER> to continue]
Check rootkits * Default files and directories Rootkit '55808 Trojan - Variant A'... [ OK ] ADM Worm... [ OK ] Rootkit 'AjaKit'... [ OK ] Rootkit 'aPa Kit'... [ OK ] Rootkit 'Apache Worm'... [ OK ] Rootkit 'Ambient (ark) Rootkit'... [ OK ] Rootkit 'Balaur Rootkit'... [ OK ] Rootkit 'BeastKit'... [ OK ] Rootkit 'beX2'... [ OK ] Rootkit 'BOBKit'... [ OK ] Rootkit 'CiNIK Worm (Slapper.B variant)'... [ OK ] Rootkit 'Danny-Boy's Abuse Kit'... [ OK ] Rootkit 'Devil RootKit'... [ OK ] Rootkit 'Dica'... [ OK ] Rootkit 'Dreams Rootkit'... [ OK ] Rootkit 'Duarawkz'... [ OK ] Rootkit 'Flea Linux Rootkit'... [ OK ] Rootkit 'FreeBSD Rootkit'... [ OK ] Rootkit 'Fuck`it Rootkit'... [ OK ] Rootkit 'GasKit'... [ OK ] Rootkit 'Heroin LKM'... [ OK ] Rootkit 'HjC Kit'... [ OK ] Rootkit 'ignoKit'... [ OK ] Rootkit 'ImperalsS-FBRK'... [ OK ] Rootkit 'Irix Rootkit'... [ OK ] Rootkit 'Kitko'... [ OK ] Rootkit 'Knark'... [ OK ] Rootkit 'Li0n Worm'... [ OK ] Rootkit 'Lockit / LJK2'... [ OK ] Rootkit 'MRK'... [ OK ] Rootkit 'Ni0 Rootkit'... [ OK ] Rootkit 'RootKit for SunOS / NSDAP'... [ OK ] Rootkit 'Optic Kit (Tux)'... [ OK ] Rootkit 'Oz Rootkit'... [ OK ] Rootkit 'Portacelo'... [ OK ] Rootkit 'R3dstorm Toolkit'... [ OK ] Rootkit 'RH-Sharpe's rootkit'... [ OK ] Rootkit 'RSHA's rootkit'... [ OK ] Sebek LKM [ OK ] Rootkit 'Scalper Worm'... [ OK ] Rootkit 'Shutdown'... [ OK ] Rootkit 'SHV4'... [ OK ] Rootkit 'SHV5'... [ OK ] Rootkit 'Sin Rootkit'... [ OK ] Rootkit 'Slapper'... [ OK ] Rootkit 'Sneakin Rootkit'... [ OK ] Rootkit 'Suckit Rootkit'... [ OK ] Rootkit 'SunOS Rootkit'... [ OK ] Rootkit 'Superkit'... [ OK ] Rootkit 'TBD (Telnet BackDoor)'... [ OK ] Rootkit 'TeLeKiT'... [ OK ] Rootkit 'T0rn Rootkit'... [ OK ] Rootkit 'Trojanit Kit'... [ OK ] Rootkit 'Tuxtendo'... [ OK ] Rootkit 'URK'... [ OK ] Rootkit 'VcKit'... [ OK ] Rootkit 'Volc Rootkit'... [ OK ] Rootkit 'X-Org SunOS Rootkit'... [ OK ] Rootkit 'zaRwT.KiT Rootkit'... [ OK ]
* Suspicious files and malware Scanning for known rootkit strings [ OK ] Scanning for known rootkit files [ OK ] Testing running processes... [ OK ] Miscellaneous Login backdoors [ OK ] Miscellaneous directories [ OK ] Software related files [ OK ] Sniffer logs [ OK ]
[Press <ENTER> to continue]
* Trojan specific characteristics shv4 Checking /etc/rc.d/rc.sysinit Test 1 [ Clean ] Test 2 [ Clean ] Test 3 [ Clean ] Checking /etc/inetd.conf [ Not found ] Checking /etc/xinetd.conf [ Skipped ]
* Suspicious file properties chmod properties Checking /bin/ps [ Clean ] Checking /bin/ls [ Clean ] Checking /usr/bin/w [ Clean ] Checking /usr/bin/who [ Clean ] Checking /bin/netstat [ Clean ] Checking /bin/login [ Clean ] Script replacements Checking /bin/ps [ Clean ] Checking /bin/ls [ Clean ] Checking /usr/bin/w [ Clean ] Checking /usr/bin/who [ Clean ] Checking /bin/netstat [ Clean ] Checking /bin/login [ Clean ]
* OS dependant tests
Linux Checking loaded kernel modules... [ OK ] Checking files attributes [ OK ] Checking LKM module path [ OK ]
Networking * Check: frequently used backdoors Port 2001: Scalper Rootkit [ OK ] Port 2006: CB Rootkit [ OK ] Port 2128: MRK [ OK ] Port 14856: Optic Kit (Tux) [ OK ] Port 47107: T0rn Rootkit [ OK ] Port 60922: zaRwT.KiT [ OK ]
* Interfaces Scanning for promiscuous interfaces [ OK ]
[Press <ENTER> to continue]
System checks * Allround tests Checking hostname... Found. Hostname is hst-1-98.siriusbg.com Checking for passwordless user accounts... OK Checking for differences in user accounts... OK. No changes. Checking for differences in user groups... OK. No changes. Checking boot.local/rc.local file... - /etc/rc.local [ OK ] - /etc/rc.d/rc.local [ OK ] - /usr/local/etc/rc.local [ Not found ] - /usr/local/etc/rc.d/rc.local [ Not found ] - /etc/conf.d/local.start [ Not found ] - /etc/init.d/boot.local [ Not found ] Checking rc.d files... Processing........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ ........................................ .................................... Result rc.d files check [ OK ] Checking history files Bourne Shell [ OK ]
* Filesystem checks Checking /dev for suspicious files... [ OK ] Scanning for hidden files... [ Warning! ] --------------- /dev/.udev /etc/.pwd.lock --------------- Please inspect: /dev/.udev (directory)
[Press <ENTER> to continue]
Application advisories * Application scan Checking Apache2 modules ... [ Not found ] Checking Apache configuration ... [ OK ]
Security advisories * Check: Groups and Accounts Searching for /etc/passwd... [ Found ] Checking users with UID '0' (root)... [ OK ]
* Check: SSH Searching for sshd_config... Found /etc/ssh/sshd_config Checking for allowed root login... [ OK (Remote root login disabled) ] Checking for allowed protocols... [ OK (Only SSH2 allowed) ]
* Check: Events and Logging Search for syslog configuration... [ OK ] Checking for running syslog slave... [ OK ] Checking for logging to remote system... [ OK (no remote logging) ]
[Press <ENTER> to continue]
---------------------------- Scan results ----------------------------
MD5 MD5 compared: 50 Incorrect MD5 checksums: 50
File scan Scanned files: 342 Possible infected files: 0
Application scan Scanning took 905 seconds
------------------- Sat, 21 Apr 2007 13:45:45 +0300 -------------------
Do you have some problems, undetected rootkits, false positives, ideas or suggestions? Please e-mail me by filling in the contact form (@http://www.rootkit.nl)
-----------------------------------------------------------------------
In the logs I found exactly the same results since one month ago.
Does that mean I have been hacked and all those binaries are replaced? The secure logs are full with unaccepted ssh connections. The only successful connections for this period are from a known IP, but unfortunately I have no older logs.
Thanks for any clues!
Regards, Peter home site: http://bgwebdeveloper.com
peter kostov wrote:
Hello,
I was not reading my system logs regularly (that's bad!). Today I noticed the following:
Install logwatch.
[snip]
In the logs I found exactly the same results since one month ago.
Does that mean I have been hacked and all those binaries are replaced? The secure logs are full with unaccepted ssh connections. The only successful connections for this period are from a known IP, but unfortunately I have no older logs.
Doesn't look like that. Any way, I didn't read in all your mail witch version of FC you were running, and if you have upgrades up2date.
I wouldn't worry so much. But get logwatch running right away.
Martin Marques wrote:
peter kostov wrote:
Hello,
I was not reading my system logs regularly (that's bad!). Today I noticed the following:
Install logwatch.
[snip]
In the logs I found exactly the same results since one month ago.
Does that mean I have been hacked and all those binaries are replaced? The secure logs are full with unaccepted ssh connections. The only successful connections for this period are from a known IP, but unfortunately I have no older logs.
Doesn't look like that. Any way, I didn't read in all your mail witch version of FC you were running, and if you have upgrades up2date.
I am running FC5 with yum enabled.
I wouldn't worry so much. But get logwatch running right away.
I have logwatch installed, but I didn't know about it. Thanks for pointing it out!
On the other machine in my local network there is one 'bad' binary reported by rkhunter - wget. This second computer accesses the Internet through the one we are discussing. It is also running FC5 with yum, although the installation isn't exactly the same.
Peter
On Saturday 21 April 2007, peter kostov wrote:
I have logwatch installed, but I didn't know about it. Thanks for pointing it out!
In /etc/aliases, near the bottom, you'll see a line that you should edit:
# Person who should get root's mail root: you@your.email.address
You'll then get a daily report of anything important happening.
Anne
Anne Wilson escribió:
On Saturday 21 April 2007, peter kostov wrote:
I have logwatch installed, but I didn't know about it. Thanks for pointing it out!
In /etc/aliases, near the bottom, you'll see a line that you should edit:
# Person who should get root's mail root: you@your.email.address
You'll then get a daily report of anything important happening.
Actually, he should really start by editing /etc/log.d/logwatch.conf. :-)
On Saturday 21 April 2007, Martin Marques wrote:
Anne Wilson escribió:
On Saturday 21 April 2007, peter kostov wrote:
I have logwatch installed, but I didn't know about it. Thanks for pointing it out!
In /etc/aliases, near the bottom, you'll see a line that you should edit:
# Person who should get root's mail root: you@your.email.address
You'll then get a daily report of anything important happening.
Actually, he should really start by editing /etc/log.d/logwatch.conf. :-)
What do you have in mind? And do you mean /etc/logwatch/conf/logwatch.conf?
Anne
El Sábado, 21 de Abril de 2007 23:17, Anne Wilson escribió:
On Saturday 21 April 2007, Martin Marques wrote:
Anne Wilson escribió:
On Saturday 21 April 2007, peter kostov wrote:
I have logwatch installed, but I didn't know about it. Thanks for pointing it out!
In /etc/aliases, near the bottom, you'll see a line that you should edit:
# Person who should get root's mail root: you@your.email.address
You'll then get a daily report of anything important happening.
Actually, he should really start by editing /etc/log.d/logwatch.conf. :-)
What do you have in mind? And do you mean /etc/logwatch/conf/logwatch.conf?
Anne
The fact is, if you were hacker, doing all those things people posted here, you would probaby deleted any proof which could help in a forensics proccess. You should had done all that from a live cd or similar. This is my point of view.
Anne Wilson escribió:
On Saturday 21 April 2007, Martin Marques wrote:
Actually, he should really start by editing /etc/log.d/logwatch.conf. :-)
What do you have in mind? And do you mean /etc/logwatch/conf/logwatch.conf?
In logwatch.conf you set up various settings and who will recieve the mail. :-)
BTW, sorry for the PATH copnfusion, but I was looking at an old FC3 system, which has the logwatch.conf in /etc/log.d/
peter kostov wrote:
Martin Marques wrote:
peter kostov wrote:
Hello,
I was not reading my system logs regularly (that's bad!). Today I noticed the following:
Install logwatch.
[snip]
In the logs I found exactly the same results since one month ago.
Does that mean I have been hacked and all those binaries are replaced? The secure logs are full with unaccepted ssh connections. The only successful connections for this period are from a known IP, but unfortunately I have no older logs.
Doesn't look like that. Any way, I didn't read in all your mail witch version of FC you were running, and if you have upgrades up2date.
I am running FC5 with yum enabled.
I wouldn't worry so much. But get logwatch running right away.
I have logwatch installed, but I didn't know about it. Thanks for pointing it out!
On the other machine in my local network there is one 'bad' binary reported by rkhunter - wget. This second computer accesses the Internet through the one we are discussing. It is also running FC5 with yum, although the installation isn't exactly the same.
Peter
Two things: I don't get any 'bad' binaries when I run chkrootkit, so I would suspect problems when I see results like yours.
You can also also use RPM to check the same files. For example, to check wget:
$ type wget wget is hashed (/usr/bin/wget) $ rpm -qf /usr/bin/wget wget-1.10.2-8.fc6.1 $ rpm -V wget $
You can also use "rpm -Vv wget" if you want to see what RPM is doing, instead of it returning with no message if everything matches.
I would run "rpm -V coreutils" on the system as a first step. If it reports files that do not match, I would back up your data, wipe, and re-install! (If it does not find anything, then ether it was a smart attacker, or you are safe...)
Mikkel
peter kostov escribió:
I have logwatch installed, but I didn't know about it. Thanks for pointing it out!
Configure it and make it run. It helps alot!
On the other machine in my local network there is one 'bad' binary reported by rkhunter - wget. This second computer accesses the Internet through the one we are discussing. It is also running FC5 with yum, although the installation isn't exactly the same.
I personally see it very hard for an updated Linux system (any distribution that has updates of security issues) to get hacked. Normally you will see hacked servers due to outdated sshd or apache (but specially sshd), but not in an up2date system.
Verily I say unto thee, that Martin Marques spake thusly:
peter kostov escribió:
I have logwatch installed, but I didn't know about it. Thanks for pointing it out!
Configure it and make it run. It helps alot!
AFAIK the default Fedora setup is to install and run logwatch using cron, every day at 4:02am.
There should be a file:
/etc/cron.daily/0logwatch
If it's there, and crontab contains an entry for cron.daily, then that should be all the configuring it needs.
I personally see it very hard for an updated Linux system (any distribution that has updates of security issues) to get hacked. Normally you will see hacked servers due to outdated sshd or apache (but specially sshd), but not in an up2date system.
I have hundreds off ssh attacks every day. Just make sure you have a *very* secure password (or don't forward ssh from the router).
I also use "denyhosts" which I've found extremely useful (it's in extras).
El Domingo, 22 de Abril de 2007 02:50, Keith G. Robertson-Turner escribió:
I have hundreds off ssh attacks every day. Just make sure you have a *very* secure password (or don't forward ssh from the router).
I also use "denyhosts" which I've found extremely useful (it's in extras).
That plus some kind of app such as fail2ban to permit only like like 3 attemps of login, and if the bot, (usually those kinds of bruteforce attacks are made by bots) fails more than 3 times the password, its IP will be banned for a period of time you can set up in the config file of fail2ban, for instance.
Usually if your box is not being used as a production server or is a corporate server where lot of people work in, changing the sshd port would be an effective solution, indeed.
Just my two cents. All the best.
Verily I say unto thee, that Manuel Arostegui Ramirez spake thusly:
El Domingo, 22 de Abril de 2007 02:50, Keith G. Robertson-Turner escribió:
I have hundreds off ssh attacks every day. Just make sure you have a *very* secure password (or don't forward ssh from the router).
I also use "denyhosts" which I've found extremely useful (it's in extras).
That plus some kind of app such as fail2ban to permit only like like 3 attemps of login
Denyhosts already does that.
I'll check out fail2ban though, it's always nice to have alternatives.
On Apr 22 Keith G. Robertson-Turner did spake thusly:
Verily I say unto thee, that Manuel Arostegui Ramirez spake thusly:
El Domingo, 22 de Abril de 2007 02:50, Keith G. Robertson-Turner escribió:
I have hundreds off ssh attacks every day. Just make sure you have a *very* secure password (or don't forward ssh from the router).
I also use "denyhosts" which I've found extremely useful (it's in extras).
That plus some kind of app such as fail2ban to permit only like like 3 attemps of login
Denyhosts already does that.
I'll check out fail2ban though, it's always nice to have alternatives.
iptables -I INPUT -p tcp --dport 22 -i $EXTIF -m state --state NEW -m \ recent --set iptables -I INPUT -p tcp --dport 22 -i $EXTIF -m state --state NEW -m \ recent --update --seconds 60 --hitcount 4 -j DROP
This'll drop anything over 4 connections from an IP within 60 seconds - might also be of use for an SSH attack
Verily I say unto thee, that Scott van Looy spake thusly:
On Apr 22 Keith G. Robertson-Turner did spake thusly:
Verily I say unto thee, that Manuel Arostegui Ramirez spake thusly:
El Domingo, 22 de Abril de 2007 02:50, Keith G. Robertson-Turner escribió:
I have hundreds off ssh attacks every day. Just make sure you have a *very* secure password (or don't forward ssh from the router).
I also use "denyhosts" which I've found extremely useful (it's in extras).
That plus some kind of app such as fail2ban to permit only like like 3 attemps of login
Denyhosts already does that.
I'll check out fail2ban though, it's always nice to have alternatives.
iptables -I INPUT -p tcp --dport 22 -i $EXTIF -m state --state NEW -m \ recent --set iptables -I INPUT -p tcp --dport 22 -i $EXTIF -m state --state NEW -m \ recent --update --seconds 60 --hitcount 4 -j DROP
This'll drop anything over 4 connections from an IP within 60 seconds - might also be of use for an SSH attack
Good tip.
However, denyhosts is primarily used for failed *logins* (no such user, wrong password, etc.), rather than the above, which is really DDoS protection.
My router already handles the DDoS stuff.
Scott van Looy wrote:
On Apr 22 Keith G. Robertson-Turner did spake thusly:
Verily I say unto thee, that Manuel Arostegui Ramirez spake thusly:
El Domingo, 22 de Abril de 2007 02:50, Keith G. Robertson-Turner escribió:
I have hundreds off ssh attacks every day. Just make sure you have a *very* secure password (or don't forward ssh from the router).
I also use "denyhosts" which I've found extremely useful (it's in extras).
That plus some kind of app such as fail2ban to permit only like like 3 attemps of login
Denyhosts already does that.
I'll check out fail2ban though, it's always nice to have alternatives.
iptables -I INPUT -p tcp --dport 22 -i $EXTIF -m state --state NEW -m \ recent --set iptables -I INPUT -p tcp --dport 22 -i $EXTIF -m state --state NEW -m \ recent --update --seconds 60 --hitcount 4 -j DROP
This'll drop anything over 4 connections from an IP within 60 seconds
- might also be of use for an SSH attack
Thanks, I will use this! I think this is simpler and better than installing additional software like fail2ban, isn't it? Peter
On Sat, Apr 21, 2007 at 10:04:20PM +0300, peter kostov wrote:
On the other machine in my local network there is one 'bad' binary reported by rkhunter - wget. This second computer accesses the Internet through the one we are discussing. It is also running FC5 with yum, although the installation isn't exactly the same.
Peter
rkhunter is slightly dumb when it comes to the system binaries. They have been modified by the "prelink" process in Fedora, and thus don't match the distributed MD5sums.
The fact that you don't have any other indications of an infection is good.
I prefer chkrootkit to rkhunter, because it desn't depend on the binaries prelinking messes up.
Wolfe
peter kostov wrote:
On the other machine in my local network there is one 'bad' binary reported by rkhunter - wget. This second computer accesses the Internet through the one we are discussing.
I think that the FC maintainer for rkhunter is no more. I seem to remember that there was a bad hash for one of my FC5 binaries for a while (maybe 3 weeks). Then an rkhunter update of its database cleaed it out. Soon thereafter, there was a wget package update, and wget was broken. For about 2 days, then another update of rkhunter's database cleared that up. The next day there was another update of wget that was released. rkhunter has been complaining to me ever since. I seem to remember there is a BZ open against rkhunter, but it is maintainerless at the moment. I think all it needs is for someone to contact the rkhunter upstream development team and supply them with the current wget binary hash.
It is also running FC5 with yum, although the installation isn't exactly the same.
Someone else mentioned that rkhunter stumbles over pre-linked binaries. No it doesn't. The version of rkhunter in Fedora Core Extras was modified to work correctly with pre-linked binaries. What's broken is supplying the correct hashes for the newer packages back to the ODs so they can put them in their database which rkhunter can then download when it needs to.
Peter
-
Anne Wilson -
G.Wolfe Woodbury -
Keith G. Robertson-Turner -
Kevin Cummings -
Manuel Aróstegui -
Martin Marques -
Mikkel -
peter kostov -
Scott van Looy