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] [thread-next>] [day] [month] [year] [list]

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

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.

-- 
Rémi Denis-Courmont
--
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