[arch-general] Port 80 is shown open in port scan without any web server running

[Thomas Bächler]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20110330/9d5b2db7/attachment.asc>