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
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
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!
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! -- 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-2027< Linux Infrastructure, Security mailto:[EMAIL PROTECTED] Services, Multimedia and Metrics. http://www.galis.org/george
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
* 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: 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 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-2027< 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[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
* 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: 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
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- -- 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
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, 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
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
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
* 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
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
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
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 -- 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
* 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
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
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) -- 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
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? - 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". -- 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 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-2027< Linux Infrastructure, Security mailto:[EMAIL PROTECTED] Services, Multimedia and Metrics. http://www.galis.org/george
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-2027< 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
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
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? - 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 -- 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 pgp6jUQQVtB2r.pgp Description: PGP signature
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
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
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? - 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? - 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 pgp0.pgp Description: PGP signature
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
