Re: Hacked - is it my turn? - interesting
* Quoting Phillip Hofmeister ([EMAIL PROTECTED]): On Tue, 03 Feb 2004 at 06:11:34PM -0500, Rolf Kutz wrote: You would get a ICMP host-unreachable from the last router in that case. I don't believe this is always the case. True. It may be the RFC specification that an ICMP host-unreachable be sent, but in practice this is no where near always the case. Worse things happen. One of the largest Mailproviders in Germany (gmx.de) blocks ICMP. - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
On Tue, Feb 03, 2004 at 05:38:40AM +0100, Philipp Schulte wrote: No, with REJECT they would show up as closed. DROP produces filtered. FWIW, you also need --reject-with tcp-reset to fool nmap. Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
François TOURDE wrote: But I think DROP is the best way, 'cause it slow down NMAP or other sniffers. nmap is not a sniffer but a portscanner. It's true that nmap is slowed down by DROP but this doesn't improve security very much and can have some annoying side effects (i.e. timeouts with ident-lookups). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
* Quoting François TOURDE ([EMAIL PROTECTED]): But I think DROP is the best way, 'cause it slow down NMAP or other sniffers. Sniffers must wait packet timeout, then retry, then wait, etc. Your fooling yourself. What prevents sniffers from sending multiple packets at once[0]. And you're breaking the TCP-Protocol, which makes debugging much harder. - Rolf [0] I don't think that portscans are a threat anyway and you increase your network load by dropping packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
On Tue, Feb 03, 2004 at 05:38:40AM +0100, Philipp Schulte wrote: Those ports are not showing up as open. 'Filtered' does not mean open. If you run 'iptables -A INPUT -p tcp --dport 1524 -j REJECT' you'll get this exact behavior, with nothing listening on these ports. No, with REJECT they would show up as closed. DROP produces filtered. Nope. With REJECT, the kernel will send an ICMP port unreachable response, which causes nmap to think filtered. If you add the --reject-with tcp-reset flag to the iptables command, then the kernel will send a TCP packet with the RST flag set, which indicates a closed port. noah pgp0.pgp Description: PGP signature
Re: Hacked - is it my turn? - interesting
Le 12451ième jour après Epoch, Rolf Kutz écrivait: * Quoting François TOURDE ([EMAIL PROTECTED]): But I think DROP is the best way, 'cause it slow down NMAP or other sniffers. Sniffers must wait packet timeout, then retry, then wait, etc. Your fooling yourself. What prevents sniffers from sending multiple packets at once[0]. Nothing, but with or without DROP. And you're breaking the TCP-Protocol, which makes debugging much harder. Ok, but I don't want somebody debug on *my* machine. It's only allowed for me :) -- She was good at playing abstract confusion in the same way a midget is good at being short. -- Clive James, on Marilyn Monroe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
On Tue, 03 Feb 2004 at 08:55:51AM -0500, Philipp Schulte wrote: nmap is not a sniffer but a portscanner. It's true that nmap is slowed down by DROP but this doesn't improve security very much and can have some annoying side effects (i.e. timeouts with ident-lookups). $IPTABLES -A ETH0-IN -p tcp --dport 113 -j REJECT --reject-with tcp-reset -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Feb 2004 at 09:03:31AM -0500, Rolf Kutz wrote: Your fooling yourself. What prevents sniffers from sending multiple packets at once[0]. And you're breaking the TCP-Protocol, which makes debugging much harder. As mentioned before, it is a port-scanner. Anyhow, TCP-Reset cans turn a asymmetric DoS attack/flood (one-way) into an symmetric DoS/flood because now your host is generating traffic by replying to these otherwise useless packets. You could set a limit rule on sending a TCP-Reset..I know. I am not one that enjoys people breaking RFCs, but in this case it does make *some* sense. If someone is randomly port scanning class C's and they hit your IP, get no response from an ICMP (1) echo-request (8) and then try a few ports and get no TCP-Resets, they are likely to think you are a dead IP[1]. 1. Unless they are on your subnet and they can send an ARP request for the IP and your machine responds. The statement above assumes the attacker/researcher is not on your subnet. - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIBccS3Jybf3L5MQRAn+0AJ9vtu7B447kmAmkoEwdV/eeRP5m6QCaAh1F rvPYB97zggBJWMeJBKK8HvA= =r1v0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
* Quoting Phillip Hofmeister ([EMAIL PROTECTED]): As mentioned before, it is a port-scanner. Anyhow, TCP-Reset cans turn Ack. a asymmetric DoS attack/flood (one-way) into an symmetric DoS/flood because now your host is generating traffic by replying to these otherwise useless packets. You could set a limit rule on sending a A DoS attack is a different scenario than a port scan. In normal situation you create more load cause of the TCP-retransmission. TCP-Reset..I know. I am not one that enjoys people breaking RFCs, but in this case it does make *some* sense. If someone is randomly port scanning class C's and they hit your IP, get no response from an ICMP (1) echo-request (8) and then try a few ports and get no TCP-Resets, they are likely to think you are a dead IP[1]. You would get a ICMP host-unreachable from the last router in that case. - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re[2]: Hacked - is it my turn? - interesting
Hello Phillip, Tuesday, February 3, 2004, 10:42:03 PM, you wrote: PH On Tue, 03 Feb 2004 at 08:55:51AM -0500, Philipp Schulte wrote: nmap is not a sniffer but a portscanner. It's true that nmap is slowed down by DROP but this doesn't improve security very much and can have some annoying side effects (i.e. timeouts with ident-lookups). PH $IPTABLES -A ETH0-IN -p tcp --dport 113 -j REJECT --reject-with PH tcp-reset about it - i'm using nullidentd with username like 'nat' instead of blocking port. is it fine too ? -- Best regards, Marek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
On Tue, Feb 03, 2004 at 03:48:46PM +0100, Fran?ois TOURDE wrote: Ok, but I don't want somebody debug on *my* machine. It's only allowed for me :) As long as your machine is working, I guess you don't need to debug it! // George -- George Georgalis, Admin/Architect cell: 646-331-2027IXOYE Linux Infrastructure, Security mailto:[EMAIL PROTECTED] Services, Multimedia and Metrics. http://www.galis.org/george -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Rolf, On Tue, 03 Feb 2004 at 06:11:34PM -0500, Rolf Kutz wrote: TCP-Reset..I know. I am not one that enjoys people breaking RFCs, but in this case it does make *some* sense. If someone is randomly port scanning class C's and they hit your IP, get no response from an ICMP (1) echo-request (8) and then try a few ports and get no TCP-Resets, they are likely to think you are a dead IP[1]. You would get a ICMP host-unreachable from the last router in that case. I don't believe this is always the case. [EMAIL PROTECTED]:~$ sudo hping 63.165.217.29 -S -p 80 Enter password for SUDO: HPING 63.165.217.29 (eth0 63.165.217.29): S set, 40 headers + 0 data bytes - --- 63.165.217.29 hping statistic --- 56 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms [EMAIL PROTECTED]:~$ ping 63.165.217.29 PING 63.165.217.29 (63.165.217.29): 56 data bytes - --- 63.165.217.29 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss I KNOW that IP address is currently not in service (I am the network admin). I also did a tcpdump (in the case hping did not report ICMP host-unreachable received. No ICMP packets were seen... It may be the RFC specification that an ICMP host-unreachable be sent, but in practice this is no where near always the case. Note: The last router is a Cisco router maintained by an ISP. No, I am not on the same subnet as 63.165.219.29. Take care, - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIDPyS3Jybf3L5MQRAns7AJ9sAkTwrpyUyXpVq80KaBE4jNK21QCgktRB hQqMg9NdcAjWBX/BMOutGIQ= =HlvF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
On Tue, Feb 03, 2004 at 05:38:40AM +0100, Philipp Schulte wrote: No, with REJECT they would show up as closed. DROP produces filtered. FWIW, you also need --reject-with tcp-reset to fool nmap. Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Re: Hacked - is it my turn? - interesting
Le 12451ième jour après Epoch, Richard Atterer écrivait: On Tue, Feb 03, 2004 at 05:38:40AM +0100, Philipp Schulte wrote: No, with REJECT they would show up as closed. DROP produces filtered. FWIW, you also need --reject-with tcp-reset to fool nmap. But I think DROP is the best way, 'cause it slow down NMAP or other sniffers. Sniffers must wait packet timeout, then retry, then wait, etc. -- Problem solving under linux has never been the circus that it is under AIX. (By Pete Ehlke in comp.unix.aix)
Re: Hacked - is it my turn? - interesting
François TOURDE wrote: But I think DROP is the best way, 'cause it slow down NMAP or other sniffers. nmap is not a sniffer but a portscanner. It's true that nmap is slowed down by DROP but this doesn't improve security very much and can have some annoying side effects (i.e. timeouts with ident-lookups).
Re: Hacked - is it my turn? - interesting
* Quoting François TOURDE ([EMAIL PROTECTED]): But I think DROP is the best way, 'cause it slow down NMAP or other sniffers. Sniffers must wait packet timeout, then retry, then wait, etc. Your fooling yourself. What prevents sniffers from sending multiple packets at once[0]. And you're breaking the TCP-Protocol, which makes debugging much harder. - Rolf [0] I don't think that portscans are a threat anyway and you increase your network load by dropping packages.
Re: Hacked - is it my turn? - interesting
On Tue, Feb 03, 2004 at 05:38:40AM +0100, Philipp Schulte wrote: Those ports are not showing up as open. 'Filtered' does not mean open. If you run 'iptables -A INPUT -p tcp --dport 1524 -j REJECT' you'll get this exact behavior, with nothing listening on these ports. No, with REJECT they would show up as closed. DROP produces filtered. Nope. With REJECT, the kernel will send an ICMP port unreachable response, which causes nmap to think filtered. If you add the --reject-with tcp-reset flag to the iptables command, then the kernel will send a TCP packet with the RST flag set, which indicates a closed port. noah pgpme1OkhCiNk.pgp Description: PGP signature
Re: Hacked - is it my turn? - interesting
On Tue, Feb 03, 2004 at 02:09:42PM +0100, François TOURDE wrote: Le 12451i?me jour apr?s Epoch, Richard Atterer écrivait: On Tue, Feb 03, 2004 at 05:38:40AM +0100, Philipp Schulte wrote: No, with REJECT they would show up as closed. DROP produces filtered. FWIW, you also need --reject-with tcp-reset to fool nmap. But I think DROP is the best way, 'cause it slow down NMAP or other sniffers. Sniffers must wait packet timeout, then retry, then wait, etc. Check out the TARPIT target [*] if you're to take this route, but beware it is really a killer patch--at least, we've had a misconfigured rule that caused significant head ache to our legitim users. [*] http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-TARPIT bit, adam -- Am I a cleric? | 1024D/37B8D989 Or maybe a sinner? | 954B 998A E5F5 BA2A 3622 Unbeliever?| 82DD 54C2 843D 37B8 D989 Renegade? | http://sks.dnsalias.net
Re: Hacked - is it my turn? - interesting
Le 12451ième jour après Epoch, Rolf Kutz écrivait: * Quoting François TOURDE ([EMAIL PROTECTED]): But I think DROP is the best way, 'cause it slow down NMAP or other sniffers. Sniffers must wait packet timeout, then retry, then wait, etc. Your fooling yourself. What prevents sniffers from sending multiple packets at once[0]. Nothing, but with or without DROP. And you're breaking the TCP-Protocol, which makes debugging much harder. Ok, but I don't want somebody debug on *my* machine. It's only allowed for me :) -- She was good at playing abstract confusion in the same way a midget is good at being short. -- Clive James, on Marilyn Monroe
Re: Hacked - is it my turn? - interesting
On Tue, 03 Feb 2004 at 08:55:51AM -0500, Philipp Schulte wrote: nmap is not a sniffer but a portscanner. It's true that nmap is slowed down by DROP but this doesn't improve security very much and can have some annoying side effects (i.e. timeouts with ident-lookups). $IPTABLES -A ETH0-IN -p tcp --dport 113 -j REJECT --reject-with tcp-reset -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import
Re: Hacked - is it my turn? - interesting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Feb 2004 at 09:03:31AM -0500, Rolf Kutz wrote: Your fooling yourself. What prevents sniffers from sending multiple packets at once[0]. And you're breaking the TCP-Protocol, which makes debugging much harder. As mentioned before, it is a port-scanner. Anyhow, TCP-Reset cans turn a asymmetric DoS attack/flood (one-way) into an symmetric DoS/flood because now your host is generating traffic by replying to these otherwise useless packets. You could set a limit rule on sending a TCP-Reset..I know. I am not one that enjoys people breaking RFCs, but in this case it does make *some* sense. If someone is randomly port scanning class C's and they hit your IP, get no response from an ICMP (1) echo-request (8) and then try a few ports and get no TCP-Resets, they are likely to think you are a dead IP[1]. 1. Unless they are on your subnet and they can send an ARP request for the IP and your machine responds. The statement above assumes the attacker/researcher is not on your subnet. - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIBccS3Jybf3L5MQRAn+0AJ9vtu7B447kmAmkoEwdV/eeRP5m6QCaAh1F rvPYB97zggBJWMeJBKK8HvA= =r1v0 -END PGP SIGNATURE-
Re: Hacked - is it my turn? - interesting
* Quoting Phillip Hofmeister ([EMAIL PROTECTED]): As mentioned before, it is a port-scanner. Anyhow, TCP-Reset cans turn Ack. a asymmetric DoS attack/flood (one-way) into an symmetric DoS/flood because now your host is generating traffic by replying to these otherwise useless packets. You could set a limit rule on sending a A DoS attack is a different scenario than a port scan. In normal situation you create more load cause of the TCP-retransmission. TCP-Reset..I know. I am not one that enjoys people breaking RFCs, but in this case it does make *some* sense. If someone is randomly port scanning class C's and they hit your IP, get no response from an ICMP (1) echo-request (8) and then try a few ports and get no TCP-Resets, they are likely to think you are a dead IP[1]. You would get a ICMP host-unreachable from the last router in that case. - Rolf
Re[2]: Hacked - is it my turn? - interesting
Hello Phillip, Tuesday, February 3, 2004, 10:42:03 PM, you wrote: PH On Tue, 03 Feb 2004 at 08:55:51AM -0500, Philipp Schulte wrote: nmap is not a sniffer but a portscanner. It's true that nmap is slowed down by DROP but this doesn't improve security very much and can have some annoying side effects (i.e. timeouts with ident-lookups). PH $IPTABLES -A ETH0-IN -p tcp --dport 113 -j REJECT --reject-with PH tcp-reset about it - i'm using nullidentd with username like 'nat' instead of blocking port. is it fine too ? -- Best regards, Marek
Re: Hacked - is it my turn? - interesting
On Tue, Feb 03, 2004 at 03:48:46PM +0100, Fran?ois TOURDE wrote: Ok, but I don't want somebody debug on *my* machine. It's only allowed for me :) As long as your machine is working, I guess you don't need to debug it! // George -- George Georgalis, Admin/Architect cell: 646-331-2027IXOYE Linux Infrastructure, Security mailto:[EMAIL PROTECTED] Services, Multimedia and Metrics. http://www.galis.org/george
Re: Hacked - is it my turn? - interesting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Rolf, On Tue, 03 Feb 2004 at 06:11:34PM -0500, Rolf Kutz wrote: TCP-Reset..I know. I am not one that enjoys people breaking RFCs, but in this case it does make *some* sense. If someone is randomly port scanning class C's and they hit your IP, get no response from an ICMP (1) echo-request (8) and then try a few ports and get no TCP-Resets, they are likely to think you are a dead IP[1]. You would get a ICMP host-unreachable from the last router in that case. I don't believe this is always the case. [EMAIL PROTECTED]:~$ sudo hping 63.165.217.29 -S -p 80 Enter password for SUDO: HPING 63.165.217.29 (eth0 63.165.217.29): S set, 40 headers + 0 data bytes - --- 63.165.217.29 hping statistic --- 56 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms [EMAIL PROTECTED]:~$ ping 63.165.217.29 PING 63.165.217.29 (63.165.217.29): 56 data bytes - --- 63.165.217.29 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss I KNOW that IP address is currently not in service (I am the network admin). I also did a tcpdump (in the case hping did not report ICMP host-unreachable received. No ICMP packets were seen... It may be the RFC specification that an ICMP host-unreachable be sent, but in practice this is no where near always the case. Note: The last router is a Cisco router maintained by an ISP. No, I am not on the same subnet as 63.165.219.29. Take care, - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAIDPyS3Jybf3L5MQRAns7AJ9sAkTwrpyUyXpVq80KaBE4jNK21QCgktRB hQqMg9NdcAjWBX/BMOutGIQ= =HlvF -END PGP SIGNATURE-
Re: Hacked - is it my turn? - interesting
Le 12452ième jour après Epoch, George Georgalis écrivait: On Tue, Feb 03, 2004 at 03:48:46PM +0100, Fran?ois TOURDE wrote: Ok, but I don't want somebody debug on *my* machine. It's only allowed for me :) As long as your machine is working, I guess you don't need to debug it! Right! So I use DROP, and I'll use TARPIT asap :) Sorry for the non RFC-compliant machine. -- Honk if you are against noise pollution!
Hacked - is it my turn?
Hello, As of this morning two of my machines - which are regularly contacted trough ssh from each other - showed this message upon 'chkrootkit': Checking 'bindshell'... INFECTED [PORTS: 1524 31337] Checking 'lkm'... You have 4 processes hidden for ps command The latter happened to me before and I had gotten info on how this check doesn't work from this newsgroup ... but the former never showed up before. 'nmap' to those ports gives me: PORT STATESERVICE 1524/tcp filtered ingreslock 31337/tcp filtered Elite Checksecurity reports this: Security Violations for su =-=-=-=-=-=-=-=-=-=-=-=-=- Feb 2 06:33:11 server_name su[16863]: + ??? root:nobody 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide (cd-burned database, unsafe binary) or debsums (unsafe binary). Am I hacked? What else can I do to investigate the situation further? Thanks, Joh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn?
On 2004.02.02 21:08, Johannes Graumann wrote: Hello, Checksecurity reports this: Security Violations for su =-=-=-=-=-=-=-=-=-=-=-=-=- Feb 2 06:33:11 server_name su[16863]: + ??? root:nobody 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide (cd-burned database, unsafe binary) or debsums (unsafe binary). Hi, have something similar here: # Performing signature check of system binaries... NEW: --WARN-- [sig004w] None of the following versions of /bin/ping (-rwsr-xr-x) matched the /bin/ping on this machine. NEW: --WARN-- [sig004w] None of the following versions of /usr/bin/at (-rwsr-xr-x) matched the /usr/bin/at on this machine. NEW: --WARN-- [sig004w] None of the following versions of /usr/sbin/ inetd (-rwxr-xr-x) matched the /usr/sbin/inetd on this machine. # Checking for correct umask settings... # Performing common access checks for root... Considerung this kind of behavior is on two machines now makes me assume this might be another bug with tiger. :-) BTW, the machine logging this has sid installed. Moreover, I got these messages: # Performing check of 'services' ... OLD: --FAIL-- [inet002f] Service binkp is assigned to port 24554/tcp which should be 24554/udp. OLD: --FAIL-- [inet002f] Service fido is assigned to port 60179/tcp which should be 60179/udp. OLD: --FAIL-- [inet002f] Service ircd is assigned to port 6667/tcp which should be 6667/udp. OLD: --FAIL-- [inet002f] Service tfido is assigned to port 60177/tcp which should be 60177/udp. OLD: --FAIL-- [inet002f] Service tproxy is assigned to port 8081/tcp which should be 8081/udp. OLD: --FAIL-- [inet002f] Service webcache is assigned to port 8080/tcp which should be 8080/udp. Is that anything to be worried about? After all, it's just some mappings in /etc/services, or is it? I don't run an ircd (I know of), for instance, and the other ports mentioned here are not shown as open by nmap/netstat. Best regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
On Mon, Feb 02, 2004 at 02:54:33PM -0800, Alvin Oga wrote: If you run 'iptables -A INPUT -p tcp --dport 1524 -j REJECT' you'll get this exact behavior, with nothing listening on these ports. and am wondering, why explicitly reject those ports and not explicity reject other ports that is also not used ... Perhaps it's because some known back door or rarely used (but often running by default) service was one one of those ports. IIRC, some well known back door listened on port 31337. It's possible that the ISP is filtering it on their routers, and thus the scan showed it as filtered (assuming that the scan was done from elsewhere and its traffic passed through the ISP's routers). noah pgp0.pgp Description: PGP signature
Re: Hacked - is it my turn?
On Tue, 3 Feb 2004 09:55:04 +1300 (NZDT) TiM [EMAIL PROTECTED] wrote: Hello, As of this morning two of my machines - which are regularly contacted trough ssh from each other - showed this message upon 'chkrootkit': Checking 'bindshell'... INFECTED [PORTS: 1524 31337] Checking 'lkm'... You have 4 processes hidden for ps command The latter happened to me before and I had gotten info on how this check doesn't work from this newsgroup ... but the former never showed up before. 'nmap' to those ports gives me: PORT STATESERVICE 1524/tcp filtered ingreslock 31337/tcp filtered Elite Checksecurity reports this: Security Violations for su =-=-=-=-=-=-=-=-=-=-=-=-=- Feb 2 06:33:11 server_name su[16863]: + ??? root:nobody 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide(cd-burned database, unsafe binary) or debsums (unsafe binary). Am I hacked? What else can I do to investigate the situation further? Yes, I'm afraid you are. Hard to say at this time exactly how you were hacked, but it doesn't look good I'm afriad! What kernel version were are you running? Was it patched against the two recent local root exploits? I'm running a Debian 2.4.24-1-k7 stock kernel on the testing/unstable system and 2.4.18-1-k7 stock kernel on the affected stable system. I don't know what exploits you are referring to and whether the Debian team took care of them. Joh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn? - interesting
hi ya noah On Mon, 2 Feb 2004, Noah Meyerhans wrote: On Mon, Feb 02, 2004 at 02:06:41PM -0800, Alvin Oga wrote: 'nmap' to those ports gives me: PORT STATESERVICE 1524/tcp filtered ingreslock 31337/tcp filtered Elite turn off those ports ... kill ingress and whatever uses elite and keep poking around with nmap till it doesn show those ports listed Those ports are not showing up as open. 'Filtered' does not mean open. yuppers... good point ... and i prefer it to not show up at all ... If you run 'iptables -A INPUT -p tcp --dport 1524 -j REJECT' you'll get this exact behavior, with nothing listening on these ports. and am wondering, why explicitly reject those ports and not explicity reject other ports that is also not used ... have fun alvin hopefully.. nobody has a iptable config of 64k lines of rejects :-) I'm curious about what the output of 'iptables -L' looks like on this machine. I'm also curious about any routers or other network devices that might exist between the source and target of this scan. They are also capable of creating this behavior. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hacked - is it my turn?
On Mon, Feb 02, 2004 at 10:59:11PM +0100, Andreas Schmidt wrote: =-=-=-=-=-=-=-=-=-=-=-=-=- Feb 2 06:33:11 server_name su[16863]: + ??? root:nobody That's normal, its been discussed here before. It just needs to be added to logcheck patterns, a bug should be filed. 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide (cd-burned database, unsafe binary) or debsums (unsafe binary). Hi, have something similar here: # Performing signature check of system binaries... Do _not_ rely on that if you are _not_ using a stable system (and really, even then, unless you've regenerated the database yourself). Considerung this kind of behavior is on two machines now makes me assume this might be another bug with tiger. :-) Well, it _kind_ of is, but that test should not be enabled on systems running sid or testing. The signature database is rarely updated (but you can update it yourself). In any case, rely on an integrity database (aide, tripwire, samhain, integrit... your call) instead of Tiger since it will only: - check against a signature database based on woody, which will never match yours. - check using 'debsums' which is not complete (some packages do not include md5 checksums for all the files) BTW, the machine logging this has sid installed. Moreover, I got these messages: # Performing check of 'services' ... (...) Is that anything to be worried about? After all, it's just some mappings in /etc/services, or is it? I don't run an ircd (I know of), for instance, and the other ports mentioned here are not shown as open by nmap/netstat. Yes, that just compares the system's /etc/services against the list that Tiger has which, again, might not match what you have in a sid system if you have upgraded netbase. I will take care of those probably before the release, feel free to file a bug, however. Regards Javi signature.asc Description: Digital signature
Re: Hacked - is it my turn? - interesting
On Mon, Feb 02, 2004 at 05:58:29PM -0500, Noah Meyerhans wrote: On Mon, Feb 02, 2004 at 02:54:33PM -0800, Alvin Oga wrote: If you run 'iptables -A INPUT -p tcp --dport 1524 -j REJECT' you'll get this exact behavior, with nothing listening on these ports. and am wondering, why explicitly reject those ports and not explicity reject other ports that is also not used ... Perhaps it's because some known back door or rarely used (but often running by default) service was one one of those ports. IIRC, some well known back door listened on port 31337. It's possible that the ISP is filtering it on their routers, and thus the scan showed it as filtered (assuming that the scan was done from elsewhere and its traffic passed through the ISP's routers). These might come in handy http://www.networkice.com/advice/Exploits/Ports/ List of frequently seen TCP and UDP ports and what they mean. http://www.portsdb.org/ internet ports database http://www.sans.org/resources/idfaq/oddports.php Default ports used by some known trojan horses The filter is prob an ISP one... 31337 Back Orifice // George -- George Georgalis, Admin/Architect cell: 646-331-2027IXOYE Linux Infrastructure, Security mailto:[EMAIL PROTECTED] Services, Multimedia and Metrics. http://www.galis.org/george -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hacked - is it my turn?
Hello, As of this morning two of my machines - which are regularly contacted trough ssh from each other - showed this message upon 'chkrootkit': Checking 'bindshell'... INFECTED [PORTS: 1524 31337] Checking 'lkm'... You have 4 processes hidden for ps command The latter happened to me before and I had gotten info on how this check doesn't work from this newsgroup ... but the former never showed up before. 'nmap' to those ports gives me: PORT STATESERVICE 1524/tcp filtered ingreslock 31337/tcp filtered Elite Checksecurity reports this: Security Violations for su =-=-=-=-=-=-=-=-=-=-=-=-=- Feb 2 06:33:11 server_name su[16863]: + ??? root:nobody 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide (cd-burned database, unsafe binary) or debsums (unsafe binary). Am I hacked? What else can I do to investigate the situation further? Thanks, Joh
Re: Hacked - is it my turn?
Yep, it definately looks like you're hacked with those ports open unless you've installed something that uses them. I'd look into those hidden processes also but I know there's a problem with procfs or something that causes some hidden pid's 2-5 or something. check out http://www.soohrt.org/stuff/linux/suckit/ if in doubt. Eric Johannes Graumann wrote: Hello, As of this morning two of my machines - which are regularly contacted trough ssh from each other - showed this message upon 'chkrootkit': Checking 'bindshell'... INFECTED [PORTS: 1524 31337] Checking 'lkm'... You have 4 processes hidden for ps command The latter happened to me before and I had gotten info on how this check doesn't work from this newsgroup ... but the former never showed up before. 'nmap' to those ports gives me: PORT STATESERVICE 1524/tcp filtered ingreslock 31337/tcp filtered Elite Checksecurity reports this: Security Violations for su =-=-=-=-=-=-=-=-=-=-=-=-=- Feb 2 06:33:11 server_name su[16863]: + ??? root:nobody 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide (cd-burned database, unsafe binary) or debsums (unsafe binary). Am I hacked? What else can I do to investigate the situation further? Thanks, Joh -- Eric Nelson [EMAIL PROTECTED] http://www.megahosted.com/~en/ GPG-key: C4AB5707 Fingerprint: 9E50 D5C2 2B02 A944 1A28 5CA5 366A 0294 C4AB 5707
Re: Hacked - is it my turn?
On 2004.02.02 21:08, Johannes Graumann wrote: Hello, Checksecurity reports this: Security Violations for su =-=-=-=-=-=-=-=-=-=-=-=-=- Feb 2 06:33:11 server_name su[16863]: + ??? root:nobody 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide (cd-burned database, unsafe binary) or debsums (unsafe binary). Hi, have something similar here: # Performing signature check of system binaries... NEW: --WARN-- [sig004w] None of the following versions of /bin/ping (-rwsr-xr-x) matched the /bin/ping on this machine. NEW: --WARN-- [sig004w] None of the following versions of /usr/bin/at (-rwsr-xr-x) matched the /usr/bin/at on this machine. NEW: --WARN-- [sig004w] None of the following versions of /usr/sbin/ inetd (-rwxr-xr-x) matched the /usr/sbin/inetd on this machine. # Checking for correct umask settings... # Performing common access checks for root... Considerung this kind of behavior is on two machines now makes me assume this might be another bug with tiger. :-) BTW, the machine logging this has sid installed. Moreover, I got these messages: # Performing check of 'services' ... OLD: --FAIL-- [inet002f] Service binkp is assigned to port 24554/tcp which should be 24554/udp. OLD: --FAIL-- [inet002f] Service fido is assigned to port 60179/tcp which should be 60179/udp. OLD: --FAIL-- [inet002f] Service ircd is assigned to port 6667/tcp which should be 6667/udp. OLD: --FAIL-- [inet002f] Service tfido is assigned to port 60177/tcp which should be 60177/udp. OLD: --FAIL-- [inet002f] Service tproxy is assigned to port 8081/tcp which should be 8081/udp. OLD: --FAIL-- [inet002f] Service webcache is assigned to port 8080/tcp which should be 8080/udp. Is that anything to be worried about? After all, it's just some mappings in /etc/services, or is it? I don't run an ircd (I know of), for instance, and the other ports mentioned here are not shown as open by nmap/netstat. Best regards, Andreas
Re: Hacked - is it my turn? - interesting
hi ya Johannes if you ( a debian box?? ) have been hacked .. other hosts are equally susceptable .. finding out what is going on is important On Sun, 1 Feb 2004, Eric Nelson wrote: Yep, it definately looks like you're hacked with those ports open unless hummm... i'm not as sure .. so i'd like to pose a few questions you've installed something that uses them. I'd look into those hidden processes also but I know there's a problem with procfs or something that causes some hidden pid's 2-5 or something. check out http://www.soohrt.org/stuff/linux/suckit/ if in doubt. .. Johannes Graumann wrote: Hello, As of this morning two of my machines - which are regularly contacted trough ssh from each other - showed this message upon 'chkrootkit': Checking 'bindshell'... INFECTED [PORTS: 1524 31337] Checking 'lkm'... You have 4 processes hidden for ps command i'd ignore the chkrootkit flagging lkm ... known problem ?? i'd ignore the misleading bindshell problem on those ports 'nmap' to those ports gives me: PORT STATESERVICE 1524/tcp filtered ingreslock 31337/tcp filtered Elite turn off those ports ... kill ingress and whatever uses elite and keep poking around with nmap till it doesn show those ports listed this should tell you which binary is running on that port lsof -V -i :1524 this is your homework to keep fiddling till nmap doesnt report ports you cannot answer as what app is running on it and why 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. what precisely doesnt match ??? - time stamps ?? size of the files ?? - if the binaries ( size of the files ) doesn't match, was there an upgrade from apt-get update ; apt-get update .. ( ps-util package and other basic packages, i forgot which ones ( that contains those binaries, looks like a couple 2-3 packages is the tiger db up to date did you make a binary copy of all of your important files BEFORE teh system go online so you can verify anything that is claimed to be not matching the clean ( un-infected/un-modified ) copy tar zcvf /mnt/safeplace/root.clean.tgz /root /boot /lib /sbin /bin /etc ... tar zcvf /mnt/safeplace/var.clean.tgz /var tar zcvf /mnt/safeplace/usr.clean.tgz /usr ... where /mnt/safeplace is while the system is NOT accessible from the outside and you can write *.clean.tgz off onto cdrom BEFORE going live always double check everything against a cdrom ... BEFORE that system went live. ... than there'd be no doubt .. you can rebuild from cdrom, apply the patches and updates and you should have the same as your current suspect box or different if it was modified This can not be confirmed by aide (cd-burned database, unsafe binary) or debsums (unsafe binary). why not ?? aide should be able to tell you what matches and doesnt match its db ??? Am I hacked? What else can I do to investigate the situation further? get the ports cleared up from nmap's view fix tiger and aide db ... - keep your previous db on cdrom ... c ya alvin
Re: Hacked - is it my turn? - interesting
On Mon, Feb 02, 2004 at 02:06:41PM -0800, Alvin Oga wrote: 'nmap' to those ports gives me: PORT STATESERVICE 1524/tcp filtered ingreslock 31337/tcp filtered Elite turn off those ports ... kill ingress and whatever uses elite and keep poking around with nmap till it doesn show those ports listed Those ports are not showing up as open. 'Filtered' does not mean open. If you run 'iptables -A INPUT -p tcp --dport 1524 -j REJECT' you'll get this exact behavior, with nothing listening on these ports. I'm curious about what the output of 'iptables -L' looks like on this machine. I'm also curious about any routers or other network devices that might exist between the source and target of this scan. They are also capable of creating this behavior. noah pgpWr0iL9roA0.pgp Description: PGP signature
Re: Hacked - is it my turn? - interesting
On Mon, Feb 02, 2004 at 02:54:33PM -0800, Alvin Oga wrote: If you run 'iptables -A INPUT -p tcp --dport 1524 -j REJECT' you'll get this exact behavior, with nothing listening on these ports. and am wondering, why explicitly reject those ports and not explicity reject other ports that is also not used ... Perhaps it's because some known back door or rarely used (but often running by default) service was one one of those ports. IIRC, some well known back door listened on port 31337. It's possible that the ISP is filtering it on their routers, and thus the scan showed it as filtered (assuming that the scan was done from elsewhere and its traffic passed through the ISP's routers). noah pgp6jUQQVtB2r.pgp Description: PGP signature
Re: Hacked - is it my turn?
On Tue, 3 Feb 2004 09:55:04 +1300 (NZDT) TiM [EMAIL PROTECTED] wrote: Hello, As of this morning two of my machines - which are regularly contacted trough ssh from each other - showed this message upon 'chkrootkit': Checking 'bindshell'... INFECTED [PORTS: 1524 31337] Checking 'lkm'... You have 4 processes hidden for ps command The latter happened to me before and I had gotten info on how this check doesn't work from this newsgroup ... but the former never showed up before. 'nmap' to those ports gives me: PORT STATESERVICE 1524/tcp filtered ingreslock 31337/tcp filtered Elite Checksecurity reports this: Security Violations for su =-=-=-=-=-=-=-=-=-=-=-=-=- Feb 2 06:33:11 server_name su[16863]: + ??? root:nobody 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide(cd-burned database, unsafe binary) or debsums (unsafe binary). Am I hacked? What else can I do to investigate the situation further? Yes, I'm afraid you are. Hard to say at this time exactly how you were hacked, but it doesn't look good I'm afriad! What kernel version were are you running? Was it patched against the two recent local root exploits? I'm running a Debian 2.4.24-1-k7 stock kernel on the testing/unstable system and 2.4.18-1-k7 stock kernel on the affected stable system. I don't know what exploits you are referring to and whether the Debian team took care of them. Joh
Re: Hacked - is it my turn? - interesting
hi ya noah On Mon, 2 Feb 2004, Noah Meyerhans wrote: On Mon, Feb 02, 2004 at 02:06:41PM -0800, Alvin Oga wrote: 'nmap' to those ports gives me: PORT STATESERVICE 1524/tcp filtered ingreslock 31337/tcp filtered Elite turn off those ports ... kill ingress and whatever uses elite and keep poking around with nmap till it doesn show those ports listed Those ports are not showing up as open. 'Filtered' does not mean open. yuppers... good point ... and i prefer it to not show up at all ... If you run 'iptables -A INPUT -p tcp --dport 1524 -j REJECT' you'll get this exact behavior, with nothing listening on these ports. and am wondering, why explicitly reject those ports and not explicity reject other ports that is also not used ... have fun alvin hopefully.. nobody has a iptable config of 64k lines of rejects :-) I'm curious about what the output of 'iptables -L' looks like on this machine. I'm also curious about any routers or other network devices that might exist between the source and target of this scan. They are also capable of creating this behavior.
Re: Hacked - is it my turn?
On Mon, Feb 02, 2004 at 10:59:11PM +0100, Andreas Schmidt wrote: =-=-=-=-=-=-=-=-=-=-=-=-=- Feb 2 06:33:11 server_name su[16863]: + ??? root:nobody That's normal, its been discussed here before. It just needs to be added to logcheck patterns, a bug should be filed. 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide (cd-burned database, unsafe binary) or debsums (unsafe binary). Hi, have something similar here: # Performing signature check of system binaries... Do _not_ rely on that if you are _not_ using a stable system (and really, even then, unless you've regenerated the database yourself). Considerung this kind of behavior is on two machines now makes me assume this might be another bug with tiger. :-) Well, it _kind_ of is, but that test should not be enabled on systems running sid or testing. The signature database is rarely updated (but you can update it yourself). In any case, rely on an integrity database (aide, tripwire, samhain, integrit... your call) instead of Tiger since it will only: - check against a signature database based on woody, which will never match yours. - check using 'debsums' which is not complete (some packages do not include md5 checksums for all the files) BTW, the machine logging this has sid installed. Moreover, I got these messages: # Performing check of 'services' ... (...) Is that anything to be worried about? After all, it's just some mappings in /etc/services, or is it? I don't run an ircd (I know of), for instance, and the other ports mentioned here are not shown as open by nmap/netstat. Yes, that just compares the system's /etc/services against the list that Tiger has which, again, might not match what you have in a sid system if you have upgraded netbase. I will take care of those probably before the release, feel free to file a bug, however. Regards Javi signature.asc Description: Digital signature
Re: Hacked - is it my turn? - interesting
hi ya noah On Mon, 2 Feb 2004, Noah Meyerhans wrote: On Mon, Feb 02, 2004 at 02:54:33PM -0800, Alvin Oga wrote: If you run 'iptables -A INPUT -p tcp --dport 1524 -j REJECT' you'll get this exact behavior, with nothing listening on these ports. and am wondering, why explicitly reject those ports and not explicity reject other ports that is also not used ... Perhaps it's because some known back door or rarely used (but often running by default) service was one one of those ports. IIRC, some well known back door listened on port 31337. It's possible that the ISP is filtering it on their routers, and thus the scan showed it as filtered (assuming that the scan was done from elsewhere and its traffic passed through the ISP's routers). yuo.. one does need to scan locally, than scan from ones own network and than from outside ( locally == just 2 pcs .. the scanner and the scanee ) should be fun to see what comes out of all the original posters checking have fun alvin
Re: Hacked - is it my turn? - interesting
On Mon, Feb 02, 2004 at 05:58:29PM -0500, Noah Meyerhans wrote: On Mon, Feb 02, 2004 at 02:54:33PM -0800, Alvin Oga wrote: If you run 'iptables -A INPUT -p tcp --dport 1524 -j REJECT' you'll get this exact behavior, with nothing listening on these ports. and am wondering, why explicitly reject those ports and not explicity reject other ports that is also not used ... Perhaps it's because some known back door or rarely used (but often running by default) service was one one of those ports. IIRC, some well known back door listened on port 31337. It's possible that the ISP is filtering it on their routers, and thus the scan showed it as filtered (assuming that the scan was done from elsewhere and its traffic passed through the ISP's routers). These might come in handy http://www.networkice.com/advice/Exploits/Ports/ List of frequently seen TCP and UDP ports and what they mean. http://www.portsdb.org/ internet ports database http://www.sans.org/resources/idfaq/oddports.php Default ports used by some known trojan horses The filter is prob an ISP one... 31337 Back Orifice // George -- George Georgalis, Admin/Architect cell: 646-331-2027IXOYE Linux Infrastructure, Security mailto:[EMAIL PROTECTED] Services, Multimedia and Metrics. http://www.galis.org/george
Re: Hacked - is it my turn?
Hello again, Here is what I make of my evidence at the end of a quite anxious day. I would highly appreciate any comments on my conclusions! Checking 'bindshell'... INFECTED [PORTS: 1524 31337] At this point I believe to be able to attribute this to portsentry running - '/etc/init.d/portsentry stop' makes it go away, '/etc/init.d/portsentry start' makes it reappear and I can create the message on a pristine system by installing portsentry (running in the default configuration). Checksecurity reports this: Security Violations for su =-=-=-=-=-=-=-=-=-=-=-=-=- Feb 2 06:33:11 server_name su[16863]: + ??? root:nobody As Javier Fernández-Sanguino Peña [EMAIL PROTECTED] pointed out in a branch thread : That's normal, its been discussed here before. It just needs to be added to logcheck patterns, a bug should be filed. Digging in the logs also showed this to be happening around 6:30 every morning - must be related t one of my cron jobs that are being triggered then, as /etc/crontab reads 25 6 * * * root test -e /usr/bin/anachron || run-parts --report /etc/cron.daily 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide (cd-burned database, unsafe binary) or debsums (unsafe binary). Javier stated as well: Do _not_ rely on that if you are _not_ using a stable system (and really, even then, unless you've regenerated the database yourself). This is a testing/unstable system. Now the conclusion: at this point there doesn't seem to be any real evidence for compromise over here. My current working hypothesis is that one of the packages involved had a update recently - I haven't really payed attention to what happened during my updates - and I started to see some log extracts I wasn't used to and couldn't make proper sense of and panicked. If you don't buy this: please let me know and why. Since We are talking 20+ systems being dependent on one of the machines in question, I'm considering myself biased due to installation anxiety. Hope to hear from you, Joh
Re: Hacked - is it my turn?
hi ya johannes On Mon, 2 Feb 2004, Johannes Graumann wrote: Checking 'bindshell'... INFECTED [PORTS: 1524 31337] At this point I believe to be able to attribute this to portsentry running - '/etc/init.d/portsentry stop' makes it go away, '/etc/init.d/portsentry start' makes it reappear and I can create the message on a pristine system by installing portsentry (running in the default configuration). odd that portsentry does that... oh welll ... 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide (cd-burned database, unsafe binary) or debsums (unsafe binary). Javier stated as well: Do _not_ rely on that if you are _not_ using a stable system (and really, even then, unless you've regenerated the database yourself). This is a testing/unstable system. that doesn't explain why the semi-important binaries are not as you expected ... you still need to confirm the size/md5 of the binaries against a clean system and/or patched updated/upgraded box If you don't buy this: please let me know and why. Since We are talking 20+ systems being dependent on one of the machines in question, I'm considering myself biased due to installation anxiety. maybe its time to spend an extra $300 for a 2nd backup machine and keep it offline or more protected behind another secure firewall - and also time to put all your binaries compressed onto cdrom so that you can trivially compare binaries in a few seconds and know if its been hacked or not - you'd also need to know which binaries changed on which date from which package :-) have fun alvin
Re: Hacked - is it my turn?
On Mon, 2 Feb 2004 18:28:31 -0800 (PST), Alvin Oga wrote: On Mon, 2 Feb 2004, Johannes Graumann wrote: Checking 'bindshell'... INFECTED [PORTS: 1524 31337] At this point I believe to be able to attribute this to portsentry running - '/etc/init.d/portsentry stop' makes it go away, odd that portsentry does that... oh welll ... Um, no - I believe that's not odd at all - because Port Sentry's method is to listen on every conceivable port so that it can detect inbound connection attempts. NB: this is just hearsay - I've never actually used Port Sentry, due to reports about this very problem. In fact, IIUC you also need to have all those ports unfirewalled so that Port Sentry can do its stuff. Quite a few people think this is a Very Bad Thing ... and that's been good enough for me. [And then there's Port Sentry's attack-response feature, which can apparently leave you deaf dumb blind if someone sends you spoofed packets. I _think_ the current wisdom is that Port Sentry is an all round Bad Idea, but maybe it's just a religious thing ..] Somebody please tell me if I'm wrong here. Nick Boyce Bristol, UK -- I tried to patent patent barratry as a business model, but there was too much prior art.
Re: Hacked - is it my turn? - interesting
Noah Meyerhans wrote: Those ports are not showing up as open. 'Filtered' does not mean open. If you run 'iptables -A INPUT -p tcp --dport 1524 -j REJECT' you'll get this exact behavior, with nothing listening on these ports. No, with REJECT they would show up as closed. DROP produces filtered.
Re: Hacked - is it my turn?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Feb 2004 03:50:06 +0100, Alvin Oga [EMAIL PROTECTED] wrote: hi ya johannes On Mon, 2 Feb 2004, Johannes Graumann wrote: Checking 'bindshell'... INFECTED [PORTS: 1524 31337] At this point I believe to be able to attribute this to portsentry running - '/etc/init.d/portsentry stop' makes it go away, '/etc/init.d/portsentry start' makes it reappear and I can create the message on a pristine system by installing portsentry (running in the default configuration). odd that portsentry does that... oh welll ... portsentry opens and attaches to ports, it's famous for setting off false alarms for security tests. IMHO, it's a poor tool for using in securing a system, but it's probably better than nothing. Although you'd be far better off with snort. 'tiger' also reports - while performing signature check of system binaries, that /bin/ping, /usr/bin/chage, /usr/bin/at, /usr/bin/write and /usr/bin/inetd don not match. This can not be confirmed by aide (cd-burned database, unsafe binary) or debsums (unsafe binary). Javier stated as well: Do _not_ rely on that if you are _not_ using a stable system (and really, even then, unless you've regenerated the database yourself). This is a testing/unstable system. that doesn't explain why the semi-important binaries are not as you expected ... you still need to confirm the size/md5 of the binaries against a clean system and/or patched updated/upgraded box If you don't buy this: please let me know and why. Since We are talking 20+ systems being dependent on one of the machines in question, I'm considering myself biased due to installation anxiety. maybe its time to spend an extra $300 for a 2nd backup machine and keep it offline or more protected behind another secure firewall - and also time to put all your binaries compressed onto cdrom so that you can trivially compare binaries in a few seconds and know if its been hacked or not - you'd also need to know which binaries changed on which date from which package :-) Aide does a nice job of this, if you maintain a copy of the aide.db offsite, and check that too. On my machines, I do a series of tests Nightly aide, chkrootkit and tiger tests, verify local aide.db md5sum matches remote backup, and run the logs. I am setting up snort, for the purposes mostly of practice. These are web/mail servers, so I have a limited number of ports I have to have open, everything else is firewalled off. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAHx2Sd90bcYOAWPYRAqSwAJ0YPQCQZ5fvtsWMDRkRLTrKjcjdPQCdEtMe ahSRcZMY49OsTRoWIaCtQac= =XqM4 -END PGP SIGNATURE- -- Jim Richardson http://www.eskimo.com/~warlock It is dark. Your .sig has been eaten by a grue.
Re: Hacked - is it my turn?
hi ya nick/jim On Tue, 3 Feb 2004, Nick Boyce wrote: On Mon, 2 Feb 2004 18:28:31 -0800 (PST), Alvin Oga wrote: On Mon, 2 Feb 2004, Johannes Graumann wrote: Checking 'bindshell'... INFECTED [PORTS: 1524 31337] At this point I believe to be able to attribute this to portsentry running - '/etc/init.d/portsentry stop' makes it go away, odd that portsentry does that... oh welll ... Um, no - I believe that's not odd at all - because Port Sentry's method is to listen on every conceivable port so that it can detect inbound connection attempts. and given that portsentry supposed to watch all ports, i'm curious why only 1524 shows up and not a random selection of one of 64K port or whatever reason it uses 1524 is okay and the original poster shows/reaffirms another reason NOT to run portsentry :-0 .. a lot of false positives but a good learning experience and results in tighten the security policy before a real crack occurs - i do run logcheck .. but not portsenty :-0 and i dont like any port scan detectors running, it'd be pointless esp if one gets xxx scans per hour coming from where ever ( consider it a free audit via port scan ) c ya alvin
