similar to: Re: FreeBSD Security AdvisoryFreeBSD-SA-04:04.tcp

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:04.tcp Security Advisory The FreeBSD Project Topic: many out-of-sequence TCP packets denial-of-service Category: core Module: kernel

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:04.tcp Security Advisory The FreeBSD Project Topic: many out-of-sequence TCP packets denial-of-service Category: core Module: kernel

Here's my proposed patch to change RST handling so that ESTABLISHED connections are subject to strict RST checking, but connections in other states are only subject to the "within the window" check. Part 2 of the patch is simply a patch to netstat so that it displays the statistic. As expected, it's very straightforward, the only real question is what to call the statistic...

This looks like a very cool feature addition to RELENG_7! Are there any performance penalties that you know of with this built in ? ---Mike At 09:13 PM 7/23/2008, Julian Elischer wrote: >julian 2008-07-24 01:13:22 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_7) > contrib/pf/pfctl parse.y > lib/libc/sys

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-05:08.kmem Security Advisory The FreeBSD Project Topic: Local kernel memory disclosure Category: core Module: sys Announced: 2005-05-06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-05:08.kmem Security Advisory The FreeBSD Project Topic: Local kernel memory disclosure Category: core Module: sys Announced: 2005-05-06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-05:15.tcp Security Advisory The FreeBSD Project Topic: TCP connection stall denial of service Category: core Module: inet Announced:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-05:15.tcp Security Advisory The FreeBSD Project Topic: TCP connection stall denial of service Category: core Module: inet Announced:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-EN-12:02.ipv6refcount Errata Notice The FreeBSD Project Topic: Reference count errors in IPv6 code Category: core Modules: sys_netinet sys_netinet6

-----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-00:52 Security Advisory FreeBSD, Inc. Topic: TCP uses weak initial sequence numbers Category: core Module: kernel Announced: 2000-10-06

Box with fresh RELENG_7 panic under heavy network load (more than 50k connections). This panics seems to be senfile(2) related, because when sendfile disabled in nginx, I can't reproduce the problem. Backtrace in all cases like this: # kgdb kernel /spool/crash/vmcore.1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General

Hi, I've encountered a strange problem while using FreeBSD 6.0 for our local mirror (mirror.math.uni-bielefeld.de) and thus is providing access via ftp, http, rsync and cvsup (all local and remote). The system crashes periodically with a kernel panic (panic: sbdrop). The uptimes between two crashes are going from a few hours to a few weeks. The system is a i386, Intel Pentium 4 based with

forgot this addr. -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene -----Oorspronkelijk bericht----- Van: Remko Lodder [mailto:remko@elvandar.org] Verzonden: vrijdag 23 januari 2004 10:53 Aan: Nick Twaddell Onderwerp: RE: [Freebsd-security] ipfw + named problem did you tcpdump the packets so that you can

Hello there. I tried make update using the following stable-supfile: *default base=/usr *default prefix=/usr *default release=cvs tag=RELENG_4 *default delete use-rel-suffix and my two nearest Russian CVS mirrors showed no changes in realpath. Heck, I downloaded the patch and said in /usr/src: # patch < realpath.patch so it was rejected. Then I looked into realpath.c's revision and

Hello security gurus, yesterday, I mistakenly posted a question on the questions list about this article : http://www.securityfocus.com/bid/13676/info/ which talks about a form of DOS vulnerability. I was curious as to the possibility of FreeBSD 5.x being affected, and if anyone was working on this or not. Ted Mittelstaedt posted this possible patch based upon the OpenBSD patch : in

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:06.ipv6 Security Advisory The FreeBSD Project Topic: setsockopt(2) IPv6 sockets input validation error Category: core Module: kernel

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:06.ipv6 Security Advisory The FreeBSD Project Topic: setsockopt(2) IPv6 sockets input validation error Category: core Module: kernel

Yeah but if you are uncertain about your own box my VERY STRONG advise is that you reinstall. IF your host is indeed owned, then you are a lot further away then just reinstalling, god knows what issues can arrise when a cracker exploits the system to do bogus tasks.. Then i say: Too bad for your time, sorry but it's like that -- Kind regards, Remko Lodder Elvandar.org/DSINet.org

Hi, I dont think you can deny all ddos against your box, you will need help from your isp. That is because if a person sends you enough packets, like 1mbit (and your line is 1mbit) full of packets, your connection is stuck, whether you filter or not. Though you can mitigate those by closing all non needed ports, log them if any attempt is being made to connect to them, and use a bogon list which

that only works when you are presuming that the host was not hacked already because i would clear those logs when i hacked a system :) but indeed it's a try, If you remain unsure, it is best to reinstall the system to be sure that a fresh and newly updated (yeah update it when installed :)) system is not compromised at that time.. loads of work, but it gives you some relief to know that