My home system has been hacked. It's running CentOS 4.4, and I recently added an account to play around with Samba shares to back up PCs here at home. I had set a weak password for that account and forgot to disable it after my testing. I could hear the disk being accessed constantly, so I knew something was up. I disabled the port forwarding to my CentOS box on my Linksys router (only ports 22 and 80 were being forwarded). After some poking around, I found the following files in the directory "/var/tmp/ /.. ":
-rw-rw-r-- 1 backup backup 9468 Dec 1 00:20 azi2.seen -rw-rw-r-- 1 backup backup 9513 Dec 1 00:20 azi3.seen -rw-rw-r-- 1 backup backup 9513 Dec 1 00:20 azi4.seen -rwxr-xr-x 1 backup backup 504464 Feb 10 2005 -bash -rwx--x--x 1 backup backup 22936 Feb 10 2005 kswap.help -rw-r--r-- 1 backup backup 1085 Dec 1 00:00 kswap.levels -rw------- 1 backup backup 5 Nov 29 17:28 kswap.pid -rw-r--r-- 1 backup backup 1480 Dec 1 00:00 kswap.session -rw-r--r-- 1 backup backup 4731 Dec 25 2005 kswap.set -rw-r--r-- 1 backup backup 165073 Dec 1 00:26 LinkEvents -rw-r--r-- 1 backup backup 258 Dec 1 00:00 mech2.users -rw-r--r-- 1 backup backup 258 Dec 1 00:00 mech3.users -rw-r--r-- 1 backup backup 258 Dec 1 00:00 mech4.users -rw-r--r-- 1 backup backup 258 Jun 28 1999 mech.users -rwxr-xr-x 1 backup backup 174396 May 17 2004 pico
Anyone recognize this root kit (if that is what it is)? I've disabled the backup account, and re-enabled port forwarding on my router (so I can access the system from home). Other than deleting these files, is there anything else I should worry about? I'd rather not re-install the OS...
Alfred
Alfred von Campe wrote:
My home system has been hacked. It's running CentOS 4.4, and I recently added an account to play around with Samba shares to back up PCs here at home. I had set a weak password for that account and forgot to disable it after my testing. I could hear the disk being accessed constantly, so I knew something was up. I disabled the port forwarding to my CentOS box on my Linksys router (only ports 22 and 80 were being forwarded).
if for sure only 22 and 80 were forwarded, then it wasn't Samba.
There's no default account I see here on my 4.4 boxes named backup, was that something you'd created? some package you'd installed?
what was on your website? any canned php scripting or whatever?
re: cleanup... look very carefully for directories in odd places with . names
I'd run rkhunter to see if tehre's any other well known root kits on your system.
On Thu, 2006-11-30 at 22:12 -0800, John R Pierce wrote:
Alfred von Campe wrote:
My home system has been hacked. It's running CentOS 4.4, and I recently added an account to play around with Samba shares to back up PCs here at home. I had set a weak password for that account and forgot to disable it after my testing. I could hear the disk being accessed constantly, so I knew something was up. I disabled the port forwarding to my CentOS box on my Linksys router (only ports 22 and 80 were being forwarded).
if for sure only 22 and 80 were forwarded, then it wasn't Samba.
Right ... however, if a weak account/passwd was created in useradd (for backups) and if something was not done to prevent ssh logins for that user, then someone may have logged into ssh via that account and port 22.
In this case (if the user you created for samba shares was "backup") then this is what happened.
There are many ways to combat this specific issue (use key only logins to ssh, etc.). But the simplest way I have found (if you want password access) is to use the AllowGroups option in /etc/ssh/sshd_config.
AllowGroups sshusers
That will make it so only people in the group sshusers can ssh in.
If you do that, create the group sshusers, and add only those accounts that you want to have ssh access to the sshusers group you will make it so any new test accounts you create do not allow ssh login by default (only if you also add them to the sshusers group).
I would also highly recommend that you do not use port 22 for ssh from the outside ... pick a non standard port (like 3333 or 22222, etc.) and add this option as well to sshd_config
port 22 port 3333
You can then port forward port 3333 from linksys to 3333 on your centos machine ... you can ssh in via that port from outside and still use port 22 from inside your firewall (via other machines inside your firewall). (you will also need to open up port 3333 tcp on iptables if you have iptables on).
There's no default account I see here on my 4.4 boxes named backup, was that something you'd created? some package you'd installed?
what was on your website? any canned php scripting or whatever?
That is also a possibility. Many php CMSs are horrible and allow access to many issue by default. SELinux can be your friend if properly configured ... as well, a program called mod_security can be affective.
If backup was the sambe user, then this was probably not the entry point in this case.
re: cleanup... look very carefully for directories in odd places with . names
I'd run rkhunter to see if tehre's any other well known root kits on your system.
rkhunter and / or chkrootkit ... both good things.
Another thing to worry about is that once a user is logged in on that machine and in, they may try to use a local use exploit to gain root privileges. So, you need to proceed assuming that they logged in as backup ... and exploited to get a root shell ... and had access to everything.
That would mean that you need to either reinstall or do:
rpm -V -qa
and figure out everything that is different and verify that you do not have binary files for things like top, ps that have been modified to hide certain things.
Reinstall, that is my advise.
Right ... however, if a weak account/passwd was created in useradd (for backups) and if something was not done to prevent ssh logins for that user, then someone may have logged into ssh via that account and port 22.
Yes, this is what happened. I have set the shell to /sbin/nologin for that account now, something I neglected to do when I created it.
There are many ways to combat this specific issue (use key only logins to ssh, etc.). But the simplest way I have found (if you want password access) is to use the AllowGroups option in /etc/ssh/sshd_config.
AllowGroups sshusers
That will make it so only people in the group sshusers can ssh in.
Excellent idea, I'll do this.
I would also highly recommend that you do not use port 22 for ssh from the outside ... pick a non standard port (like 3333 or 22222, etc.) and add this option as well to sshd_config
port 22 port 3333
You can then port forward port 3333 from linksys to 3333 on your centos machine ... you can ssh in via that port from outside and still use port 22 from inside your firewall (via other machines inside your firewall). (you will also need to open up port 3333 tcp on iptables if you have iptables on).
What about simply forwarding a non standard port from my Linksys router to port 22 on my CentOS system? This way I wouldn't have to reconfigure anything except for the router itself.
rkhunter and / or chkrootkit ... both good things.
I'll get them and run them when I get back home tonight or over the weekend.
Another thing to worry about is that once a user is logged in on that machine and in, they may try to use a local use exploit to gain root privileges. So, you need to proceed assuming that they logged in as backup ... and exploited to get a root shell ... and had access to everything.
This is what I am worried about.
That would mean that you need to either reinstall or do:
rpm -V -qa
and figure out everything that is different and verify that you do not have binary files for things like top, ps that have been modified to hide certain things.
I ran this and will go over the output tonight.
Reinstall, that is my advise.
That's what I've done in the past too, but I am trying to avoid that option if possible.
Thanks for the quick response and advice.
Alfred
Alfred von Campe wrote:
Reinstall, that is my advise.
That's what I've done in the past too, but I am trying to avoid that option if possible.
I'd opt for reinstallation also, as you normall never can really find out *what* has been changed, if there is/was an active rootkit on that machine.
for package in $(rpm -qa); do echo -e "${package}"; rpm -V "${package}"; done
might be of help, also. If rpm didn't get exchanged. If the active rootkit doesn't intercept that. And so on ...
Ralph
On 12/1/06, Ralph Angenendt ra+centos@br-online.de wrote:
I'd opt for reinstallation also, as you normall never can really find out *what* has been changed, if there is/was an active rootkit on that machine.
for package in $(rpm -qa); do echo -e "${package}"; rpm -V "${package}"; done
When I run this I get an error message similar to the following for a bunch of the files:
prelink: /lib/tls/i486/libdb-4.2.so: at least one of file's dependencies has changed since prelinking
I deleted /etc/prelink.cache and manually reran /etc/cron.daily/prelink but I still get the same thing. Anyone have any ideas? I'm pretty I didn't get this problem with rpm -V in the past. Also, this is a Centos4 box yummed up to the latest stuff.
Thanks, Kennedy
On Fri, 2006-12-01 at 07:31 -0500, Alfred von Campe wrote: <snip>
I would also highly recommend that you do not use port 22 for ssh from the outside ... pick a non standard port (like 3333 or 22222, etc.) and add this option as well to sshd_config
port 22 port 3333
You can then port forward port 3333 from linksys to 3333 on your centos machine ... you can ssh in via that port from outside and still use port 22 from inside your firewall (via other machines inside your firewall). (you will also need to open up port 3333 tcp on iptables if you have iptables on).
What about simply forwarding a non standard port from my Linksys router to port 22 on my CentOS system? This way I wouldn't have to reconfigure anything except for the router itself.
If you linksys will do that, yes it is perfect ... mine has very limited port forwarding capability ... it only forwards a port (say 22) to the same port on one machine.
No way to set more than 1 external IP or port forward 3333 -> 22 ... 3333 -> 3333 only and 22 -> 22 only. That is how mine works :(
Thanks for all your suggestions. I'll be trying them out over the weekend. At first glance, it doesn't appear that they gained root access.
Is there any sense in reporting this? I have the IP addresses from which they logged in.
Alfred
Alfred von Campe wrote:
Thanks for all your suggestions. I'll be trying them out over the weekend. At first glance, it doesn't appear that they gained root access.
I would recommend a reinstall anyway.
Is there any sense in reporting this? I have the IP addresses from which they logged in.
yes! find out the owner of the ip netblock and report it, its possible that the machine itself might be hacked.
- KB
Depends on the IP address. If it came from an ISP here in the US (assuming you are here in the US), then sure submit it to the proper admins of those networks. If the IP is outside of the US, then I wouldn't bother as e-mailing an admin from another country is useless unless you speak their language.
Then again, some ISPs are so flooded with abuse complaints, it might not be worth it to you.
On 12/1/06, Alfred von Campe alfred@110.net wrote:
Thanks for all your suggestions. I'll be trying them out over the weekend. At first glance, it doesn't appear that they gained root access.
Is there any sense in reporting this? I have the IP addresses from which they logged in.
Alfred
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Quoting Joshua Zukerman hawk82@gmail.com:
If the IP is outside of the US, then I wouldn't bother as e-mailing an admin from another country is useless unless you speak their language.
Let me assure you that even admins in Quebec will speak English. Not always to Americans. But with most other people around the world they will. I heard it has something to do with the attitude you showed in the quoted email (see above).
On Fri, 01 Dec 2006 14:01:54 -0600 Aleksandar Milivojevic alex@8-p.ca wrote:
Quoting Joshua Zukerman hawk82@gmail.com:
If the IP is outside of the US, then I wouldn't bother as e-mailing an admin from another country is useless unless you speak their language.
Let me assure you that even admins in Quebec will speak English. Not always to Americans. But with most other people around the world they will. I heard it has something to do with the attitude you showed in the quoted email (see above).
I have stopped reporting breakin attempts to any ISP outside the UK. It would appear from this and previous posts that, if the breakin came from an ISP's IP range in one's own country then something may get done, otherwise, forget it.
BTW I run fail2ban on all my servers, CentOS and Debian, and set to permanently ban after 3 attempts.
On 12/1/06, Aleksandar Milivojevic alex@8-p.ca wrote:
Quoting Joshua Zukerman hawk82@gmail.com:
If the IP is outside of the US, then I wouldn't bother as e-mailing an admin from another country is useless unless you speak their language.
Let me assure you that even admins in Quebec will speak English. Not always to Americans. But with most other people around the world they will. I heard it has something to do with the attitude you showed in the quoted email (see above).
First I have relatives that know little to no English. Second I have traveled to Europe, Asia, and Africa for both business and pleasure.
Now I have to ask how many people would even attempt to understand an e-mail in an unknown language?
Leonard Isham spake the following on 12/2/2006 9:15 PM:
On 12/1/06, Aleksandar Milivojevic alex@8-p.ca wrote:
Quoting Joshua Zukerman hawk82@gmail.com:
If the IP is outside of the US, then I wouldn't bother as e-mailing an admin from another country is useless unless you speak their language.
Let me assure you that even admins in Quebec will speak English. Not always to Americans. But with most other people around the world they will. I heard it has something to do with the attitude you showed in the quoted email (see above).
First I have relatives that know little to no English. Second I have traveled to Europe, Asia, and Africa for both business and pleasure.
Now I have to ask how many people would even attempt to understand an e-mail in an unknown language?
But a major ISP should have at a minimum resources to translate messages to their abuse address. You could cut and paste into babelfish.altavista.com and get something semi-understandable. Or just take the IP address out of the message and grep your logs for the types of activity. I know that most major ISP's are fairly responsive to their static addresses, as I have been notified when one of our departments put up an unpatched MSSQL server that was immediately infected. They usually have more trouble with the dynamic addresses for some unknown reason, maybe they don't keep enough logs. But your abuse message will not usually be replied to.
Quoting Leonard Isham leonard.isham@gmail.com:
First I have relatives that know little to no English. Second I have traveled to Europe, Asia, and Africa for both business and pleasure.
Now I have to ask how many people would even attempt to understand an e-mail in an unknown language?
If their profession is computer related, the chances that they will be able to understand what you wrote to them is relatively high. It is highly unlikely that an ISP will hire somebody who don't speak English for "abuse" position. Even the "basic helpdesk" personel is usually required to have at least basic knowledge of English.
Like you, I also have many relatives back home in Croatia. Many of them don't speak English at all. Back home in Croatia, I also have a bunch of friends that are system administrators, programmers, engineers, professionals, etc. All of them do speak English. It kind of comes with the profession. With some professions, it is a huge dissadvantage if you don't know at least basic English. Computer related professions are just extreme example of that.
On 12/4/06, Aleksandar Milivojevic alex@milivojevic.org wrote:
Quoting Leonard Isham leonard.isham@gmail.com:
First I have relatives that know little to no English. Second I have traveled to Europe, Asia, and Africa for both business and pleasure.
Now I have to ask how many people would even attempt to understand an e-mail in an unknown language?
If their profession is computer related, the chances that they will be able to understand what you wrote to them is relatively high. It is highly unlikely that an ISP will hire somebody who don't speak English for "abuse" position. Even the "basic helpdesk" personel is usually required to have at least basic knowledge of English.
Like you, I also have many relatives back home in Croatia. Many of them don't speak English at all. Back home in Croatia, I also have a bunch of friends that are system administrators, programmers, engineers, professionals, etc. All of them do speak English. It kind of comes with the profession. With some professions, it is a huge dissadvantage if you don't know at least basic English. Computer related professions are just extreme example of that.
This is good information thank you.
On Fri December 1 2006 14:37, Joshua Zukerman wrote:
Depends on the IP address. If it came from an ISP here in the US (assuming you are here in the US), then sure submit it to the proper admins of those networks. If the IP is outside of the US, then I wouldn't bother as e-mailing an admin from another country is useless unless you speak their language.
I would say report it anyway. One never knows how the receiver will handle it. esides how much time will you really lose by sending them an email?
Greetings, Joshua.
1 ??????? 2006 ?., 22:37:43 you have wrote:
Depends on the IP address. If it came from an ISP here in the US (assuming you are here in the US), then sure submit it to the proper admins of those networks. If the IP is outside of the US, then I wouldn't bother as e-mailing an admin from another country is useless unless you speak their language.
Not sure for the rest of world, but here in Russia the knowledge of english is one of the main things checked when hiring someone on system administrator or programmer position. Not always free-spoken-level is required, but at least read-of-techdocs-and-abuse-repots level. ;-)
Alexey Loukianov wrote:
Not sure for the rest of world, but here in Russia the knowledge of english is one of the main things checked when hiring someone on system administrator or programmer position. Not always free-spoken-level is required, but at least read-of-techdocs-and-abuse-repots level. ;-)
Agreed. English is the Lingua Franca of the Internet. Any ISP that cannot master English at some basic level is not worth a grain of salt. I would not hestitate the least to send an email in English to any abuse/webmaster/postmaster or similar standard email addresses.
Quoting Alfred von Campe alfred@110.net:
Is there any sense in reporting this? I have the IP addresses from which they logged in.
You could try, it won't hurt. However, you run 99% probability nothing will happen. That IP address is probably just another compromised system. If it's a dial-up address, contact the ISP. If it actually belongs to some organization (for example university), contact them. In general, places like universities might even attempt to do something with info you provided. ISP's in general will do little to nothing about it.
Is there any sense in reporting this? I have the IP addresses from which they logged in.
You could try, it won't hurt. However, you run 99% probability nothing will happen.
FWIW, the IP addresses are 172.178.63.167 (acb23fa7.ipt.aol.com) and 61.43.153.30. There is no reverse entry for the latter, so I don't know who to contact. I'll fire off an email to AOL (not that I think anything will happen).
Alfred
Quoting Alfred von Campe alfred@110.net:
FWIW, the IP addresses are 172.178.63.167 (acb23fa7.ipt.aol.com) and 61.43.153.30. There is no reverse entry for the latter, so I don't know who to contact. I'll fire off an email to AOL (not that I think anything will happen).
You can use a whois database to find the info (for example, there's web interface on www.ripe.net). Info for 61.43.153.30 indicates that this IP address is alocated to an provider in South Korea. Contact addresses included:
inetnum: 61.32.0.0 - 61.43.255.255 netname: BORANET-1 descr: DACOM Corp. descr: Facility-based Telecommunication Service Provider descr: providing Internet leased-ine, on-line service, BLL etc. country: KR admin-c: DB50-AP tech-c: DB50-AP status: ALLOCATED PORTABLE "status:" definitions mnt-by: APNIC-HM mnt-lower: MNT-KRNIC-AP changed: hostmaster@apnic.net 20000918 source: APNIC
role: DACOM BORANET address: DACOM Bldg., 706-1, Yoeksam-dong, Kangnam-ku, Seoul country: KR phone: +82-2-2089-7755 fax-no: +82-2-2089-0706 e-mail: ipadm@nic.bora.net e-mail: abuse@bora.net e-mail: security@bora.net admin-c: EC115-AP tech-c: SIJ1-AP nic-hdl: DB50-AP remarks: IP address administrator group of NIC team, DACOM Corp. remarks: If related with spam, send mail to abuse@bora.net remarks: If related with security, send mail to security@bora.net remarks: Only for whois information correction, send mail to ipadm@nic.bora.net mnt-by: MNT-KRNIC-AP changed: jeonsi@bora.net 20041105 source: APNIC
Aleksandar Milivojevic spake the following on 12/1/2006 12:43 PM:
Quoting Alfred von Campe alfred@110.net:
FWIW, the IP addresses are 172.178.63.167 (acb23fa7.ipt.aol.com) and 61.43.153.30. There is no reverse entry for the latter, so I don't know who to contact. I'll fire off an email to AOL (not that I think anything will happen).
You can use a whois database to find the info (for example, there's web interface on www.ripe.net). Info for 61.43.153.30 indicates that this IP address is alocated to an provider in South Korea. Contact addresses included:
inetnum: 61.32.0.0 - 61.43.255.255 netname: BORANET-1 descr: DACOM Corp. descr: Facility-based Telecommunication Service Provider descr: providing Internet leased-ine, on-line service, BLL etc. country: KR admin-c: DB50-AP tech-c: DB50-AP status: ALLOCATED PORTABLE "status:" definitions mnt-by: APNIC-HM mnt-lower: MNT-KRNIC-AP changed: hostmaster@apnic.net 20000918 source: APNIC
role: DACOM BORANET address: DACOM Bldg., 706-1, Yoeksam-dong, Kangnam-ku, Seoul country: KR phone: +82-2-2089-7755 fax-no: +82-2-2089-0706 e-mail: ipadm@nic.bora.net e-mail: abuse@bora.net e-mail: security@bora.net admin-c: EC115-AP tech-c: SIJ1-AP nic-hdl: DB50-AP remarks: IP address administrator group of NIC team, DACOM Corp. remarks: If related with spam, send mail to abuse@bora.net remarks: If related with security, send mail to security@bora.net remarks: Only for whois information correction, send mail to ipadm@nic.bora.net mnt-by: MNT-KRNIC-AP changed: jeonsi@bora.net 20041105 source: APNIC
Hacked from Korea! There is a surprise!! ;-D
On Dec 1, 2006, at 15:43, Aleksandar Milivojevic wrote:
You can use a whois database to find the info (for example, there's web interface on www.ripe.net). Info for 61.43.153.30 indicates that this IP address is alocated to an provider in South Korea.
So I sent mail to the address (abuse@bora.net) listed in the whois record for that ISP, and it bounced!
Hi. This is the qmail-send program at users.bora.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out.
<badmail@bora.net|/webmail/mbox0/bora.net/513/badmail|2|512000| 530259968|99999999|99999999|>: Recipient's maiilbox is full, message returned to sender, (#5.2.2) [7mallot:(524288000), usage:(530309120)[0m
Maybe I'll try again after a few days to see if they cleaned up their mailbox. Doesn't give me a warm and fuzzy feeling about that ISP, though.
Alfred
On 12/4/2006 8:24 PM, Alfred von Campe wrote:
You can use a whois database to find the info (for example, there's web interface on www.ripe.net). Info for 61.43.153.30 indicates that this IP address is alocated to an provider in South Korea.
So I sent mail to the address (abuse@bora.net) listed in the whois record for that ISP, and it bounced! ...
<badmail@bora.net|/webmail/mbox0/bora.net/513/badmail|2|512000|530259968|99999999|99999999|>:
Recipient's maiilbox is full, message returned to sender, (#5.2.2)[7mallot:(524288000), usage:(530309120)[0m
<humor style="flavour:black; weight: ultraheavy"> My theory: The admin was shot in his office and the gunman broke into your system. After, nobody cared anymore for the dead man's mailbox. </humor>
<reality> Don't spend too much time into something that won't give you something back in the end. You could traceroute to that guy and email the admin from the hop just before that guy. Normally you get somebody there, but neither will they pay anything to you nor will they shot the gunman back (SCNR). </reality>
Maybe I'll try again after a few days to see if they cleaned up their mailbox. Doesn't give me a warm and fuzzy feeling about that ISP, though.
Put his network on your iptables black list, that certainly gives you a better feeling.
Regards, Michael
Alfred von Campe wrote:
On Dec 1, 2006, at 15:43, Aleksandar Milivojevic wrote:
You can use a whois database to find the info (for example, there's web interface on www.ripe.net). Info for 61.43.153.30 indicates that this IP address is alocated to an provider in South Korea.
So I sent mail to the address (abuse@bora.net) listed in the whois record for that ISP, and it bounced!
If they weren't already listed at http://rfc-ignorant.org/tools/lookup.php?domain=bora.net I'd advise you to list them there. As they are already listed - well, ignore them. They're not worth to get any attention on the net.
Ralph
Alfred von Campe wrote:
Is there any sense in reporting this? I have the IP addresses from which they logged in.
You could try, it won't hurt. However, you run 99% probability nothing will happen.
FWIW, the IP addresses are 172.178.63.167 (acb23fa7.ipt.aol.com) and 61.43.153.30. There is no reverse entry for the latter, so I don't know who to contact. I'll fire off an email to AOL (not that I think anything will happen).
Alfred
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi Alfred,
Go to http://www.arin.net and enter the IP address. In the case of 61.43.153.30, follow the link to the APNIC which is responsible for this pool. You'll get there the info you seek.
Hope this helped!
Guy Boisvert, ing. IngTegration inc.
Go to http://www.arin.net and enter the IP address. In the case of 61.43.153.30, follow the link to the APNIC which is responsible for this pool. You'll get there the info you seek.
there is an enhanced whois command that will do this automatically. I don't know if its in any RH/CentOS repositories (it probably should be, hint hint!), I've built mine from source and drop it into /usr/local/bin ... here's the authors site, the info on it is skimpy, but it works great. http://www.linux.it/~md/software/
$ whois --version Version 4.7.17.
Report bugs to md+whois@linux.it.
$ whois 61.43.153.30 % [whois.apnic.net node-1] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 61.32.0.0 - 61.43.255.255 netname: BORANET-1 descr: DACOM Corp. descr: Facility-based Telecommunication Service Provider descr: providing Internet leased-ine, on-line service, BLL etc. country: KR ...
On Friday 01 December 2006 11:42, Aleksandar Milivojevic wrote:
Quoting Alfred von Campe alfred@110.net:
Is there any sense in reporting this? I have the IP addresses from which they logged in.
You could try, it won't hurt. However, you run 99% probability nothing will happen. That IP address is probably just another compromised system. If it's a dial-up address, contact the ISP. If it actually belongs to some organization (for example university), contact them. In general, places like universities might even attempt to do something with info you provided. ISP's in general will do little to nothing about it.
Having worked at an ISP, I would like to note they might be appreciative depending on the circumstances. If the IP is obviously a DSL or dialup address (check the reverse DNS), they probably get deluged with so many that it's hard for them to actually take action on them (although many ISPs do try). If the IP looks to be an actual server (whether it's the ISP's or a colocation client of theirs), they will most likely be appreciative of the notice.
Alfred von Campe wrote:
Anyone recognize this root kit (if that is what it is)? I've disabled the backup account, and re-enabled port forwarding on my router (so I can access the system from home). Other than deleting these files, is there anything else I should worry about? I'd rather not re-install the OS...
My advice is to reinstall too. Cleaning compromised machine is error prone job. Especially if that is something you have never done before.
Have you been running anything like Tripwire on that box? Without it (or somethine similar), and without its database that was stored off the machine or on read-only media (CD/DVD) I'd be very reluctant to even attempt cleaning the machine.
Anyhow, if you decide to proceed with cleaning attempt (and not reinstall), boot from into the rescue mode from installation CD. That way you'll be using clean kernel and binaries to examine the system. Do not chroot into compromised file systems, since this could simply trigger loading of rootkit (and than you won't see anything).
If you haven't been running tools like Tripwire, you could make fresh installation on some spare system, undo prelink stuff on both machines (prelink changes your binary files), create database on clean system, copy it to the compromised system and run check. This should find all changed, added and removed files (if you do it properly), as long as you run it from rescue mode.
The rpm in verify mode will find changed files, however it will not find changes in configuration files. It also won't be able to find added files (for example kernel modules that are supposed to hide files from you and tools such as rpm and/or tripwire). But it might be good start. Again, run rpm from rescue mode, and do not chroot. You don't want to use (potentially modified) rpm from the file system, you want to use clean rpm binary from installation media (it has couple of options to point it to where the root file system is mounted).
You could also try to remove all kernels, than manually remove kernel directories in /lib/modules, and reinstall kernel (again from rescue mode, and avoid chrooting if possible). This should get rid of additional kernel modules that were part of rootkit.
There's plethora of other stuff to do or try. But even if I went along and made this posting 10 times longer than it already is, you wouldn't be 100% sure you cleaned the machine. Again, reinstall is really your best friend here. You'll probably spend way more time attempting to clean up, than if you were simply to reinstall and restore data (and only data, not config files or anything else, and watch for config files that might be part of data) from backup.
On Dec 1, 2006, at 12:45 AM, Alfred von Campe wrote:
enabled port forwarding on my router (so I can access the system from home). Other than deleting these files, is there anything else I should worry about? I'd rather not re-install the OS...
let me add another suggestion to the flood: once you've rebuilt the box, install DenyHosts (http://denyhosts.sourceforge.net/). this tool is quite effective at blocking brute-force ssh attacks; not only will this make it much harder for an attacker even if you should happen to set a weak password on an account in the future, but it will also reduce the amount of CPU time and memory wasted on dealing with brute-force ssh attacks.
RPMs are available at sourceforge; the python 2.3 RPM works great on CentOS 4.
i'm sorry you're having to deal with this. :(
-steve
-- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
Steve Huff napsal(a):
let me add another suggestion to the flood: once you've rebuilt the box, install DenyHosts (http://denyhosts.sourceforge.net/). this tool is quite effective at blocking brute-force ssh attacks; not only will this make it much harder for an attacker even if you should happen to set a weak password on an account in the future, but it will also reduce the amount of CPU time and memory wasted on dealing with brute-force ssh attacks.
My suggestion is pam_abl. David
On Fri, 1 Dec 2006 08:51:02 -0500 Steve Huff shuff@vecna.org wrote:
let me add another suggestion to the flood: once you've rebuilt the box, install DenyHosts (http://denyhosts.sourceforge.net/). this tool is quite effective at blocking brute-force ssh attacks; not only will this make it much harder for an attacker even if you should happen to set a weak password on an account in the future, but it will also reduce the amount of CPU time and memory wasted on dealing with brute-force ssh attacks.
http://www.bastille-linux.org/
Bastille is an interactive program that will guide you on how to lock-down your boxes. They even have an OsX beta version.
It goes into even more area than was mentioned by the others. It asks you questions with very extensive explanations and then will apply the changes for you at the end.
On 12/1/06, centos@911networks.com centos@911networks.com wrote:
On Fri, 1 Dec 2006 08:51:02 -0500 Steve Huff shuff@vecna.org wrote:
let me add another suggestion to the flood: once you've rebuilt the box, install DenyHosts (http://denyhosts.sourceforge.net/). this tool is quite effective at blocking brute-force ssh attacks; not only will this make it much harder for an attacker even if you should happen to set a weak password on an account in the future, but it will also reduce the amount of CPU time and memory wasted on dealing with brute-force ssh attacks.
http://www.bastille-linux.org/
Bastille is an interactive program that will guide you on how to lock-down your boxes. They even have an OsX beta version.
It goes into even more area than was mentioned by the others. It asks you questions with very extensive explanations and then will apply the changes for you at the end.
Be very very careful with Bastille. Read the documentation first and realize that you may lock yourself out of your system etc. In the last year I have had to walk over 20 people on how to boot from a cdrom, remount, try to undo the Bastille changes, and get the box in a working state.
-
Aleksandar Milivojevic -
Aleksandar Milivojevic -
Alexey Loukianov -
Alfred von Campe -
centos＠911networks.com -
David Hrbác( -
Guy Boisvert -
hkclark＠gmail.com -
John K Masters -
John R Pierce -
Johnny Hughes -
Joshua Zukerman -
Karanbir Singh -
Kevan Benson -
Leonard Isham -
Michael Kress -
Morten Torstensen -
Ralph Angenendt -
Robert Spangler -
Scott Silva -
Stephen John Smoogen -
Steve Huff