Re: [arch-general] Port 80 is shown open in port scan without any web server running
On 30/03/11 14:16, Thomas Bächler wrote:
Am 30.03.2011 10:36, schrieb Partha Chowdhury:
sudo /sbin/iptables-save # Generated by iptables-save v1.4.7 on Wed Mar 30 13:59:44 2011 *filter :INPUT DROP [2844:282816] :FORWARD DROP [0:0] :OUTPUT ACCEPT [9999:990098] -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 54215 -j ACCEPT -A INPUT -p udp -m udp --dport 54215 -j ACCEPT COMMIT # Completed on Wed Mar 30 13:59:44 2011 The following is OT, but I have to say it:
This is an affront to every admin of smaller or bigger networks. It hurts my eyes. What do you try to achieve by dropping unwanted traffic? You even drop ICMP entirely - dropping ICMP is the cause of a large number of problems.
There is no security advantage, but you deliberately prevent proper communication between yourself and other computers on the internet.
Well I picked this configuration from Red Hat training books, except for port 54215 which I open for bit torrent. What do you suggest about the ideal iptables configuration for basic desktop user - allowing proper connection as you said and yet stay secure from malicious port scanners ? On 30/03/11 14:20, Jan de Groot wrote:
. Try doing an nmap -sV and you'll see what software is running on the proxyserver. I did what you said:
nmap -sV 115.187.45.97
Starting Nmap 4.20 ( http://insecure.org ) at 2011-03-30 15:06 IST Interesting ports on 115.187.45.97: Not shown: 1696 filtered ports PORT STATE SERVICE VERSION 80/tcp open http? 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi : SF-Port80-TCP:V=4.20%I=7%D=3/30%Time=4D92F9D0%P=i686-pc-linux-gnu%r(Help,D SF:DD,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nServer:\x20squid/3\.2\.0\.4-2 SF:0110203\r\nMime-Version:\x201\.0\r\nDate:\x20Wed,\x2030\x20Mar\x202011\ SF:x2009:37:20\x20GMT\r\nContent-Type:\x20text/html\r\nContent-Length:\x20 SF:3234\r\nX-Squid-Error:\x20ERR_INVALID_REQ\x200\r\nContent-Language:\x20 SF:en\r\nX-Cache:\x20MISS\x20from\x20Streamride\r\nVia:\x201\.1\x20Streamr SF:ide\x20\(squid/3\.2\.0\.4-20110203\)\r\nConnection:\x20close\r\n\r\n<!D SF:OCTYPE\x20html\x20PUBLIC\x20\"-//W3C//DTD\x20HTML\x204\.01//EN\"\x20\"h SF:ttp://www\.w3\.org/TR/html4/strict\.dtd\">\n<html><head>\n<meta\x20http SF:-equiv=\"Content-Type\"\x20content=\"text/html;\x20charset=utf-8\">\n<t SF:itle>ERROR:\x20The\x20requested\x20URL\x20could\x20not\x20be\x20retriev SF:ed</title>\n<style\x20type=\"text/css\"><!--\x20\n\x20/\*\n\x20Styleshe SF:et\x20for\x20Squid\x20Error\x20pages\n\x20Adapted\x20from\x20design\x20 SF:by\x20Free\x20CSS\x20Templates\n\x20http://www\.freecsstemplates\.org\n SF:\x20Released\x20for\x20free\x20under\x20a\x20Creative\x20Commons\x20Att SF:ribution\x202\.5\x20License\n\*/\n\n/\*\x20Page\x20basics\x20\*/\n\*\x2 SF:0{\n\tfont-family:\x20verdana,\x20sans-serif;\n}\n\nhtml\x20body\x20{\n SF:\tmargin:\x200;\n\tpadding:\x200;\n\tbackground:\x20#efefef;\n\tfont-si SF:ze:\x2012px")%r(SSLSessionReq,DE3,"HTTP/1\.1\x20400\x20Bad\x20Request\r SF:\nServer:\x20squid/3\.2\.0\.4-20110203\r\nMime-Version:\x201\.0\r\nDate SF::\x20Wed,\x2030\x20Mar\x202011\x2009:37:20\x20GMT\r\nContent-Type:\x20t SF:ext/html\r\nContent-Length:\x203240\r\nX-Squid-Error:\x20ERR_INVALID_RE SF:Q\x200\r\nContent-Language:\x20en\r\nX-Cache:\x20MISS\x20from\x20Stream SF:ride\r\nVia:\x201\.1\x20Streamride\x20\(squid/3\.2\.0\.4-20110203\)\r\n SF:Connection:\x20close\r\n\r\n<!DOCTYPE\x20html\x20PUBLIC\x20\"-//W3C//DT SF:D\x20HTML\x204\.01//EN\"\x20\"http://www\.w3\.org/TR/html4/strict\.dtd\ SF:">\n<html><head>\n<meta\x20http-equiv=\"Content-Type\"\x20content=\"tex SF:t/html;\x20charset=utf-8\">\n<title>ERROR:\x20The\x20requested\x20URL\x SF:20could\x20not\x20be\x20retrieved</title>\n<style\x20type=\"text/css\"> SF:<!--\x20\n\x20/\*\n\x20Stylesheet\x20for\x20Squid\x20Error\x20pages\n\x SF:20Adapted\x20from\x20design\x20by\x20Free\x20CSS\x20Templates\n\x20http SF:://www\.freecsstemplates\.org\n\x20Released\x20for\x20free\x20under\x20 SF:a\x20Creative\x20Commons\x20Attribution\x202\.5\x20License\n\*/\n\n/\*\ SF:x20Page\x20basics\x20\*/\n\*\x20{\n\tfont-family:\x20verdana,\x20sans-s SF:erif;\n}\n\nhtml\x20body\x20{\n\tmargin:\x200;\n\tpadding:\x200;\n\tbac SF:kground:\x20#efefef;\n\tfont-size:\x2012px");
Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ . Nmap finished: 1 IP address (1 host up) scanned in 114.226 seconds
So it seems my ISP is running squid version 3.2.0.4-20110203 in transparent mode , just like you said. Interestingly when connecting to random ip addresses on port 80, the error page returned is quite different from normal ones. http://www.freeimagehosting.net/image.php?280f0ef980.png Does this transparent proxy pose any threat and what can I do to stop that ?
On Wed, 2011-03-30 at 15:45 +0530, Partha Chowdhury wrote:
So it seems my ISP is running squid version 3.2.0.4-20110203 in transparent mode , just like you said.
Interestingly when connecting to random ip addresses on port 80, the error page returned is quite different from normal ones.
http://www.freeimagehosting.net/image.php?280f0ef980.png
Does this transparent proxy pose any threat and what can I do to stop that ?
The threat here is that your ISP will log every page visit you do and also has the ability to block certain websites. The only thing you can do is setting up a tunnel or using a different proxyserver that you trust.
On 30/03/11 15:58, Jan de Groot wrote:
The threat here is that your ISP will log every page visit you do and also has the ability to block certain websites.
The only thing you can do is setting up a tunnel or using a different proxyserver that you trust.
Doesn't every ISP keeps logs of what sites its customers are visiting for a certain amount of time ? Can you give me some pointers where I can find more information about setting up tunnel ? On 30/03/11 16:02, Simon Perry wrote:
I give up trying to understand this.
Initially you were complaining about port 80 being open on your host, you gave us a list of open ports - not an nmap of another host.
So now a transparent proxy is the concern?
initially I wanted to know why port 80 is shown open on my machine and i gave the lsof output to show that no service was listening to port 80 on my machine. The nmap output of the ip - that is my public ip at the moment ( got that by visiting whatismyip.com) shows port 80 as open when it should be blocked according to my iptables configuration. Basically i was afraid some rootkit/malware was running web server on my machine by making it invisible !
Am 30.03.2011 12:48, schrieb Partha Chowdhury:
The threat here is that your ISP will log every page visit you do and also has the ability to block certain websites.
Doesn't every ISP keeps logs of what sites its customers are visiting for a certain amount of time ?
If you live in China, yes. In a free country, I would hope not. I am pretty sure my provider does not log such information and I think it is even forbidden by law. I am also pretty sure that I do not sit behind a transparent proxy (I do at work, but not at home).
Excerpts from Thomas Bächler's message of 2011-03-30 12:57:45 +0200:
Am 30.03.2011 12:48, schrieb Partha Chowdhury:
The threat here is that your ISP will log every page visit you do and also has the ability to block certain websites.
Doesn't every ISP keeps logs of what sites its customers are visiting for a certain amount of time ?
If you live in China, yes. In a free country, I would hope not. I am pretty sure my provider does not log such information and I think it is even forbidden by law.
I am also pretty sure that I do not sit behind a transparent proxy (I do at work, but not at home).
If you live in a civilized country in Europe data retention either is already in place or will be rather soon. The US might have a different approach but I doubt the net result is much different.
On Wed, 2011-03-30 at 17:27 +0200, Philipp Überbacher wrote:
If you live in a civilized country in Europe data retention either is already in place or will be rather soon. The US might have a different approach but I doubt the net result is much different.
Those regulations are about email only. Providers have to store recipient and sender for every mail that passes their network and they have to store it for a long time, depending on what country implemented the rules.
Excerpts from Jan de Groot's message of 2011-03-30 17:52:00 +0200:
On Wed, 2011-03-30 at 17:27 +0200, Philipp Überbacher wrote:
If you live in a civilized country in Europe data retention either is already in place or will be rather soon. The US might have a different approach but I doubt the net result is much different.
Those regulations are about email only. Providers have to store recipient and sender for every mail that passes their network and they have to store it for a long time, depending on what country implemented the rules.
I doubt that: "The Directive as adopted covers fixed telephony, mobile telephony, Internet access, Internet email and Internet telephony." http://en.wikipedia.org/wiki/Telecommunications_data_retention#European_Unio...
Am 30.03.2011 18:22, schrieb Philipp Überbacher:
I doubt that: "The Directive as adopted covers fixed telephony, mobile telephony, Internet access, Internet email and Internet telephony." http://en.wikipedia.org/wiki/Telecommunications_data_retention#European_Unio...
It only covers connection data (IP addresses, phone numbers, email addresses), not content. Inspecting the content (for instance, doing a deep packet inspection on web traffic, listening in on phone conversations) is still illegal unless ordered by a judge. Besides, the laws implementing this regulation have been deemed unconstitutional in 4 or 5 countries already. There is still hope that the regulation will be dropped entirely. Back to topic: If I would find out that my provider inspects my web traffic and logs which websites I connect to, I would definitely sue.
I give up trying to understand this. Initially you were complaining about port 80 being open on your host, you gave us a list of open ports - not an nmap of another host. So now a transparent proxy is the concern? On Wed, 30 Mar 2011 15:45:18 +0530, Partha Chowdhury wrote:
nmap -sV 115.187.45.97
Starting Nmap 4.20 ( http://insecure.org ) at 2011-03-30 15:06 IST Interesting ports on 115.187.45.97: Not shown: 1696 filtered ports PORT STATE SERVICE VERSION 80/tcp open http? 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
SF-Port80-TCP:V=4.20%I=7%D=3/30%Time=4D92F9D0%P=i686-pc-linux-gnu%r(Help,D
Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ . Nmap finished: 1 IP address (1 host up) scanned in 114.226 seconds
So it seems my ISP is running squid version 3.2.0.4-20110203 in transparent mode , just like you said.
Interestingly when connecting to random ip addresses on port 80, the error page returned is quite different from normal ones.
http://www.freeimagehosting.net/image.php?280f0ef980.png
Does this transparent proxy pose any threat and what can I do to stop that ?
-- Simon Perry (aka Pezz) [ s a n x i o n . n e t ]
Am 30.03.2011 12:15, schrieb Partha Chowdhury:
Well I picked this configuration from Red Hat training books, except for port 54215 which I open for bit torrent.
What do you suggest about the ideal iptables configuration for basic desktop user -
This comes with our iptables package: $ cat /etc/iptables/simple_firewall.rules *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -p icmp -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -j REJECT --reject-with icmp-proto-unreachable COMMIT I use this as a basis for every packet filter I create manually (but then, I originally wrote this file). Just add your open ports as you did before. This has the advantage that 1) ICMP is allowed. ICMP can do essential things such as path MTU discovery. Blocking all ICMP packets might lead to various bizzare connection failures (in the past, many of these failures where because large corporate networks had stupid admins that blocked ICMP entirely). 2) You properly block incoming connections. When someone tries to connect to a port that is not allowed, the connection will simply be rejected, the client does not have to wait for a timeout. Most home routers use DROP rules here, which can be very annoying. One example: You want to ssh home, but got the wrong IP (dyndns not updated yet, whatever). Instead of just seeing a message that the connection has been closed, you have to wait between 1 and 2 minutes until you get a timeout. Another one: When you connect to freenode, the server tries to get your ident information. If you drop connections, the server will stall at that point, waiting for a timeout. If you reject properly, it will immediately proceed without having to wait. These might seem like minor annoyances, but on a large scale (hundreds of thousands of machines behaving incorrectly), this might have worse consequences.
allowing proper connection as you said and yet stay secure from malicious port scanners ?
What is a "malicious port scanner" and how can you stay "secure" from it?
On 30/03/11 16:25, Thomas Bächler wrote:
This comes with our iptables package:
$ cat /etc/iptables/simple_firewall.rules *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -p icmp -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -j REJECT --reject-with icmp-proto-unreachable COMMIT
According to the source from where i got the iptables configuration , the approach is "Block all incoming connections except for established connections, then open only specific ports which you want outside world to connect to".About blocking icmp ping, i quote one website as-is:
Your system REPLIED to our Ping (ICMP Echo) requests, making it visible on the Internet. Most personal firewalls can be configured to block, drop, and ignore such ping requests in order to better hide systems from hackers. This is highly recommended since "Ping" is among the oldest and most common methods used to locate systems prior to further exploitation is what they say is true ?
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
isn't this seem redundant ? I mean icmp is allowed, then except for established and related connections, a tcp rst packet is sent for all unwanted tcp traffic and icmp-port-unreachable message is sent for every unwanted udp packets, right ? Then what packets that rule match ?
What is a "malicious port scanner" and how can you stay "secure" from it?
I meant to avoid random packets coming from random machines at random times: for example: one random packet from sys.log
IN=eth0 OUT= MAC=20:cf:30:5a:ea:aa:00:00:cd:27:e5:03:08:00 SRC=182.177.140.45 DST=172.16.37.164 LEN=48 TOS=0x00 PREC=0x00 TTL=103 ID=32623 DF PROTO=TCP SPT=17511 DPT=39384 WINDOW=8192 RES=0x00 SYN URGP=0
On 30/03/11 16:40, Richard Schütz wrote:
The output of "ip addr show" would be interesting.
here is the output:
ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 20:cf:30:5a:ea:aa brd ff:ff:ff:ff:ff:ff inet 172.16.37.164/26 brd 172.16.37.191 scope global eth0 3: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
On 30/03/11 16:44, Simon Perry wrote:
So your machine is 172.16.37.164, which you have to configure and tell your ISP because they NAT externally from 115.187.45.97 to many internal 172.16.37.* users?
Therefore more than one person could have an external address of 115.187.45.97 mapping back to their 172.16.37.* IP?
Even though only one person could have 115.187.45.97:80 mapped back to them?
Are you sure about how this works?
With my previous dsl provider , an address in the range 59.93.x.x was assigned to ppp0 interface by authenticating with rp-pppoe software.But now i have to provide the private ip to eth0, authenticate and then visit any website to know my public ip.
On 30/03/11 16:40, Richard Schütz wrote:
The output of "ip addr show" would be interesting.
here is the output:
ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 20:cf:30:5a:ea:aa brd ff:ff:ff:ff:ff:ff inet 172.16.37.164/26 brd 172.16.37.191 scope global eth0 3: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
Either 172.16.37.164 is mapped 1:1 to a public IP address or you are behind a NAT. Looks very crappy in my eyes. -- Regards, Richard Schütz
Am 30.03.2011 15:00, schrieb Partha Chowdhury:
According to the source from where i got the iptables configuration , the approach is "Block all incoming connections except for established connections, then open only specific ports which you want outside world to connect to".
Exactly my philosophy.
About blocking icmp ping, i quote one website as-is:
Your system REPLIED to our Ping (ICMP Echo) requests, making it visible on the Internet. Most personal firewalls can be configured to block, drop, and ignore such ping requests in order to better hide systems from hackers. This is highly recommended since "Ping" is among the oldest and most common methods used to locate systems prior to further exploitation is what they say is true ?
You cannot "hide" yourself on the internet. If you were offline, the next router would reply that your machine is unreachable. By not answering, you not only tell the "attacker" that you are online, you also tell him that you don't know shit about networking. Google it.
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
isn't this seem redundant ? I mean icmp is allowed, then except for established and related connections, a tcp rst packet is sent for all unwanted tcp traffic and icmp-port-unreachable message is sent for every unwanted udp packets, right ? Then what packets that rule match ?
This properly rejects packets to your IP that are neither ICMP nor TCP nor UDP.
What is a "malicious port scanner" and how can you stay "secure" from it?
I meant to avoid random packets coming from random machines at random times:
for example: one random packet from sys.log
IN=eth0 OUT= MAC=20:cf:30:5a:ea:aa:00:00:cd:27:e5:03:08:00 SRC=182.177.140.45 DST=172.16.37.164 LEN=48 TOS=0x00 PREC=0x00 TTL=103 ID=32623 DF PROTO=TCP SPT=17511 DPT=39384 WINDOW=8192 RES=0x00 SYN URGP=0
And how does that harm you? It is rejected, and the sender now knows that he is sending to the wrong destination (instead of continuously retrying, which he would probably if you DROPped it).
On 30/03/11 19:38, Thomas Bächler wrote:
You cannot "hide" yourself on the internet. If you were offline, the next router would reply that your machine is unreachable. By not answering, you not only tell the "attacker" that you are online, you also tell him that you don't know shit about networking.
Google it.
Thank you for clearing that up :-) I always believed that remaining stealth, my machine was hidden on the internet from prying eyes. I was so mistaken !:-[
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
This properly rejects packets to your IP that are neither ICMP nor TCP nor UDP.
Sorry I confused packets with protocols. It basically tells that no http,pop3,ftp or imap services is running on my machine and politely closes the connection instead silently dropping the connection, right ?
And how does that harm you? It is rejected, and the sender now knows that he is sending to the wrong destination (instead of continuously retrying, which he would probably if you DROPped it).
It seems you were right. With my previous iptables configuration, i was getting thousands of unwanted packets from same sources multiple times. After using your configuration, there is a very sharp decrease of unwanted packets.
nmap -sV 115.187.45.97
Are you sure that this IP is really your public one? The static IP which you do assign to your eth0 interface is from a private netblock. It looks like you create a tunnel on top of that connection with this strange Cyberoam client software. The output of "ip addr show" would be interesting. -- Regards, Richard Schütz
participants (6)
-
Jan de Groot
-
Partha Chowdhury
-
Philipp Überbacher
-
Richard Schütz
-
Simon Perry
-
Thomas Bächler