* UNWANTED state
@ 2004-12-29 23:42 Matteo Croce
2004-12-29 23:56 ` Phil Oester
0 siblings, 1 reply; 6+ messages in thread
From: Matteo Croce @ 2004-12-29 23:42 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]
Hi,
time ago i wanted to stealth may gateway, so i start dropping outgoing
icmp-port-unreachable packets, to avoid UDP scans.
But i had also a '--dport 113 -j REJECT' target to allow faster irc logins,
that stopped working since those ICMP were rejected by the new rule.
So i hacked the kernel with a patch i also attach, to prevent those packets
being generated.
I also start dropping outgoing RST/ACK to prevent TCP scans, but now i have a
question:
can an UNWANTED state be useful?
I mean, incoming packets which dstport is closed were classified as UNWANTED.
So were possible to drop UNWANTED packets, and a port will be open when some
service listens to it and filtered (not closed) when the service doesn't
listens.
A simple firewall is having a DROP default policy and open used ports.
But what happens when the service listening behind that port stop listenings?
The port remains not filtered, and send RST/ACK (or icmp-port-unreachable)
when someone tries to connect to it.
Regards, Matteo
--
.""`. Matteo Croce <3297627799@wind.it>
: :" : proud Debian admin and user
`. `"`
`- Debian - when you have better things to do than fix a system
--
.""`. Matteo Croce <rootkit85@yahoo.it>
: :" : proud Debian admin and user
`. `"`
`- Debian - when you have better things to do than fix a system
[-- Attachment #2: udp.diff --]
[-- Type: text/x-diff, Size: 956 bytes --]
diff -urN linux-2.6.10-vanilla/net/ipv4/udp.c linux-2.6.10/net/ipv4/udp.c
--- linux-2.6.10-vanilla/net/ipv4/udp.c 2004-12-26 17:17:09.000000000 +0100
+++ linux-2.6.10/net/ipv4/udp.c 2004-12-29 02:57:26.000000000 +0100
@@ -1165,7 +1165,7 @@
goto csum_error;
UDP_INC_STATS_BH(UDP_MIB_NOPORTS);
- icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
+// icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
/*
* Hmm. We got an UDP packet to a port to which we
diff -urN linux-2.6.10-vanilla/net/ipv6/udp.c linux-2.6.10/net/ipv6/udp.c
--- linux-2.6.10-vanilla/net/ipv6/udp.c 2004-12-26 17:17:10.000000000 +0100
+++ linux-2.6.10/net/ipv6/udp.c 2004-12-29 02:57:48.000000000 +0100
@@ -523,7 +523,7 @@
goto discard;
UDP6_INC_STATS_BH(UDP_MIB_NOPORTS);
- icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_PORT_UNREACH, 0, dev);
+// icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_PORT_UNREACH, 0, dev);
kfree_skb(skb);
return(0);
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: UNWANTED state
2004-12-29 23:42 UNWANTED state Matteo Croce
@ 2004-12-29 23:56 ` Phil Oester
2004-12-30 0:39 ` Matteo Croce
0 siblings, 1 reply; 6+ messages in thread
From: Phil Oester @ 2004-12-29 23:56 UTC (permalink / raw)
To: Matteo Croce; +Cc: netfilter-devel
On Thu, Dec 30, 2004 at 12:42:17AM +0100, Matteo Croce wrote:
> Hi,
> time ago i wanted to stealth may gateway, so i start dropping outgoing
> icmp-port-unreachable packets, to avoid UDP scans.
> But i had also a '--dport 113 -j REJECT' target to allow faster irc logins,
> that stopped working since those ICMP were rejected by the new rule.
> So i hacked the kernel with a patch i also attach, to prevent those packets
> being generated.
Perhaps you should consider using:
--dport 113 -j REJECT --reject-with tcp-reset
instead of hacking the kernel to disable icmp rejects?
As far as the rest of your message goes, I suppose it is a matter of personal
preference, but if you have a firewall open to the world for a particular
service, people on the outside will be able to find it if that service is
running. Why do you care if people get an icmp unreachable when the service
is down? You aren't making the box more secure IMO by not allowing the
icmp error outbound.
Anyhow...this discussion likely belongs over on the general netfilter list.
Phil
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: UNWANTED state
2004-12-29 23:56 ` Phil Oester
@ 2004-12-30 0:39 ` Matteo Croce
2004-12-31 5:56 ` Willy Tarreau
0 siblings, 1 reply; 6+ messages in thread
From: Matteo Croce @ 2004-12-30 0:39 UTC (permalink / raw)
To: netfilter-devel
> On Thu, Dec 30, 2004 at 12:42:17AM +0100, Matteo Croce wrote:
> Perhaps you should consider using:
>
> --dport 113 -j REJECT --reject-with tcp-reset
> instead of hacking the kernel to disable icmp rejects?
>
# iptables -I INPUT 1 -p tcp --dport 4567 -j REJECT --reject-with tcp-reset
# hping3 127.0.0.1 -p 4567 -S
HPING 127.0.0.1 (lo 127.0.0.1): S set, 40 headers + 0 data bytes
len=40 ip=127.0.0.1 ttl=255 DF id=0 sport=4567 flags=RA seq=0 win=0 rtt=0
--reject-with tcp-reset sends RST/ACK that are dropped by my firewall
> Why do you care if people get an icmp unreachable when
> the service is down? You aren't making the box more secure IMO by not
> allowing the icmp error outbound.
Tryng to reduce at minimum unneeded traffic is a sort of protection against
DOS.
Let's say i have a 4096/400 ADSL.
Someone with a ~512kbit upload can send me an large amount of data on a closed
port with something like 'hping3 <IP> -S -p <PORT> --flood', and my 400kbit
upload
will be unable to send 512Kbit of RST/ACKs.
If i drop unwanted data, the attacker needs an upload of ~4200Kbit
to dos my box, since he need to fill my download instead of my upload.
And having such a target will avoid open/close ports as needed, since only
used ports are available.
--
.""`. Matteo Croce <rootkit85@yahoo.it>
: :" : proud Debian admin and user
`. `"`
`- Debian - when you have better things to do than fix a system
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: UNWANTED state
2004-12-30 0:39 ` Matteo Croce
@ 2004-12-31 5:56 ` Willy Tarreau
2004-12-31 13:15 ` Matteo Croce
0 siblings, 1 reply; 6+ messages in thread
From: Willy Tarreau @ 2004-12-31 5:56 UTC (permalink / raw)
To: Matteo Croce; +Cc: netfilter-devel
On Thu, Dec 30, 2004 at 01:39:48AM +0100, Matteo Croce wrote:
> > On Thu, Dec 30, 2004 at 12:42:17AM +0100, Matteo Croce wrote:
> > Perhaps you should consider using:
> >
> > --dport 113 -j REJECT --reject-with tcp-reset
> > instead of hacking the kernel to disable icmp rejects?
> >
>
> # iptables -I INPUT 1 -p tcp --dport 4567 -j REJECT --reject-with tcp-reset
> # hping3 127.0.0.1 -p 4567 -S
> HPING 127.0.0.1 (lo 127.0.0.1): S set, 40 headers + 0 data bytes
> len=40 ip=127.0.0.1 ttl=255 DF id=0 sport=4567 flags=RA seq=0 win=0 rtt=0
>
>
> --reject-with tcp-reset sends RST/ACK that are dropped by my firewall
it seems to me that you forgot to add the following rule for the RST packet
to go out :
# iptables -I OUTPUT -m state --state ESTABLISHED -j ACCEPT
Regards,
willy
> > Why do you care if people get an icmp unreachable when
> > the service is down? You aren't making the box more secure IMO by not
> > allowing the icmp error outbound.
>
> Tryng to reduce at minimum unneeded traffic is a sort of protection against
> DOS.
Normally, you should be able to do most of this by checking for ESTABLISHED
and RELATED states. I don't know if there is a relation between your port 113
and the service you're using, but I believe that a cleaner solution would be
to add this relation to the conntrack helper associated to your particular
service.
In other terms, you would then do something like this :
-A INPUT -m state ESTABLISHED -j ACCEPT
-A INPUT -m state RELATED -p tcp --dport 113 -j REJECT --reject-with tcp-reset
-A INPUT -m state RELATED -j ACCEPT
... check for new connections here then final drop ...
-A INPUT -j DROP
A last solution would be the RECENT match. You create an entry when
establishing the outgoing session, and you match against it in return so that
only this address has the permission to receive a REJECT.
> Let's say i have a 4096/400 ADSL.
> Someone with a ~512kbit upload can send me an large amount of data on a closed
> port with something like 'hping3 <IP> -S -p <PORT> --flood', and my 400kbit
> upload
> will be unable to send 512Kbit of RST/ACKs.
You know, it's enough that you have *one* open port for an attacker to be able
to do this, be it SMTP, HTTP, SSH, or anything else...
Regards,
Willy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: UNWANTED state
2004-12-31 5:56 ` Willy Tarreau
@ 2004-12-31 13:15 ` Matteo Croce
0 siblings, 0 replies; 6+ messages in thread
From: Matteo Croce @ 2004-12-31 13:15 UTC (permalink / raw)
To: netfilter-devel
> In other terms, you would then do something like this :
>
> -A INPUT -m state ESTABLISHED -j ACCEPT
> -A INPUT -m state RELATED -p tcp --dport 113 -j REJECT --reject-with tcp-reset
> -A INPUT -m state RELATED -j ACCEPT
> ... check for new connections here then final drop ...
> -A INPUT -j DROP
>
> A last solution would be the RECENT match. You create an entry when
> establishing the outgoing session, and you match against it in return so that
> only this address has the permission to receive a REJECT.
here is my iptables -L output:
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID,UNTRACKED
DROP icmp -- anywhere anywhere icmp echo-request
REJECT tcp -- anywhere anywhere tcp dpt:auth reject-with icmp-port-unreachable
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/RST,ACK
Add the patch that doesn't respond on closed udp ports with an ICMP, and i have
the system sthealted with only 3 rules.
But I also know that the kernel patch and the rule that drops RST/ACKs are very ugly hacks.
Don't forget that this ugly hack works even for loopback!
> You know, it's enough that you have *one* open port for an attacker to be
> able to do this, be it SMTP, HTTP, SSH, or anything else...
Yes, but in most tipical end-user systems, open ports will be only:
20 for non PASV ftp transfers
some ports for IRC's DCC transfer
some ports for P2P apps
These ports are open only when needed, and (apart for p2p)
the program that opens them accepts only one connection.
So is almost impossible being DOSsed whit traffic on port 20 or so..
> Regards,
> Willy
Regards,
Matteo
--
.""`. Matteo Croce <rootkit85@yahoo.it>
: :" : proud Debian admin and user
`. `"`
`- Debian - when you have better things to do than fix a system
^ permalink raw reply [flat|nested] 6+ messages in thread
* UNWANTED state
@ 2004-12-29 22:58 Matteo Croce
0 siblings, 0 replies; 6+ messages in thread
From: Matteo Croce @ 2004-12-29 22:58 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]
Hi,
time ago i wanted to stealth may gateway, so i start dropping outgoing
icmp-port-unreachable packets, to avoid UDP scans.
But i had also a '--dport 113 -j REJECT' target to allow faster irc logins,
that stopped working since those ICMP were rejected by the new rule.
So i hacked the kernel with a patch i also attach, to prevent those packets
being generated.
I also start dropping outgoing RST/ACK to prevent TCP scans, but now i have a
question:
can an UNWANTED state be useful?
I mean, incoming packets which dstport is closed were classified as UNWANTED.
So were possible to drop UNWANTED packets, and a port will be open when some
service listens to it and filtered (not closed) when the service doesn't
listens.
A simple firewall is having a DROP default policy and open used ports.
But what happens when the service listening behind that port stop listenings?
The port remains not filtered, and send RST/ACK (or icmp-port-unreachable)
when someone tries to connect to it.
Regards, Matteo
--
.""`. Matteo Croce <3297627799@wind.it>
: :" : proud Debian admin and user
`. `"`
`- Debian - when you have better things to do than fix a system
[-- Attachment #2: udp.diff --]
[-- Type: text/x-diff, Size: 956 bytes --]
diff -urN linux-2.6.10-vanilla/net/ipv4/udp.c linux-2.6.10/net/ipv4/udp.c
--- linux-2.6.10-vanilla/net/ipv4/udp.c 2004-12-26 17:17:09.000000000 +0100
+++ linux-2.6.10/net/ipv4/udp.c 2004-12-29 02:57:26.000000000 +0100
@@ -1165,7 +1165,7 @@
goto csum_error;
UDP_INC_STATS_BH(UDP_MIB_NOPORTS);
- icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
+// icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
/*
* Hmm. We got an UDP packet to a port to which we
diff -urN linux-2.6.10-vanilla/net/ipv6/udp.c linux-2.6.10/net/ipv6/udp.c
--- linux-2.6.10-vanilla/net/ipv6/udp.c 2004-12-26 17:17:10.000000000 +0100
+++ linux-2.6.10/net/ipv6/udp.c 2004-12-29 02:57:48.000000000 +0100
@@ -523,7 +523,7 @@
goto discard;
UDP6_INC_STATS_BH(UDP_MIB_NOPORTS);
- icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_PORT_UNREACH, 0, dev);
+// icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_PORT_UNREACH, 0, dev);
kfree_skb(skb);
return(0);
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-12-31 13:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-12-29 23:42 UNWANTED state Matteo Croce
2004-12-29 23:56 ` Phil Oester
2004-12-30 0:39 ` Matteo Croce
2004-12-31 5:56 ` Willy Tarreau
2004-12-31 13:15 ` Matteo Croce
-- strict thread matches above, loose matches on Subject: below --
2004-12-29 22:58 Matteo Croce
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.