Re: Port 80 Open

On 2007-10-27 Telly Williams wrote:
> -A INPUT -p tcp -j bad_tcp
> -A INPUT -p tcp -f -j Fragment
> -A INPUT -p tcp -m iprange --src-range 10.0.0.0-10.255.255.255 -j Spoofs
> -A INPUT -p tcp -m iprange --src-range 172.16.0.0-172.31.255.255 -j Spoofs
> -A INPUT -p tcp -m iprange --src-range 192.168.0.0-192.168.255.255 -j Spoofs
> -A INPUT -p tcp -m iprange --src-range 169.254.0.0-169.254.255.255 -j Spoofs

You don't need the iprange module for this, but you most definitely want
these rules to apply to *all* IP packets, not just to TCP.

iptables -A INPUT -s 10.0.0.0/8 -j Spoofs
iptables -A INPUT -s 172.16.0.0/12 -j Spoofs
iptables -A INPUT -s 192.168.0.0/16 -j Spoofs
iptables -A INPUT -s 169.254.0.0/16 -j Spoofs

Depending on your infrastructure you may also want to specify the input
interface here.

> -A INPUT -s 127.0.0.1 -i lo -j ACCEPT
> -A INPUT -s XX.XXX.XXX.XXX -i lo -j ACCEPT

No other source address than 127.0.0.1/8 is supposed to appear at the
loopback interface.

iptables -A INPUT -i lo -s 127.0.0.1/8 -j ACCEPT

[...]
> -A INPUT -d XX.XXX.XXX.XXX -m state --state RELATED,ESTABLISHED -j ACCEPT

It's rather pointless to discriminate this rule by destination IP,
because it's traffic that belongs to an already established connection
(i.e. you already accepted traffic for this). Also you should allow
ESTABLISHED,RELATED traffic in the other chains as well:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

You can omit the last one if you're not forwarding packets.

> -A INPUT -i eth1 -p tcp -j tcp_packets
> -A INPUT -i eth1 -p udp -j udp_packets
> -A INPUT -i eth1 -p icmp -j icmp_packets

Defining one chain per protocol and do all the packet handling there may
work for ICMP, but for TCP and UDP it's probably not the best of ideas,
because with these protocols a packet in the INPUT chain usually needs
other rules than a packet in the OUTPUT (or FORWARD) chain.

> -A INPUT -p tcp -m multiport --sports ! 8002 -m limit --limit 6/min --limit-burst 6 -j LOG --log-prefix "INPUT pkt dead: " --log-level 7

Since you specified only one port you don't need the multiport module
here.

[...]
> -A OUTPUT -s XX.XX.XXX.XXX -j ACCEPT

Why are you ACCEPTing traffic based on the source address? For new
outbound connections you should ACCEPT based on destination and state
NEW, for everything else, you should use an ESTABLISHED,RELATED rule
just like you do in the INPUT chain.

[...]
> -A icmp_packets -p icmp -m icmp --icmp-type 8 -j DROP
> -A icmp_packets -p icmp -m icmp --icmp-type 11 -j DROP
> # With the above two rules, I thought it put me in stealth
> # mode(?).

Repeating myself: "stealth" is braindead marketing babble invented by
people who failed to understand TCP/IP for people who fail to understand
TCP/IP. Your host doesn't magically become "invisible" just because it
drops packets. TCP/IP doesn't work that way.

Besides, you shouldn't be dropping echo-request and time-exceeded. ICMP
is a vital part of IP and required e.g. for troubleshooting connection
problems. Rather do something like this:

iptables -N icmp_packets
# Allow ping, but limit it to 10 requests per second:
iptables -A icmp_packets -p icmp --icmp-type echo-request \
-m state --state NEW -m limit --limit 10/sec -j ACCEPT
# Allow echo replies (pong) for accepted pings:
iptables -A icmp_packets -p icmp --icmp-type echo-reply \
-m state --state ESTABLISHED -j ACCEPT
# Allow troubleshooting messages for all established connections:
iptables -A icmp_packets -p icmp --icmp-type destination-unreachable \
-m state --state RELATED -j ACCEPT
iptables -A icmp_packets -p icmp --icmp-type source-quench \
-m state --state RELATED -j ACCEPT
iptables -A icmp_packets -p icmp --icmp-type time-exceeded \
-m state --state RELATED -j ACCEPT
iptables -A icmp_packets -p icmp --icmp-type parameter-problem \
-m state --state RELATED -j ACCEPT
iptables -A icmp_packets -j DROP

I'd also recommend to REJECT packets rather than simply DROP them, so I
usually define a DENY chain and put it at the end of the INPUT, OUTPUT
and FORWARD chains:

iptables -N DENY
iptables -A DENY -p tcp -m limit --limit 10/sec -j REJECT \
--reject-with tcp-reset
iptables -A DENY -p udp -m limit --limit 10/sec -j REJECT \
--reject-with icmp-port-unreachable
iptables -A DENY -j DROP

> -A tcp_packets -p tcp -m tcp --dport 80 -j allowed
> -A tcp_packets -p tcp -m tcp --dport 443 -m comment --comment "HTTPS" -j allowed
> -A tcp_packets -p tcp -m tcp --dport 25 -j allowed
> -A tcp_packets -p tcp -m tcp --sport 123 -m comment --comment "NTP" -j allowed

Why are you ACCEPTing NTP packets based on the source port? Unlike not
being "stealth" this can be an actual security breach in your firewall.
ACCEPT NEW NTP connections in the appropriate chain (depending on
whether you want to allow inbound or outbound NTP), the rest is covered
by your ESTABLISHED,RELATED rules.

[...]
> -A udp_packets -i eth1 -p udp -m udp --sport 67:68 --dport 67:68 -m comment --comment "DHCP Purposes" -j ACCEPT
[...]
> -A udp_packets -p udp -m udp --sport 123 -m comment --comment "NTP" -j ACCEPT

Same with these.

Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org