netdev - Re: [PATCH] add a sysctl to disable TCP simultaneous connection opening

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 10 Oct 2008 10:57:57 +0200
From:	Willy Tarreau <w@....eu>
To:	Rémi Denis-Courmont <rdenis@...phalempin.com>
Cc:	Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] add a sysctl to disable TCP simultaneous connection opening

On Fri, Oct 10, 2008 at 11:44:06AM +0300, Rémi Denis-Courmont wrote:
> On Friday 10 October 2008 11:10:22 ext Willy Tarreau, you wrote:
> > > Duh? If you require a SYN from the outside to the server, before you
> > > allow the server to send either SYN or SYN/ACK, I fail to see the
> > > problem.
> >
> > Requiring the firewall to expect a first SYN to come from the internet is
> > like doing no check at all.
> 
> On ports which are open to the outside you MUST allow inbound SYNs anyway. 
> >From a security perspective, it does not matter whether the server answers 
> with a SYN/ACK as normally or with a SYN-not-ACK as in "simultaneous open".
> 
> On ports which the server is using outbound only (if any), you can expect the 
> server to send a SYN out first. It again does not matter whether the other 
> end answers with a SYN/ACK or a SYN-not-ACK.
> 
> On other ports, a plain dumb stateless blackhole will do.
> 
> > When your server has been rooted, you can 
> > pretty much expect that your guest has no problem sending you a SYN.
> 
> And why would (s)he have problem sending a SYN/ACK? It makes no difference.

It's just that it would be useless. If sending a fake SYN from port 25 to your
server's port 443 allows it to establish connections from port 443 to port 25,
it becomes an easy spam platform. That's just an example. I'm just trying to
explain that supporting simultaneous connect on a firewall prevents you from
precisely controlling the direction of the streams.

Willy

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html