Date: Tue, 11 Jan 2000 11:46:43 -0800 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: Brad Knowles <blk@skynet.be>, Holtor <holtor@yahoo.com>, freebsd-questions@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Kernel Option: TCP_DROP_SYNFIN Message-ID: <200001111947.LAA55191@cwsys.cwsent.com> In-Reply-To: Your message of "11 Jan 2000 09:42:13 %2B0100." <xzpya9xq9sq.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <xzpya9xq9sq.fsf@flood.ping.uio.no>, Dag-Erling Smorgrav
writes:
> Brad Knowles <blk@skynet.be> writes:
> > At 12:18 PM -0800 2000/1/9, Holtor wrote:
> > > Would this help stop SYN floods from breaking my
> > > freebsd computer? if anyones tried it, please speak
> > > up with any results or how it works. Thanks!
> > I've used it and haven't seen it do any harm to the systems I was
> > using it on, although I can't speak for how well it might have helped
> > them survive a SYN flood. Unless you're using TTCP (TCP for
> > Transactions), you should probably be safe in enabling it.
>
> It doesn't have anything to do with syn floods at all. It merely
> prevents OS fingerprinting (at least the way nmap does it).
The following ipfw rule will also prevent OS fingerprinting.
deny log tcp from any to any in tcpflg fin,syn
Would this too have problems with TTCP? The reason I ask is that I've
been using this rule for a ever since 2.2.x (cannot remember the exact
date) and I haven't had any problems with TTCP enabled. I know I
should look at the RFC (and I will after lunch), but I'll ask anyway.
Does TTCP use packets with SYN/FIN set?
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca
ITSD
Province of BC
"e**(i*pi)+1=0"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001111947.LAA55191>