netdev - Re: bug in tcp?

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:	Mon, 16 Apr 2007 23:35:23 -0600
From:	Sebastian Kuzminsky <seb@...hlab.com>
To:	Philip Craig <philipc@...pgear.com>
cc:	netdev@...r.kernel.org, Sebastian Kuzminsky <seb@...hlab.com>
Subject: Re: bug in tcp? 

Philip Craig <philipc@...pgear.com> wrote:
> It sounds like it could easily be iptables related, if you have iptables
> rules that only allow new connections in the client to server direction,
> which is quite normal.

Sure I have those standard rules.

iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --syn --dport ssh -j ACCEPT
iptables -A INPUT -p tcp --syn --dport http -j ACCEPT
... etc

> The default iptables timeout for TCP connections is 5 days.
> So after 5 days of idle, any packets from the server will be treated
> as a new connection and the iptables rules will drop them.

Weird.  Why does sending a message from the client make it go again?

If that's the case, it seems like a simple fix would be to enable TCP
keepalive in my app, that would keep netfilter from timing out, right?
That seems better than extending the netfilter timeout.

How do people normally handle this?

-- 
Sebastian Kuzminsky
-
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