Re: /bin/login listening?
On Sat, 29 Jul 2007, Tyler Smith wrote: On 2007-07-28, Jeff D [EMAIL PROTECTED] wrote: also, what version of debian are you running? Is this machine behind a firewall or do you have a firewall running on it? You may also I'm running Lenny on a laptop, usually connected to various wireless routers. I recently noticed that firestarter wasn't actually starting automatically, something to do with the network not being up when I boot, and I don't always remember to turn it on after I connect to the wireless router. Also, even when I am running firestarter I have to turn it off in order to access my university via vpn. I've pasted the results of all the tests you suggested below. I don't understand much, but the md5sum mis-match for the rkhunter files is definitely worrying. Am I going to have to re-install? Thanks, Tyler you can also install the debsums package, it will do a md5sum check against installed packages. root:chapter3# debsums -s SNIP tons of debsum output debsums: checksum mismatch libgcj-common file /usr/share/doc/libgcj-common/copyright debsums: checksum mismatch libgcj-common file /usr/share/doc/libgcj-common/changelog.Debian.gz SNIP lsof output do you have nmap installed on the local machine? you could run a nmap -sV localhost against it and it should report back with something as well. root:chapter3# nmap -sV localhost Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-29 00:26 ADT Interesting ports on localhost (127.0.0.1): Not shown: 1691 closed ports PORTSTATE SERVICE VERSION 22/tcp open ssh OpenSSH 4.6p1 Debian 4 (protocol 2.0) 25/tcp open smtpExim smtpd 4.67 80/tcp open httpApache httpd 1.3.34 ((Debian)) 111/tcp open rpcbind 2 (rpc #10) 113/tcp open ident OpenBSD identd 929/tcp open unknown Service Info: Host: blackbart.mynetwork; OSs: Linux, OpenBSD Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ . Nmap finished: 1 IP address (1 host up) scanned in 6.208 seconds root:chapter3# From the looks of it, it could have just been a false positive. ive seen rkhunter report a few, not very often though. I'd run rkhunter again, install chkrootkit, run that, see if the two match up. As far as debsums reporting back on the rkhunter files, those will probably not match, as they can get updated. -+- 8 out of 10 Owners who Expressed a Preference said Their Cats Preferred Techno. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On 2007-07-29, Jeff D [EMAIL PROTECTED] wrote: From the looks of it, it could have just been a false positive. ive seen rkhunter report a few, not very often though. I'd run rkhunter again, install chkrootkit, run that, see if the two match up. As far as debsums reporting back on the rkhunter files, those will probably not match, as they can get updated. I ran rkhunter again, and then for good measure I aptitude --purged it, reinstalled, and ran again. And then I thought maybe the whole thing was compromised, so I purged it again, installed rkhunter 1.30 from sourceforge, and ran again. And I also ran chkrootkit. In all cases they showed nothing happening, except for warning me that some of my /bin executables had been replaced by scripts -- stuff like egrep, fgrep etc. So perhaps it was just a false positive. I'm going to read up on security stuff now, so maybe I'll have some idea how to proceed the next time. Thanks for your help, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On Sun, Jul 29, 2007 at 12:48:16PM +, Tyler Smith wrote: On 2007-07-29, Jeff D [EMAIL PROTECTED] wrote: I ran rkhunter again, and then for good measure I aptitude --purged it, reinstalled, and ran again. And then I thought maybe the whole thing was compromised, so I purged it again, installed rkhunter 1.30 from sourceforge, and ran again. And I also ran chkrootkit. In all cases they showed nothing happening, except for warning me that some of my /bin executables had been replaced by scripts -- stuff like egrep, fgrep etc. So perhaps it was just a false positive. I'm going to read up on security stuff now, so maybe I'll have some idea how to proceed the next time. Its tricky. If you have been rooted, you can't trust anything on the system, including aptitude. As for reading, try the package harden-doc. Good luck. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On 2007-07-29, Douglas Allan Tutty [EMAIL PROTECTED] wrote: On Sun, Jul 29, 2007 at 12:48:16PM +, Tyler Smith wrote: On 2007-07-29, Jeff D [EMAIL PROTECTED] wrote: I ran rkhunter again, and then for good measure I aptitude --purged it, reinstalled, and ran again. And then I thought maybe the whole thing was compromised, so I purged it again, installed rkhunter 1.30 from sourceforge, and ran again. And I also ran chkrootkit. In all cases they showed nothing happening, except for warning me that some of my /bin executables had been replaced by scripts -- stuff like egrep, fgrep etc. So perhaps it was just a false positive. I'm going to read up on security stuff now, so maybe I'll have some idea how to proceed the next time. Its tricky. If you have been rooted, you can't trust anything on the system, including aptitude. As for reading, try the package harden-doc. That's what I was thinking. But is there any way a rootkit could interfere with my downloading and compiling from source? I was hoping that doing things 'by hand' would limit the possibilities for compromising the result. I will look at harden-doc. I'm working through the Linux how-to security quick start at the moment. Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On 29 Jul 2007 13:47:30 GMT Tyler Smith [EMAIL PROTECTED] wrote: On 2007-07-29, Douglas Allan Tutty [EMAIL PROTECTED] wrote: On Sun, Jul 29, 2007 at 12:48:16PM +, Tyler Smith wrote: On 2007-07-29, Jeff D [EMAIL PROTECTED] wrote: I ran rkhunter again, and then for good measure I aptitude --purged it, reinstalled, and ran again. And then I thought maybe the whole thing was compromised, so I purged it again, installed rkhunter 1.30 from sourceforge, and ran again. And I also ran chkrootkit. In all cases they showed nothing happening, except for warning me that some of my /bin executables had been replaced by scripts -- stuff like egrep, fgrep etc. So perhaps it was just a false positive. I'm going to read up on security stuff now, so maybe I'll have some idea how to proceed the next time. Its tricky. If you have been rooted, you can't trust anything on the system, including aptitude. As for reading, try the package harden-doc. That's what I was thinking. But is there any way a rootkit could interfere with my downloading and compiling from source? I was hoping that doing things 'by hand' would limit the possibilities for compromising the result. In theory, certainly. Your downloading agent is probably invoking system libraries, which may be compromised and substituting bad source. The system may not even be running your download agent at all! Or it may subsequently lie to you and assure you that it's running the downloaded app when it really isn't. Whether all this is at all plausible is a different question. I will look at harden-doc. I'm working through the Linux how-to security quick start at the moment. Thanks, Tyler Celejar -- mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
That's what I was thinking. But is there any way a rootkit could interfere with my downloading and compiling from source? Of course. They could have trojaned any of the tools you would use. _No_ software on a rooted box can be trusted. Including the shell. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On 2007-07-29, Celejar [EMAIL PROTECTED] wrote: That's what I was thinking. But is there any way a rootkit could interfere with my downloading and compiling from source? I was hoping that doing things 'by hand' would limit the possibilities for compromising the result. In theory, certainly. Your downloading agent is probably invoking system libraries, which may be compromised and substituting bad source. The system may not even be running your download agent at all! Or it may subsequently lie to you and assure you that it's running the downloaded app when it really isn't. Whether all this is at all plausible is a different question. So if I'm compromised nothing is safe, and the only guaranteed way to clear this up is to format my harddrive and reinstall. Given that the only evidence of a problem is a warning about /bin/login listening from rkhunter, which happened only once, and I have had no other problems with my net connection or general performance of my laptop, let alone mysterious withdrawals from my bank account or other signs of stolen passwords, what should I be doing? From the advice received and what I'm reading, I'm getting two very different messages - I must reinstall to be 100% certain that I'm safe, and while I can't be 100% certain I'm safe it's pretty unlikely that I have a real problem. What would you do in my situation? Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On Sun, Jul 29, 2007 at 03:56:08PM +, Tyler Smith wrote: So if I'm compromised nothing is safe, and the only guaranteed way to clear this up is to format my harddrive and reinstall. Given that the only evidence of a problem is a warning about /bin/login listening from rkhunter, which happened only once, and I have had no other problems with my net connection or general performance of my laptop, let alone mysterious withdrawals from my bank account or other signs of stolen passwords, what should I be doing? From the advice received and what I'm reading, I'm getting two very different messages - I must reinstall to be 100% certain that I'm safe, and while I can't be 100% certain I'm safe it's pretty unlikely that I have a real problem. What would you do in my situation? Try this: Boot the box from something like the install CD, go to a shell, mount your / partition ro, noexec. I think the install CD has md5sum installed. Run: #md5sum /bin/login. On my i386, I get: 2ee32ff74e474c4d9fc9df6f1460980f /bin/login If /bin/login is fine, then I'd forget about it. If it differs, I'd wipe the drive and reinstall; from backups before your first indication of a problem. Then examine the difference between that backup's data and your most recent backup. Actually, to put your mind at ease, I've attached a file bin-MD5SUMS which is the output of: $md5sum /bin/* bin-MD5SUMS Put this onto a floppy and mount it when you boot your install CD. Then edit it so that, for example the /bin/login reads /mnt/bin/login. You can then verify the whole /bin with #md5sum -c bin-MD5SUMS Here's the file, and good luck. Doug. be2bfd8feb6bfb826593c087817be9d5 /bin/arch 72e1a7bbf8478e3dd08693bec6f4c50e /bin/bash 01fcfa4919953518bbbc97b2637a27ad /bin/bunzip2 a60f3c2c4dcedeec5b0e6cce4fd777c8 /bin/busybox 01fcfa4919953518bbbc97b2637a27ad /bin/bzcat dfaba3a92070a1881dd8ec64a26069a4 /bin/bzcmp dfaba3a92070a1881dd8ec64a26069a4 /bin/bzdiff 2b11565d85da178b3a1942a22d20c624 /bin/bzegrep ea97408418bc4c3a77c0048003198acc /bin/bzexe 2b11565d85da178b3a1942a22d20c624 /bin/bzfgrep 2b11565d85da178b3a1942a22d20c624 /bin/bzgrep 01fcfa4919953518bbbc97b2637a27ad /bin/bzip2 d231db40e391032509c4c4782653cb6e /bin/bzip2recover e243255b6cf3b9403df53cb9cd6176e1 /bin/bzless e243255b6cf3b9403df53cb9cd6176e1 /bin/bzmore c12e12da393d90fba841aa678aef5094 /bin/cat 117baf5142bb451a8a0c501cdbf43726 /bin/chgrp aa1ab822de26dd9d455c8ac9163ba30e /bin/chmod b28ba00d8345041e4955ed970ed174ee /bin/chown a096cd237ee340b66f84a7867a2da2a7 /bin/cp 901cc68b293e3249a681ab4f396d1cd4 /bin/cpio a9a89a3beefb30729ea4ae80d6335cb6 /bin/csh 2af9162bd0c10ecd3b77983a56d79f6c /bin/date 02aec16981ffee391d957a28cd1190af /bin/dd 53f20746bb14718e54a65b86510bcb82 /bin/df 1c4d91adb9b1fa383247d0334a389975 /bin/dir 5c54d6f8b6af629e4be985f52c21adb6 /bin/dmesg 638cead25982bc413a287e30a6b3fea4 /bin/dnsdomainname 177e77531159a20fbcf741136c02ce05 /bin/echo 73a8a6f1948231171a6586aef43f26a6 /bin/ed 1a1c4e75e82a51bc570350aa22184913 /bin/egrep 28b23332333e80869b5810c4105392c6 /bin/false 01b9524c8e60a5e167132a6e85452cd0 /bin/fgrep 5d3ff43e62be5f980abeb4100a018ff1 /bin/fuser d274e7a42d015822ea25fb08ed19262c /bin/grep df40328a2c30b3dd195ef2f55d60cef4 /bin/gunzip cd4aee768f1e3db05aac2b3f5a6219ae /bin/gzexe df40328a2c30b3dd195ef2f55d60cef4 /bin/gzip 638cead25982bc413a287e30a6b3fea4 /bin/hostname 01c8af0fc0fe16eab70368389a5482bb /bin/ip aca6202f58b4e514ac9c0501505c2076 /bin/kernelversion 083ec3e06bc9de75e00fcb6d6292b378 /bin/kill 2f67f424360319c65ab68c27984f4d06 /bin/ln 2ee32ff74e474c4d9fc9df6f1460980f /bin/login 3a409d2e7d87fa96c89650c6aec35ac7 /bin/ls 8903244917679b8f5a19909e7e5d0fcc /bin/lsmod 432c653790fe9d2562f0894bb922d46d /bin/lsmod.modutils e89d8739e436bf722668b838476d65cb /bin/lspci 2b71253ac2aa883f6b65cc4d636fe8c8 /bin/mkdir 95887a0809f5a6de47e26d8b60ae28b1 /bin/mknod 641ec128955d32c613c201d45a9bf224 /bin/mktemp cc51af5002e2d41a84aecb14fc9cbd79 /bin/more 27c66448968d6775d3f61ee07938938c /bin/mount dcfe6fa0df8251d56c7f6cd738181003 /bin/mountpoint 0658725a01811e897497f24838c79e75 /bin/mt 0658725a01811e897497f24838c79e75 /bin/mt-gnu 45fc16400d06a4cf9d69c8d619f9104b /bin/mv 68de2870b06443403332c81022010a24 /bin/nano f0169e77f969e17e013c295cd74346a6 /bin/nc f0169e77f969e17e013c295cd74346a6 /bin/netcat e00b5e934dfa34a968b33cb2566ecdec /bin/netstat 3aba7c43d7978452e790220b0deb0e4e /bin/pidof 7001afa26625989c85d05be0d4f93e4e /bin/ping d420db19497b56e632756884efd244e9 /bin/ping6 6140d156296de35a86fd154081b00f26 /bin/ps b7ec22f9d3040fff114acfd4f6d226e7 /bin/pwd 72e1a7bbf8478e3dd08693bec6f4c50e /bin/rbash 07e433957de1c39329ebd81d61ca44a2 /bin/readlink bdd022ca8ec797544b3eddb817ce97f5 /bin/rm 34dd0e07f6abdd1531c7c0953752ab1d /bin/rmdir 68de2870b06443403332c81022010a24 /bin/rnano 1622c90a9570641dd182d0eff4e9d95b /bin/run-parts d9be68996d0b87faeb83d1ad8951a481 /bin/sash
Re: /bin/login listening?
Hi Douglas. Douglas Allan Tutty, 29.07.2007 18:35: Boot the box from something like the install CD, go to a shell, mount your / partition ro, noexec. I think the install CD has md5sum installed. Run: #md5sum /bin/login. On my i386, I get: 2ee32ff74e474c4d9fc9df6f1460980f /bin/login You should also tell the exact version of the login package you are using. Otherwise this number is useless. With 1:4.0.18.1-11 on i386 I get this: 004a41bb9196f1888bd89c2245910f46 /bin/login Regards, Mathias -- debian/rules signature.asc Description: OpenPGP digital signature
Re: /bin/login listening?
On Sun, Jul 29, 2007 at 06:40:05PM +0200, Mathias Brodala wrote: You should also tell the exact version of the login package you are using. Otherwise this number is useless. Sorry. Stock, up-to-date Etch. Aptitude shows it as version 1:4.0.18.1-7. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On 2007-07-29, Mathias Brodala [EMAIL PROTECTED] wrote: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enig6620D8D79CB50A9B1AFF7AB2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Douglas. Douglas Allan Tutty, 29.07.2007 18:35: Boot the box from something like the install CD, go to a shell, mount your / partition ro, noexec. =20 I think the install CD has md5sum installed. Run: #md5sum /bin/login. =20 On my i386, I get: =20 2ee32ff74e474c4d9fc9df6f1460980f /bin/login You should also tell the exact version of the login package you are usi= ng. Otherwise this number is useless. With 1:4.0.18.1-11 on i386 I get this: 004a41bb9196f1888bd89c2245910f46 /bin/login Which is just what I got too. I found an old Mepis CD, booted into that, mounted my / partition, ran md5sum on /bin/login, and out came the same answer, for the same version of /bin/login. So I'm going to proceed as if I've been lucky, have not been rootkit-ed, and will continue on with hardening my laptop without reinstalling. Thanks for your help! Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On Sun, 29 Jul 2007, Tyler Smith wrote: On 2007-07-29, Mathias Brodala [EMAIL PROTECTED] wrote: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enig6620D8D79CB50A9B1AFF7AB2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Douglas. Douglas Allan Tutty, 29.07.2007 18:35: Boot the box from something like the install CD, go to a shell, mount your / partition ro, noexec. =20 I think the install CD has md5sum installed. Run: #md5sum /bin/login. =20 On my i386, I get: =20 2ee32ff74e474c4d9fc9df6f1460980f /bin/login You should also tell the exact version of the login package you are usi= ng. Otherwise this number is useless. With 1:4.0.18.1-11 on i386 I get this: 004a41bb9196f1888bd89c2245910f46 /bin/login Which is just what I got too. I found an old Mepis CD, booted into that, mounted my / partition, ran md5sum on /bin/login, and out came the same answer, for the same version of /bin/login. So I'm going to proceed as if I've been lucky, have not been rootkit-ed, and will continue on with hardening my laptop without reinstalling. Thanks for your help! Tyler On that note, one thing that you might want to consider as part of the hardening process is to install aide or some other file integrity checker. Using something like that greatly helps in detecting and identifying issues such as this. -+- 8 out of 10 Owners who Expressed a Preference said Their Cats Preferred Techno. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On Sun, Jul 29, 2007 at 12:44:56PM -0700, Jeff D wrote: On that note, one thing that you might want to consider as part of the hardening process is to install aide or some other file integrity checker. Using something like that greatly helps in detecting and identifying issues such as this. I use samhain. However, since a compromised system can't reliably check for an intrusion, I use it as a check agains JFS. Since JFS doesn't journal data (just meta-data), it is possible that after a power failure, a file may be missing. Samhain would detect this. For security, you should have the samhain on a live-CD or something with the checksums stored on a CD or USB stick. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
/bin/login listening?
Hi, rkhunter has turned up a new warning for me: Found warnings: [16:37:42] Checking for packet capturing applications... Warning [16:37:43] Warning! Process /bin/login (3888) listening [16:37:43] Warning! Process /bin/login (3888) listening [16:37:43] Warning! Process /bin/login (3888) listening [16:37:43] Warning! Process /bin/login (3888) listening [16:37:43] Warning! Process /sbin/dhclient (4197) listening [16:37:43] WARNING, found: /etc/.java (directory) /dev/.static (directory) /dev/.udev (directory) /dev/.initramfs (directory) The /bin/login hasn't shown up before. Is this something I need to worry about? Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On Sat, 28 Jul 2007, Tyler Smith wrote: Hi, rkhunter has turned up a new warning for me: Found warnings: [16:37:42] Checking for packet capturing applications... Warning [16:37:43] Warning! Process /bin/login (3888) listening [16:37:43] Warning! Process /bin/login (3888) listening [16:37:43] Warning! Process /bin/login (3888) listening [16:37:43] Warning! Process /bin/login (3888) listening [16:37:43] Warning! Process /sbin/dhclient (4197) listening [16:37:43] WARNING, found: /etc/.java (directory) /dev/.static (directory) /dev/.udev (directory) /dev/.initramfs (directory) The /bin/login hasn't shown up before. Is this something I need to worry about? Thanks, Tyler -- Normally /bin/login shouldn't be listening. A couple things you could do to see if it is listneing is: lsof -i -n | grep LISTEN if it is listening, it should show up there. providing lsof hasnt been comprimised. if you have another machine available to you, run an nmap scan on it like so: nmap -sV hostname if those show up true, it's likely that you have a rootkit installed and should pull the network cable from the machine and rebuild. jeff -+- 8 out of 10 Owners who Expressed a Preference said Their Cats Preferred Techno. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On 2007-07-28, Jeff D [EMAIL PROTECTED] wrote: [16:37:43] Warning! Process /bin/login (3888) listening Normally /bin/login shouldn't be listening. A couple things you could do to see if it is listneing is: lsof -i -n | grep LISTEN Here's what I got - no sign of /bin/login: lsof -i -n | grep LISTEN portmap2578 daemon4u IPv4 6938 TCP *:sunrpc (LISTEN) rpc.statd 2603 statd8u IPv4 7009 TCP *:37381 (LISTEN) sshd 3026root3u IPv6 7668 TCP *:ssh (LISTEN) exim4 3385 Debian-exim3u IPv4 7971 TCP 127.0.0.1:smtp (LISTEN) inetd 3661root4u IPv4 8254 TCP *:auth (LISTEN) famd 3721 tyler3u IPv4 8323 TCP 127.0.0.1:929 (LISTEN) apache 3826root 16u IPv4 9177 TCP *:www (LISTEN) apache 3827www-data 16u IPv4 9177 TCP *:www (LISTEN) apache 3828www-data 16u IPv4 9177 TCP *:www (LISTEN) apache 3829www-data 16u IPv4 9177 TCP *:www (LISTEN) apache 3830www-data 16u IPv4 9177 TCP *:www (LISTEN) apache 3839www-data 16u IPv4 9177 TCP *:www (LISTEN) apache21000www-data 16u IPv4 9177 TCP *:www (LISTEN) apache21001www-data 16u IPv4 9177 TCP *:www (LISTEN) apache21002www-data 16u IPv4 9177 TCP *:www (LISTEN) identd21568 identd0u IPv4 8254 TCP *:auth (LISTEN) identd21568 identd1u IPv4 8254 TCP *:auth (LISTEN) identd21568 identd2u IPv4 8254 TCP *:auth (LISTEN) if it is listening, it should show up there. providing lsof hasnt been comprimised. if you have another machine available to you, run an nmap scan on it like so: nmap -sV hostname I don't have another maching available. What do you think? Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On Sat, 28 Jul 2007, Tyler Smith wrote: On 2007-07-28, Jeff D [EMAIL PROTECTED] wrote: [16:37:43] Warning! Process /bin/login (3888) listening Normally /bin/login shouldn't be listening. A couple things you could do to see if it is listneing is: lsof -i -n | grep LISTEN Here's what I got - no sign of /bin/login: lsof -i -n | grep LISTEN portmap2578 daemon4u IPv4 6938 TCP *:sunrpc (LISTEN) rpc.statd 2603 statd8u IPv4 7009 TCP *:37381 (LISTEN) sshd 3026root3u IPv6 7668 TCP *:ssh (LISTEN) exim4 3385 Debian-exim3u IPv4 7971 TCP 127.0.0.1:smtp (LISTEN) inetd 3661root4u IPv4 8254 TCP *:auth (LISTEN) famd 3721 tyler3u IPv4 8323 TCP 127.0.0.1:929 (LISTEN) apache 3826root 16u IPv4 9177 TCP *:www (LISTEN) apache 3827www-data 16u IPv4 9177 TCP *:www (LISTEN) apache 3828www-data 16u IPv4 9177 TCP *:www (LISTEN) apache 3829www-data 16u IPv4 9177 TCP *:www (LISTEN) apache 3830www-data 16u IPv4 9177 TCP *:www (LISTEN) apache 3839www-data 16u IPv4 9177 TCP *:www (LISTEN) apache21000www-data 16u IPv4 9177 TCP *:www (LISTEN) apache21001www-data 16u IPv4 9177 TCP *:www (LISTEN) apache21002www-data 16u IPv4 9177 TCP *:www (LISTEN) identd21568 identd0u IPv4 8254 TCP *:auth (LISTEN) identd21568 identd1u IPv4 8254 TCP *:auth (LISTEN) identd21568 identd2u IPv4 8254 TCP *:auth (LISTEN) if it is listening, it should show up there. providing lsof hasnt been comprimised. if you have another machine available to you, run an nmap scan on it like so: nmap -sV hostname I don't have another maching available. What do you think? Cheers, Tyler you could also try something like this: lsof -n -p `pidof login | sed s/\ /\,/g` or lsof -n -p 3888 ( since that is the process id that rkhunter is reporting listening) do you have nmap installed on the local machine? you could run a nmap -sV localhost against it and it should report back with something as well. you can also install the debsums package, it will do a md5sum check against installed packages. also, what version of debian are you running? Is this machine behind a firewall or do you have a firewall running on it? You may also Jeff -+- 8 out of 10 Owners who Expressed a Preference said Their Cats Preferred Techno. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /bin/login listening?
On 2007-07-28, Jeff D [EMAIL PROTECTED] wrote: also, what version of debian are you running? Is this machine behind a firewall or do you have a firewall running on it? You may also I'm running Lenny on a laptop, usually connected to various wireless routers. I recently noticed that firestarter wasn't actually starting automatically, something to do with the network not being up when I boot, and I don't always remember to turn it on after I connect to the wireless router. Also, even when I am running firestarter I have to turn it off in order to access my university via vpn. I've pasted the results of all the tests you suggested below. I don't understand much, but the md5sum mis-match for the rkhunter files is definitely worrying. Am I going to have to re-install? Thanks, Tyler you can also install the debsums package, it will do a md5sum check against installed packages. root:chapter3# debsums -s debsums: no md5sums for amarok-engines debsums: no md5sums for at debsums: no md5sums for base-files debsums: no md5sums for bc debsums: no md5sums for bin86 debsums: no md5sums for binutils debsums: no md5sums for bsdutils debsums: no md5sums for bzip2 debsums: can't open cltl file /usr/share/doc/cltl/README.Debian (No such file or directory) debsums: can't open cltl file /usr/share/doc/cltl/copyright (No such file or directory) debsums: can't open cltl file /usr/share/doc/cltl/changelog.gz (No such file or directory) debsums: no md5sums for console-data debsums: no md5sums for dc debsums: no md5sums for debian-archive-keyring debsums: no md5sums for debian-policy debsums: no md5sums for dict debsums: no md5sums for doc-debian debsums: can't open ebook-dev-alp file /usr/share/doc/ebook-dev-alp/advanced-linux-programming.pdf.gz (No such file or directory) debsums: no md5sums for ed debsums: no md5sums for figlet debsums: no md5sums for g++ debsums: no md5sums for g77 debsums: no md5sums for gawk debsums: no md5sums for gawk-doc debsums: no md5sums for gnupg debsums: no md5sums for gnuplot debsums: no md5sums for gpgv debsums: no md5sums for hibernate debsums: no md5sums for initscripts debsums: no md5sums for installation-guide-i386 debsums: no md5sums for installation-report debsums: no md5sums for klogd debsums: no md5sums for libaudio2 debsums: no md5sums for libbz2-1.0 debsums: no md5sums for libbz2-dev debsums: no md5sums for libdb4.2 debsums: no md5sums for libdb4.3 debsums: no md5sums for libdb4.4 debsums: checksum mismatch libgcj-common file /usr/share/doc/libgcj-common/copyright debsums: checksum mismatch libgcj-common file /usr/share/doc/libgcj-common/changelog.Debian.gz debsums: no md5sums for libgdbm3 debsums: no md5sums for libgsm1 debsums: no md5sums for libhdf4g debsums: no md5sums for libident debsums: no md5sums for liblockfile1 debsums: no md5sums for libncurses5 debsums: no md5sums for libncurses5-dev debsums: no md5sums for libncursesw5 debsums: no md5sums for libnetcdf3 debsums: no md5sums for libvolume-id0 debsums: no md5sums for lynx debsums: no md5sums for make-doc debsums: no md5sums for mawk debsums: no md5sums for mime-support debsums: no md5sums for module-init-tools debsums: no md5sums for mount debsums: no md5sums for mpack debsums: no md5sums for ncurses-base debsums: no md5sums for ncurses-bin debsums: no md5sums for ncurses-term debsums: no md5sums for netbase debsums: no md5sums for openbsd-inetd debsums: checksum mismatch preview-latex-style file /usr/share/texmf/tex/latex/preview/prauctex.cfg debsums: checksum mismatch preview-latex-style file /usr/share/texmf/tex/latex/preview/prauctex.def debsums: checksum mismatch preview-latex-style file /usr/share/texmf/tex/latex/preview/prcounters.def debsums: checksum mismatch preview-latex-style file /usr/share/texmf/tex/latex/preview/preview.sty debsums: checksum mismatch preview-latex-style file /usr/share/texmf/tex/latex/preview/prfootnotes.def debsums: checksum mismatch preview-latex-style file /usr/share/texmf/tex/latex/preview/prlyx.def debsums: checksum mismatch preview-latex-style file /usr/share/texmf/tex/latex/preview/prshowbox.def debsums: checksum mismatch preview-latex-style file /usr/share/texmf/tex/latex/preview/prshowlabels.def debsums: checksum mismatch preview-latex-style file /usr/share/texmf/tex/latex/preview/prtightpage.def debsums: checksum mismatch preview-latex-style file /usr/share/texmf/tex/latex/preview/prtracingall.def debsums: no md5sums for r-recommended debsums: no md5sums for rcs debsums: checksum mismatch rkhunter file /var/lib/rkhunter/db/mirrors.dat debsums: checksum mismatch rkhunter file /var/lib/rkhunter/db/os.dat debsums: checksum mismatch rkhunter file /var/lib/rkhunter/db/programs_good.dat debsums: checksum mismatch rkhunter file /var/lib/rkhunter/db/defaulthashes.dat debsums: no md5sums for rsync debsums: no md5sums for ssh debsums: no md5sums for strace debsums: no md5sums for sun-java5-fonts debsums: no md5sums for sun-java5-plugin debsums: no md5sums for
