Good Day! I think we have a serious problem. One of our old server running FreeBSD 4.9 have been compromised and is now connected to an ircd server.. 195.204.1.132.6667 ESTABLISHED However, we still haven't brought the server down in an attempt to track the intruder down. Right now we are clueless as to what we need to do.. Most of our servers are running legacy operating systems(old versions mostly freebsd) Also, that particular server is running - ProFTPD Version 1.2.4 which someone have suggested to have a known vulnerability.. I really need all the help I can get as the administration of those servers where just transferred to us by former admins. The server is used for ftp. Thanks.. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
At 05:25 PM 11/16/2005 -0800, Mark Jayson Alvarez wrote: | Good Day! | | I think we have a serious problem. One of our old | server running FreeBSD 4.9 have been compromised and | is now connected to an ircd server.. | 195.204.1.132.6667 ESTABLISHED | | However, we still haven't brought the server down in | an attempt to track the intruder down. Right now we | are clueless as to what we need to do.. | Most of our servers are running legacy operating | systems(old versions mostly freebsd) Also, that | particular server is running - ProFTPD Version 1.2.4 | which someone have suggested to have a known | vulnerability.. | | I really need all the help I can get as the | administration of those servers where just transferred | to us by former admins. The server is used for ftp. | | Thanks.. Hi Mark, Good luck tracking them. The IP# is out of Canada if that helps any. 195.204.1.132 CA CANADA ONTARIO WAWA UNDERNET-IRC Looks like it is coming from another IRC network - although I am no IRC expert. Someone is probably using your machine to exchange software or run a bot network or something along those lines. Who knows. Try doing a ps -aux and see if something like eggdrop or some IRC bot is running on there (assuming you still have the root password). You might even be able to figure out if you are hosting an IRC room :-) Maybe everyone from the FreeBSD hacker list can meet there and party :-) Just kidding. Anyway, tracking them is probably a waste of time, unless some valuable corporate information has been stolen. The best bet is to just wipe the machine and start over, unless you need something on there that you can't backup, etc. In cases like these, unless you are running something that has built check sums of all your system files, it's difficult to work back wards and know for sure you have returned everything back to a secure status. Best just to start at square 1 and work forward. In the future, you might consider running a fire wall, such as ipf - or putting the server on a non-public IP# behind a router that acts as a fire wall - then only allow traffic in (and out) on ports you really need. If you run ipf, you might also block out going traffic on ports such as 21, 6666-6669, etc. so that anything that does get into the machine can't "phone home". If your root password has been changed on you, you'll need to boot into single user mode and change the password back. You might also check files like /etc/rc.local or the like to see if something is setup to auto load at boot, such as an IRC server, or IRC bot, etc. Anyway, just some ideas off hand. good luck! Ray
On Wed, Nov 16, 2005 at 05:25:52PM -0800, Mark Jayson Alvarez wrote:> However, we still haven't brought the server down in an attempt to > track the intruder down. Right now we are clueless as to what we > need to do.. Most of our servers are running legacy operating > systems(old versions mostly freebsd) Also, that particular server > is running - ProFTPD Version 1.2.4 which someone have suggested to > have a known vulnerability..You should take the box off the network immediately. Before doing so, get a dump of all open files using lsof(8), especially open network sockets. The following is a start: <as root> $ lsof -Pni > /root/openfiles.txt Do not use shutdown(8) or reboot(8) to shut the machine down, as these may trigger scripts that could remove or obfuscate evidence of the breakin. Simply powering the machine off will leave it in a relatively pristine state. The machine will need to be rebuilt, and all passwords on it retired. Consider whether the attacker could have compromised other systems on your network via this machine; if so, change relevant passwords and investigate further. Do not boot from the compromised hard disk again; instead, mount it on a safe machine and take a disk image. Do not alter the disk itself -- all investigation should occur using copies of the image. If the other machines are in a state similar to the compromised machine (in terms of OS upgrades, software upgrades, exposure), develop a plan to bring them to a known safe/protected level. At a minimum, unnecessary services should be turned off, strict password requirements should be set, and all software (OS and third party) should be updated. For extra credit: Using the image and the dump of open files, try to determine the vector used to launch the attack. Understanding how they got in might help you as you move to secure your other machines. You're going to have rather a lot of work to do, unfortunately, which is a rough way to start at your new job. If the previous admin had kept the machines up to date, the likelihood that you'd have to respond to a security incident on unfamiliar systems would be dramatically lessened. Do the next admin a favor: keep these machines secure after you rebuild them. -- o--------------------------{ Will Maier }--------------------------o | jabber:..wcmaier@jabber.ccc.de | email:..........wcmaier@ml1.net | | \.........wcmaier@cae.wisc.edu | \..........wcmaier@cae.wisc.edu | *------------------[ BSD Unix: Live Free or Die ]------------------*
Mark, before going too nuts with trying to locate how they got in, let me ask, are you running a webserver on this server and any websites? take a look in /tmp, /var/tmp and do a find for any directories which have 777 perms like uucppublic in /var. if so, are they owned by the web user? I have seen many IRC bots installed from poorly written php and perl programs into /tmp and such which are then run via the same security holes that allowed them to be installed. these programs can only be run on high port numbers and are owned by the webserver owner. 99 of 100 are usually IRC bots as well. another thing to look for is if they installed a cron job for the web user which re-downloads the files if they are deleted. you can disable cron for www and is reccomended. I have seen these tactics more and more lately and the amount of bad 3rd party code used by my users doesnt help at all. HTH, Bill -- Bill Desjardins d: 305.205.8644 EtherneXt.com - Managed Colocation & Bandwidth bill@ethernext.com Phone: 305.373.5960 Quoting Mark Jayson Alvarez <jay2xra@yahoo.com>:> Good Day! > > I think we have a serious problem. One of our old > server running FreeBSD 4.9 have been compromised and > is now connected to an ircd server.. > 195.204.1.132.6667 ESTABLISHED > > However, we still haven't brought the server down in > an attempt to track the intruder down. Right now we > are clueless as to what we need to do.. > Most of our servers are running legacy operating > systems(old versions mostly freebsd) Also, that > particular server is running - ProFTPD Version 1.2.4 > which someone have suggested to have a known > vulnerability.. > > I really need all the help I can get as the > administration of those servers where just transferred > to us by former admins. The server is used for ftp. > > Thanks.. > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > >
On Wed, Nov 16, 2005 at 05:25:52PM -0800, Mark Jayson Alvarez wrote:> Good Day! > > I think we have a serious problem. One of our old > server running FreeBSD 4.9 have been compromised and > is now connected to an ircd server.. > 195.204.1.132.6667 ESTABLISHEDI had a 4.9 box compromised though the ssh install (I'm certain it wasn't openssh, but the base install), and was running an irc server itself. I just yanked the box off the net, and scrubbed it flat, and reinstalled. In my case, it wasn't worth the time to track who and when and how; I needed to put the server back on the net. Good luck on chasing them down. Are you sure that effort is worth it to you?> Thanks.. > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com-- Brian Reichert <reichert@numachi.com> 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Check the system with rkhunter to see if there were any changes to some files or any known rootkit installed. You can find rkhunter in /usr/ports/security/rkhunter Try to the following: rkhunter --update && rkhunter --checkall 17 nov 2005 kl. 02.25 Mark Jayson Alvarez wrote:> Good Day! > > I think we have a serious problem. One of our old > server running FreeBSD 4.9 have been compromised and > is now connected to an ircd server.. > 195.204.1.132.6667 ESTABLISHED > > However, we still haven't brought the server down in > an attempt to track the intruder down. Right now we > are clueless as to what we need to do.. > Most of our servers are running legacy operating > systems(old versions mostly freebsd) Also, that > particular server is running - ProFTPD Version 1.2.4 > which someone have suggested to have a known > vulnerability.. > > I really need all the help I can get as the > administration of those servers where just transferred > to us by former admins. The server is used for ftp. > > Thanks.. > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security- > unsubscribe@freebsd.org"-- Johan Berg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDfLapSVaw+q1ufCYRAh7BAJ93lVecTx72JQnY8IiW3L5D8ineMwCfTZbm dY+/9ukhbXIF9r/5krcxSZ4=sjjs -----END PGP SIGNATURE-----
At 02:42 PM 11/18/2005 +1000, Timothy Smith wrote: | i have seen a similar attack recently doing a brute force ssh. the | number ONE weakness in most poorly run IT systems, is easy passwords. | it's amazingly easy to brute force these systems using common names or | variations of them. Speaking of SSH, if you have to provide SSH service via a public IP# (and you are unable to limit traffic to just specific management/workstation IP#'s), then it's always a good idea to confirm that root login is not enabled in /etc/ssh/sshd_config. This make a brute force attack much more difficult, since a would-be attacker not only has to hit the correct password, but they also have to know a valid username on the system (as opposed to just using 'root') during an attack. Also, if you have access to the router, it's handy to re-write traffic from a higher public port down to port 22 on the server, since that will trip up anyone doing scans looking for a connect on port 22 across a large number of IP's. Anyway, just a couple of ideas I thought might be helpful while on the subject of SSH hardening :-) Ray
Hej there, Bitbucket wrote:> > I agree that this is not good security. It does NOT make your system more > secure.ack :)> But I stop should of saying it should not be done as I can see no > detremental effect to changing the port number. If it makes you sleep > better at night then do it. It cannot hurt. Just dont RELY on it. >Well, it wouldn't make me sleep better at nights, since I know that there's an unpatched sshd out there. And even if it would be on another port, a non-Script-Kiddy could break in easily. Apart from avoiding security by obscurity, you're right, you can do it. If I'm responsible for several dozen of boxes out there, I still couldn't sleep at night, even though the sshd might be on another port than 22 :) Perhaps it winds down to: Do it on your private box, don't do it "at work" :) regards, Marian
ray@redshift.com wrote:>The point isn't to get more secure. You are correct by saying that >moving the port # doesn't make anything more secure.Actually the point _is_ security and changing the port number _does_ improve it significantly though only from one popular attack vector. Security by obscurity _does_ work and often very well just not in place of more substantive measures. In the case of sshd dictionary attacks those would be: 1) setting "MaxAuthTries 2", "Banner /etc/issue" and "PermitRootLogin no" in /etc/ssh/sshd_config, 2) running an sshd IDS that A) tests for '(for invalid user|Failed password for)', B) blacholes source hosts 'ipfw add deny ...', and C) alerts sysadmin or operations personnel, 3) making sure SSL and SSH are up to date (preferably via ports), 4) deleting the rc script, adding sshd to /etc/inetd.conf, and taking advantage of the rate controls, logging, and other excellent security features of FreeBSD's inetd. Hosts that don't have at least these 4 protections in place will reduce their exposure by moving sshd to a port other than 22. Hosts that do implement these protections will still benefit from changing the port but can lose some excellent logging. If possible keep the logs and either send them to the offending ISP or add to a local list of long-term blackholes. Obscurity is an important and wholly necessary part of the security toolkit. Take passwords for example. Defining a non-dictionary password is security by obscurity. It is, however, weak protection if you do not also log dictionary attacks and blackhole offenders before they can try many username/password pairs. ATM PINs are even weaker than passwords but are nevertheless adequate protection thanks to the fact that ~3 failed passwords will cause the account to be locked. Bruce Schneier looks at more areas on where security by obscurity works and where it doesn't in the May 2002 CRYPTO-GRAM <http://archives.neohapsis.com/archives/crypto/2002-q2/0005.html>. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
--- Roger Marquis <marquis@roble.com> wrote:> Obscurity is an important and wholly necessary part > of the security toolkit. Take passwords for example. > Defining a non-dictionary password is security by > obscurity. It is, however, weak protection if you > do not also log dictionary attacks and blackhole > offenders before they can try many username/password > pairs. >I can say that again... :-) I personally do not like passwords, because: 1. I could forget it. 2. A bad guy could treat me bad in order to get the password. So I was very happy, when I found out, that ssh protocol offers this passphrase-less, password-less RSA (today it seems to be DSA) authentication, which seems to be very secure, and which makes me uninteresting for authentication and for a bad guy (he or she only needs my hard disc, which he or she can get without hurting me). Maybe that could help in this specific security problem discussion. Furthermore I would ask, if it might be a good idea in this case to use a good-guy list instead of a bad-guy list. Ceterum censeo: Finger prints make everything worse (not just for thiefs, who have to wear gloves nowadays), because I have heard of a case, where a robber took away the ring-finger of his victim, because his victim was unable to get off the ring (published in german TV by a governmental broadcasting carrier (ZDF) in "Aktenzeichen XY ... noch nicht gel?st" (which translates to "case number XY ... not solved yet")). There has been a case near Kiel,SH,F.Rep.Germ, where the robber became a killer, because the victim refused to give 10USD, that belonged to his employer. -Arne who said the mother of all passwords loudly in the public, while one of his colleagues was talking to him on the phone __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
Lowell Gilbert wrote:>> Not sure I agree with the easily part.. TCP transport plus SSH >> protocol spoofing is not a vector that normally needs to be secured >> beyond what is already done in the kernel and router. That's not to >> say such spoofing cannot be done, just that it is rare and would >> require a compromised router or localnet host at a minimum. > > Except that it doesn't require spoofed addresses. One attacker from the > local university's computer center (or from a large shell service ISP) > could lock out all of the other users on that machine. Trivially.And that's exactly what you want. The alternative is to let the dictionary attack continue unabated. At least once the blackhole is up, and notices sent, the target host's admins can contact the attacking host's admins to shutdown the account or process running the scan. If nobody is monitoring the IDS alerts that's a different problem. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Tue, Nov 22, 2005 at 12:13:03AM +0100, Bitbucket wrote:> > > > You can also couple this with port-knocking (or even just port-knocking > > on 22). > > Just out of curiosity, has anyone implemented this in fbsd? > I would love to implement this for my machines. > > -Ddoorman (doorman.sf.net) is in ports. tumbler (tumbler.sf.net) was one of the original implementations discussed in linux journal and dr. dobbs (and in perl, altho may require a perl pcap module). I haven't tried any of these myself, but you might find them interesting. http://www.portknocking.org/view/implementations/implementations for an extensive listing. -- Peter C. Lai Dept. of Neurobiology | SenseLab Yale University School of Medicine http://cowbert.2y.net/