[gentoo-user] nmap/iptables
I have in my home box a iptables firewall configured via shorewall with the standalone machine standard configuration (no services whatsoever to the outside world). Just for good measure, I tryed portscanning from a computer at work: (my dynamic IP number edited) $ nmap -vv IP number Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) No tcp,udp, or ICMP scantype specified, assuming vanilla tcp connect( ) scan. Use -sP if you really don't want to portscan (and just want t o see what hosts are up). Machine IP number MIGHT actually be listening on probe port 80 Host IP number appears to be up ... good. Initiating Connect() Scan against IP number Adding open port 80/tcp Bumping up senddelay by 1 (to 1), due to excessive drops Bumping up senddelay by 2 (to 3), due to excessive drops Bumping up senddelay by 3 (to 6), due to excessive drops Bumping up senddelay by 4 (to 10), due to excessive drops Bumping up senddelay by 5 (to 15), due to excessive drops Bumping up senddelay by 6 (to 21), due to excessive drops Bumping up senddelay by 75000 (to 285000), due to excessive drops Bumping up senddelay by 75000 (to 36), due to excessive drops Bumping up senddelay by 75000 (to 435000), due to excessive drops The Connect() Scan took 1038 seconds to scan 1601 ports. Interesting ports on (IP number): (The 1597 ports scanned but not shown below are in state: closed) Port State Service 6/tcp filteredunknown 25/tcp filteredsmtp 80/tcp openhttp 135/tcpfilteredloc-srv Nmap run completed -- 1 IP address (1 host up) scanned in 1038 second s The scanning from the home box itself gives a more reassuring outcome: $ nmap -vv localhost No tcp, udp, or ICMP scantype specified, assuming vanilla tcp connect() scan. Use -sP if you really don't want to portscan (and just want to see what hosts are up). Starting nmap 3.27 ( www.insecure.org/nmap/ ) at 2003-11-22 14:54 WET Host localhost (127.0.0.1) appears to be up ... good. Initiating Connect() Scan against localhost (127.0.0.1) at 14:54 Adding open port 1/tcp Adding open port 6000/tcp The Connect() Scan took 0 seconds to scan 1623 ports. Interesting ports on localhost (127.0.0.1): (The 1621 ports scanned but not shown below are in state: closed) Port State Service 6000/tcp openX11 1/tcp opensnet-sensor-mgmt Nmap run completed -- 1 IP address (1 host up) scanned in 0.633 seconds Now, why should nmap at the remote machine report that port 80 is open? I assume that this happens because nmap is not supposed to be used when the target has a firewall. Can I be right? And, if so, how can I check whether the firewall is really working as expected? Thanks for any help, Jorge Almeida -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] nmap/iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 22 November 2003 15:33, Jorge Almeida wrote: I have in my home box a iptables firewall configured via shorewall with the standalone machine standard configuration (no services whatsoever to the outside world). Just for good measure, I tryed portscanning from a computer at work: (my dynamic IP number edited) $ nmap -vv IP number Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) (The 1597 ports scanned but not shown below are in state: closed) Port State Service 6/tcp filteredunknown 25/tcp filteredsmtp 80/tcp openhttp 135/tcpfilteredloc-srv The scanning from the home box itself gives a more reassuring outcome: $ nmap -vv localhost Interesting ports on localhost (127.0.0.1): (The 1621 ports scanned but not shown below are in state: closed) Port State Service 6000/tcp openX11 1/tcp opensnet-sensor-mgmt Now, why should nmap at the remote machine report that port 80 is open? I assume that this happens because nmap is not supposed to be used when the target has a firewall. Can I be right? And, if so, how can I check whether the firewall is really working as expected? You are right not to question ports 6, 25, and 135, they will be some sort of firewall/router in your path home. Port 80 will almost certainly be open because someone along the line is trapping port 80 traffic, probably to send it off to a proxy. I do this myself on my home network, and have seen that same behaviour with an ISP I was on. - -- Mike Williams -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/v4JuInuLMrk7bIwRAgkFAJ9ClnPsq7nR3/Hj+bjXR2VhaRSK0ACdE6Gm W3od/TcgFQhLjqYPW23YD0w= =eoso -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] nmap/iptables
On Sat, 22 Nov 2003, Mike Williams wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 22 November 2003 15:33, Jorge Almeida wrote: Port 80 will almost certainly be open because someone along the line is trapping port 80 traffic, probably to send it off to a proxy. I do this myself on my home network, and have seen that same behaviour with an ISP I was on. I'm not sure I understand. Do you mean port 80 is really closed but appears open due to ISP intervention? I have privoxy installed, which uses port 8118. Could this be the kind of trapping you mention? Jorge Almeida -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] nmap/iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 22 November 2003 15:56, Jorge Almeida wrote: Port 80 will almost certainly be open because someone along the line is trapping port 80 traffic, probably to send it off to a proxy. I do this myself on my home network, and have seen that same behaviour with an ISP I was on. I'm not sure I understand. Do you mean port 80 is really closed but appears open due to ISP intervention? I have privoxy installed, which uses port 8118. Could this be the kind of trapping you mention? Yes, port 80 is really closed on your box, and is open due to ISP intervention. Best way to know for sure is to do a 'netstat -nlp' on your machine, and see if any process is listening on port 80. I'd imagine quite a lot force it's users through a farm of web proxies, no doubt saving them an awful lot of bandwidth, and support calls explaining what a web proxy is and why they have to use it. If privoxy is a web proxy which you have to specifically tell your software about, then no. The kind of thing we are seeing here is a proxy/cache which you aren't supposed to know about, or be able to easily circumvent. - -- Mike Williams -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/v4lwInuLMrk7bIwRAny9AJ46ObOKmLZdgUPNtpMEci1hgGwhgwCfY0Td /qSiENQwcM5cgHwpcY13CLA= =E87k -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] nmap/iptables
On Sat, 22 Nov 2003, Mike Williams wrote: Yes, port 80 is really closed on your box, and is open due to ISP intervention. Best way to know for sure is to do a 'netstat -nlp' on your machine, and see if any process is listening on port 80. I knew there had to exist something like that!:-) If privoxy is a web proxy which you have to specifically tell your software about, then no. It is that king of proxy, very good to avoid ads and things like that. Thanks for your help. -- Jorge Almeida -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] nmap/iptables
- Original Message - From: Jorge Almeida [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 22, 2003 4:33 PM Subject: [gentoo-user] nmap/iptables I have in my home box a iptables firewall configured via shorewall with the standalone machine standard configuration (no services whatsoever to the outside world). Just for good measure, I tryed portscanning from a computer at work: (my dynamic IP number edited) $ nmap -vv IP number Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) No tcp,udp, or ICMP scantype specified, assuming vanilla tcp connect( ) scan. Use -sP if you really don't want to portscan (and just want t o see what hosts are up). Machine IP number MIGHT actually be listening on probe port 80 Host IP number appears to be up ... good. Initiating Connect() Scan against IP number Adding open port 80/tcp Bumping up senddelay by 1 (to 1), due to excessive drops Bumping up senddelay by 2 (to 3), due to excessive drops Bumping up senddelay by 3 (to 6), due to excessive drops Bumping up senddelay by 4 (to 10), due to excessive drops Bumping up senddelay by 5 (to 15), due to excessive drops Bumping up senddelay by 6 (to 21), due to excessive drops Bumping up senddelay by 75000 (to 285000), due to excessive drops Bumping up senddelay by 75000 (to 36), due to excessive drops Bumping up senddelay by 75000 (to 435000), due to excessive drops The Connect() Scan took 1038 seconds to scan 1601 ports. Interesting ports on (IP number): (The 1597 ports scanned but not shown below are in state: closed) Port State Service 6/tcp filteredunknown 25/tcp filteredsmtp 80/tcp openhttp 135/tcpfilteredloc-srv Okay the output here means, the firewall is blocking 6, 25,135, since they show up here you didn't completely drop all packages, but only block them, this is usually safe. 80 is completely open, if you run apache, then apache will be available from outside Nmap run completed -- 1 IP address (1 host up) scanned in 1038 second s The scanning from the home box itself gives a more reassuring outcome: $ nmap -vv localhost No tcp, udp, or ICMP scantype specified, assuming vanilla tcp connect() scan. Use -sP if you really don't want to portscan (and just want to see what hosts are up). Starting nmap 3.27 ( www.insecure.org/nmap/ ) at 2003-11-22 14:54 WET Host localhost (127.0.0.1) appears to be up ... good. Initiating Connect() Scan against localhost (127.0.0.1) at 14:54 Adding open port 1/tcp Adding open port 6000/tcp The Connect() Scan took 0 seconds to scan 1623 ports. Interesting ports on localhost (127.0.0.1): (The 1621 ports scanned but not shown below are in state: closed) Port State Service 6000/tcp openX11 1/tcp opensnet-sensor-mgmt The reason why you get a completely different out put is, first of all, if you scan localhost, then you scan only services that are bound to localhost. Depends on your setup, just run nmap on your localbox but instead of nmap --vv localhost specify your real IP of the interface that connects to the internet. Also because shorewall is usually setup to block only traffic coming in from the device that connects to the internet the output will look different. Therefore the scan from outside is much more important. Nmap run completed -- 1 IP address (1 host up) scanned in 0.633 seconds Now, why should nmap at the remote machine report that port 80 is open? I assume that this happens because nmap is not supposed to be used when the target has a firewall. Can I be right? And, if so, how can I check whether the firewall is really working as expected? Thanks for any help, Jorge Almeida -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] nmap/iptables
On Sat, 22 Nov 2003, SN wrote: (The 1597 ports scanned but not shown below are in state: closed) Port State Service 6/tcp filteredunknown 25/tcp filteredsmtp 80/tcp openhttp 135/tcpfilteredloc-srv Okay the output here means, the firewall is blocking 6, 25,135, since they show up here you didn't completely drop all packages, but only block them, this is usually safe. 80 is completely open, if you run apache, then apache will be available from outside I don't run a web server, nor any other service. Host localhost (127.0.0.1) appears to be up ... good. Initiating Connect() Scan against localhost (127.0.0.1) at 14:54 Adding open port 1/tcp Adding open port 6000/tcp The Connect() Scan took 0 seconds to scan 1623 ports. Interesting ports on localhost (127.0.0.1): (The 1621 ports scanned but not shown below are in state: closed) Port State Service 6000/tcp openX11 1/tcp opensnet-sensor-mgmt The reason why you get a completely different out put is, first of all, if you scan localhost, then you scan only services that are bound to localhost. Depends on your setup, just run nmap on your localbox but instead of nmap --vv localhost specify your real IP of the interface that connects to the internet. Also because shorewall is usually setup to block only traffic coming in from the device that connects to the internet the output will look different. Therefore the scan from outside is much more important. I tried nmap -vv My IP instead of localhost and the outcome is still OK. The explanation of Mike Williams must be right, and it is confirmed by the output of netstat. Thank you for your reply. -- Jorge Almeida -- [EMAIL PROTECTED] mailing list
