RE: new tcp connections, without SYN

RE: new tcp connections, without SYN

[dhiraj.2.bhuyan]

I tried sending an "ACK" packet from behind my Netfilter firewall to a
machine on the public side that actually doesn't exist.

A look in the /proc/net/ip_conntrack tells me that Netfilter tracked this
connection as "ESTABLISHED" but "UNREPLIED". So Netfilter does infact allow
starting a TCP connection with an ACK packet.

dhiraj


-----Original Message-----
From: Martijn Klingens [mailto:mklingens@ism.nl]
Sent: 09 April 2003 14:59
To: netfilter@lists.netfilter.org
Subject: Re: new tcp connections, without SYN


On Wednesday 09 April 2003 15:06, Cedric Blancher wrote:
> Timers for Netfilter's conntrack should be the same as TCP stacks. So,
> if conntrack times out, then destination TCP stack should time out too.
> that means if a ACK gets so delayed that related conntrack entry gets
> dropped, than it would be also dropped by destination TCP stack.

Aaah... that might explain my problem with 'new, not syn'.

Problem is that our firewall is a non-masquerading router for a class C
subnet 
and that we don't have the ability to set the timeouts on all machines
behind 
it.

Isn't there a workaround to avoid this problem on the netfilter machine?

-- 
Martijn

RE: new tcp connections, without SYN

[Cedric Blancher]

Le mer 09/04/2003 à 18:04, dhiraj.2.bhuyan@bt.com a écrit :
> I tried sending an "ACK" packet from behind my Netfilter firewall to a
> machine on the public side that actually doesn't exist.
> A look in the /proc/net/ip_conntrack tells me that Netfilter tracked this
> connection as "ESTABLISHED" but "UNREPLIED". So Netfilter does infact allow
> starting a TCP connection with an ACK packet.

Yes it does, unless you apply tcp-nopickup patch that enforces NEW and
RELATED TCP packets must be SYN ones, flaging others as INVALID.

This behaviour allows one to handle connections for which firewall have
not seen SYN packet, such as asymetrical routing, failover, reboot and
stuff.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: new tcp connections, without SYN

[Rahul Jadhav]

I have been following your messages for a  while now and I tried the '! 
--syn' and '--state NEW, RELATED' rule without much success. I am trying 
to completely block the nmap -P0 and -PS probes.
Now I know I might need to recompile iptables with tcp-nopickup patch. 
Can you please elaborate more on what it does.
And, also someone please write back rules to block port scans (do I HAVE 
to block ICMP completely for that?).

Rahul

Cedric Blancher wrote:

>Le mer 09/04/2003 à 18:04, dhiraj.2.bhuyan@bt.com a écrit :
>  
>
>>I tried sending an "ACK" packet from behind my Netfilter firewall to a
>>machine on the public side that actually doesn't exist.
>>A look in the /proc/net/ip_conntrack tells me that Netfilter tracked this
>>connection as "ESTABLISHED" but "UNREPLIED". So Netfilter does infact allow
>>starting a TCP connection with an ACK packet.
>>    
>>
>
>Yes it does, unless you apply tcp-nopickup patch that enforces NEW and
>RELATED TCP packets must be SYN ones, flaging others as INVALID.
>
>This behaviour allows one to handle connections for which firewall have
>not seen SYN packet, such as asymetrical routing, failover, reboot and
>stuff.
>
>  
>
-- 
         __  __     __   __	
        /_/ /_ \  _/ /  /  \	Institute for Agriculture
       __  __/ / \  _/ / / /	and Trade Policy
      / / /   /  / /  / __/	2105 First Ave S
     / / / / /  / /_ / /	Minneapolis MN 55404
     \/  \__/   \__/ \/		http://www.iatp.org

       I N F O R M A T I O N   T E C H N O L O G Y

The best things in life are done by people with nowhere to turn.
                                -The Blind Assassin (Margaret Atwood)

Re: new tcp connections, without SYN

[Cedric Blancher]

Le jeu 10/04/2003 à 19:53, Rahul Jadhav a écrit :
> I have been following your messages for a  while now and I tried the '! 
> --syn' and '--state NEW, RELATED' rule without much success. I am trying 
> to completely block the nmap -P0 and -PS probes.

man nmap :
[...]
       -P0    Do not try and ping hosts at all before scanning
	      them. This allows the scanning of networks that don't
	      allow ICMP echo requests (or responses) through their
	      firewall. microsoft.com is an example of such a network,
	      and thus you should always use -P0 or -PT80 when
	      portscanning microsoft.com.
[...]
       -PS    This option uses SYN (connection request) packets instead
	      of ACK packets for root users.  Hosts that are up should
	      respond with a RST (or, rarely, a SYN|ACK). You can set
	      the destination ports in the same manner as -PT above.
[...]

-PT is a TCP scan using ACK.

So, there's nothing to do to avoid a scan using -P0 for it does not
probe before scanning. You have to concentrate on detecting the scan
itself, using POM psd match or any userland tool that achieve this, and
then block it before its end.

It is about the same for -PS. You are able to block -PT scans blocking
NEW TCP packets that would not be SYN ones, but as -PS uses a SYN
packet, it uses a valid packet that is to be answered. So, if you're
probed against an opened port, you can't do anything, and as for -P0,
you have to concentrate on port scan itself.

Imho, port scanning blocking is a very tough feature to implement, as
there is a lot scanning technics, with various parameters such as
timing, multiple sources usage, decoys, etc. I prefer concentrate on a
good filtering ruleset, and let others scan. They will discover what
services they're allowed to access ;)

> And, also someone please write back rules to block port scans (do I HAVE 
> to block ICMP completely for that?).

Netfilter's conntrack achieves ICMP errors handling very well.. When an
ICMP error is recieved, it is labeled RELATED if conntrack can associate
it to an existing IP flow. If not, it's RELATED. So, you can safely drop
all ICMPs that are not RELATED (INVALID packets should be droped
anyway).

ICMP echos, timestamp, netmask and info are treated with NEW/ESTABLISH
states, as they implies requests and responses. It is harmless to drop
them all.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

RE: new tcp connections, without SYN

[dhiraj.2.bhuyan]

As far as I understand, an "ACK" packet can also start a "NEW" connection.
If the connection remains idle for long, the Netfilter's connection tracking
engine times out that connection and removes it's entry from the state
table. Now when an "ACK" packet comes back after sometime, the connection
tracking engine marks this as a "NEW" connection. However am not sure how
the state changes to "ESTABLISHED".

dhiraj

-----Original Message-----
From: Cedric Blancher [mailto:blancher@cartel-securite.fr]
Sent: 09 April 2003 11:33
To: carlosble@terra.es
Cc: netfilter@lists.netfilter.org
Subject: Re: new tcp connections, without SYN


Le mer 09/04/2003 à 13:16, Carlos Ble a écrit :
> Hi all. Two days ago, i added the policy that drops all new tcp
connections
> that starts without SYN to prevent port scaners and other attacks:
> iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
> --log-prefix "NEW tcp try no SYN:"
> iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

You can add RELATED state to this :

	iptables -A bad_tcp_packets -p tcp ! --syn -m state \
		--state NEW,RELATED -j DROP

> Another question: I had disabled the icmp answers :
> echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
> echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
> to try to be "invisible" for some wicked programs .
> will i have problems with some other programas that makes ping 
> before establish a connection? 

If a program waits for a ping reply before attempting connection, sure
you'll have problems. You can mitigeate this issue dealing echo requests
with your ruleset, and so having some addresses that still can ping.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

RE: new tcp connections, without SYN

[Cedric Blancher]

Le mer 09/04/2003 à 15:00, dhiraj.2.bhuyan@bt.com a écrit :
> As far as I understand, an "ACK" packet can also start a "NEW" connection.
> If the connection remains idle for long, the Netfilter's connection tracking
> engine times out that connection and removes it's entry from the state
> table. Now when an "ACK" packet comes back after sometime, the connection
> tracking engine marks this as a "NEW" connection. However am not sure how
> the state changes to "ESTABLISHED".

Timers for Netfilter's conntrack should be the same as TCP stacks. So,
if conntrack times out, then destination TCP stack should time out too.
that means if a ACK gets so delayed that related conntrack entry gets
dropped, than it would be also dropped by destination TCP stack.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: new tcp connections, without SYN

[Martijn Klingens]

On Wednesday 09 April 2003 15:06, Cedric Blancher wrote:
> Timers for Netfilter's conntrack should be the same as TCP stacks. So,
> if conntrack times out, then destination TCP stack should time out too.
> that means if a ACK gets so delayed that related conntrack entry gets
> dropped, than it would be also dropped by destination TCP stack.

Aaah... that might explain my problem with 'new, not syn'.

Problem is that our firewall is a non-masquerading router for a class C subnet 
and that we don't have the ability to set the timeouts on all machines behind 
it.

Isn't there a workaround to avoid this problem on the netfilter machine?

-- 
Martijn

RE: new tcp connections, without SYN

[Martin Josefsson]

On Wed, 2003-04-09 at 15:00, dhiraj.2.bhuyan@bt.com wrote:
> As far as I understand, an "ACK" packet can also start a "NEW" connection.
> If the connection remains idle for long, the Netfilter's connection tracking
> engine times out that connection and removes it's entry from the state
> table. Now when an "ACK" packet comes back after sometime, the connection
> tracking engine marks this as a "NEW" connection. However am not sure how
> the state changes to "ESTABLISHED".

IIRC there's been som discussion about how Internet Explorer violates
the tcp standard. Some versions start their tcp sessions with a ACK
instead of a SYN. And there's an hack in the windows OS that accepts
that if it's destined for an IIS webserver I think. This is to shorten
the amount of time needed for connection setup.

If connection-pickup is enabled they will be marked as NEW even though
they don't contain a SYN. If connection-pickup is disabled the packets
will be marked as INVALID.

-- 
/Martin

new tcp connections, without SYN

[Carlos Ble]

Hi all. Two days ago, i added the policy that drops all new tcp connections
that starts without SYN to prevent port scaners and other attacks:

iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
--log-prefix "NEW tcp try no SYN:"
iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

Now the system is registering this event every minute from diferents ip. 
Is this usual?. What kind of programs tries to start a new tcp connection 
without a SYN ?. 
Im no so worried because scaning the ports of my server from another computer 
in the internet, using nmap , the answer is that all ports al filtered. 

Another question: I had disabled the icmp answers :
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
to try to be "invisible" for some wicked programs .
will i have problems with some other programas that makes ping 
before establish a connection? 

Thanks in advance

Re: new tcp connections, without SYN

[Cedric Blancher]

Le mer 09/04/2003 à 13:16, Carlos Ble a écrit :
> Hi all. Two days ago, i added the policy that drops all new tcp connections
> that starts without SYN to prevent port scaners and other attacks:
> iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
> --log-prefix "NEW tcp try no SYN:"
> iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

You can add RELATED state to this :

	iptables -A bad_tcp_packets -p tcp ! --syn -m state \
		--state NEW,RELATED -j DROP

> Another question: I had disabled the icmp answers :
> echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
> echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
> to try to be "invisible" for some wicked programs .
> will i have problems with some other programas that makes ping 
> before establish a connection? 

If a program waits for a ping reply before attempting connection, sure
you'll have problems. You can mitigeate this issue dealing echo requests
with your ruleset, and so having some addresses that still can ping.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: new tcp connections, without SYN

[Martijn Klingens]

On Wednesday 09 April 2003 13:33, Cedric Blancher wrote:
> Le mer 09/04/2003 à 13:16, Carlos Ble a écrit :
> > Hi all. Two days ago, i added the policy that drops all new tcp
> > connections
> > that starts without SYN to prevent port scaners and other attacks:
> > iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
> > --log-prefix "NEW tcp try no SYN:"
> > iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
> 
> You can add RELATED state to this :
> 
> 	iptables -A bad_tcp_packets -p tcp ! --syn -m state \
> 		--state NEW,RELATED -j DROP

That doesn't necessarily help though.

Our firewall also has a 'new, not syn' filter and it gets hit a LOT. On 
average about 20% of all blocked packets. Another 20% are unexpected RSTs 
(i.e. RST that's cannot be mapped to a RELATED or ESTABLISHED connection.)

It has been like this for quite some months, and everything works as expected 
but we never found the cause of these new not syns and unexpected resets.

(Yes, related traffic _is_ properly accepted, so that can't be the case.)

-- 
Martijn

Re: new tcp connections, without SYN

[Cedric Blancher]

Le mer 09/04/2003 à 14:31, Martijn Klingens a écrit :
> > You can add RELATED state to this :
> > 	iptables -A bad_tcp_packets -p tcp ! --syn -m state \
> > 		--state NEW,RELATED -j DROP
> 
> That doesn't necessarily help though.

Well, this is not intended to reduce the amount of packets getting
blocked by this very rule. It was just to enforce the fast that a
RELATED TCP packet should be a SYN one.

> Our firewall also has a 'new, not syn' filter and it gets hit a LOT. On 
> average about 20% of all blocked packets. Another 20% are unexpected RSTs 
> (i.e. RST that's cannot be mapped to a RELATED or ESTABLISHED connection.)
> It has been like this for quite some months, and everything works as expected 
> but we never found the cause of these new not syns and unexpected resets.

On our plateform, our Netfilter boxes also block a large amount of such
packets. Most of them are destined to web servers we're hosting. My
analysis, mainly based on reverse OS fingerprinting, is that thoses
packets are mainly generated by IE, which is known to break some TCP
rules, beginning some connections with an ACK to speed things up, and
sometimes seems to reuse to quickly client ports (and thus generates SYN
packets with ESTABLISHED flag).


See Martin Josefsson's post within "new tcp connections, without SYN"
thread.


So, well, we just have to cope with this situation...


-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE