Re: New form of packet attack named Stream
Jamie Rishaw <jamie@dilbert.exodus.net> wrote:
Unless you are Vixie Hubbard Cerf Donelan Manning Bush Jesus Christ
(Randy, you _do_ look like a biblical personage :)
A major s/w key figure or comparable entity
.. or someone that knows me IRL, and has for some time .. please do not e-mail me asking for the code.
Actually, you provided enough details, so any unix guy who knows his sockets can write the program in fifteen minutes. This type of attack was known for a long time (and there are even nastier variations using TCP header bits and fragments), and, unfortunately, there's no good defense against it. The core routers are indeed vulnerable; is there any router which has an access list for restricting packet flow to the routing processor? (My knowledge of latest-and-greatest features from OFRV is somewhat outdated). A toyed with the idea of reverse-path verification coupled with some kind of super-squelch message; but so far all such schemes have holes in them. DoS attacks are a real scourge. --vadim
Actually, you provided enough details, so any unix guy who knows his sockets can write the program in fifteen minutes.
then why have six people written to me asking me to ask jamie for it? </rhetorical>
because... <rant> a lot of people are stupid lazy f*cks, they're 5kr1pt k1dd33z, or they're 4$$h0135. consequently they think they can just ask you ask for it, and then you'll forward it back to them because you're a "nice guy". which you probably are, but you're also no dummy. for most of these people, they just want more things they can use to annoy other people. they know next to nothing, don't seem to want to, and probably couldn't learn anything if their life depended on it. they're also probably 12, and use aol. </rant> thank you. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
e-mail me asking for the code.
Actually, you provided enough details, so any unix guy who knows his sockets can write the program in fifteen minutes.
This type of attack was known for a long time (and there are even nastier variations using TCP header bits and fragments), and, unfortunately, there's no good defense against it. There is one base rule - you (OS) MUST limit resources (CPU, MEMORY, buffers, sockets, etc) catched by any SINGLE origin (IP address, program, service).
Such approach broke just any except a few DoS attacks - for example, if you try to exhaust memory attaking single service, then (1) service can't catch all memory because it's the SINGLE origin, and (2) one SRC address can't catch many resources because it's SINGLE origin, and (3) you can't generate too many different addresses in case of reverse-filtering.
The core routers areindeed vulnerable; is there any router which > has an access list for restricting packet flow to the routing processor? (My knowledge of latest-and-greatest features from OFRV is somewhat outdated).
A toyed with the idea of reverse-path verification coupled with some kind of super-squelch message; but so far all such schemes have holes in them. DoS attacks are a real scourge.
--vadim
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
Alex P. Rudnev has declared that:
e-mail me asking for the code.
Actually, you provided enough details, so any unix guy who knows his sockets can write the program in fifteen minutes.
This type of attack was known for a long time (and there are even nastier variations using TCP header bits and fragments), and, unfortunately, there's no good defense against it. There is one base rule - you (OS) MUST limit resources (CPU, MEMORY, buffers, sockets, etc) catched by any SINGLE origin (IP address, program, service).
Such approach broke just any except a few DoS attacks - for example, if you try to exhaust memory attaking single service, then (1) service can't catch all memory because it's the SINGLE origin, and (2) one SRC address can't catch many resources because it's SINGLE origin, and (3) you can't generate too many different addresses in case of reverse-filtering.
Any ideas/suggestions to hacks to kernel, etc (i.e., freebsd, linux, etc) to impose such limits (configurable by admin, preferably)? Especially in the CPU usage and memory areas (perhaps sockets/handles, too). One can limit handles, memory, etc for a given user process, but I havent seen any such ability that would affect the TCP stack directly (the load of many of these attacks does not launch or run user-mode code - just eats up all the CPU and/or memory). This idea sounds like one of the potentially more viable approaches. While this would not solve issues of saturating upstream links that cant handle volume, it WOULD help a lot to enable targeted machines/servers to weather an attack. Routers - thats something the vendors should think about looking into. Pat M/HW
The core routers areindeed vulnerable; is there any router which > has an access list for restricting packet flow to the routing processor? (My knowledge of latest-and-greatest features from OFRV is somewhat outdated).
A toyed with the idea of reverse-path verification coupled with some kind of super-squelch message; but so far all such schemes have holes in them. DoS attacks are a real scourge.
--vadim
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
-- #include <std.disclaimer.h> Pat Myrto (pat at rwing dot ORG) Seattle WA How government differs from every other agency in society: The others persuade; government compels. Government is the only entity where the use of force - including deadly force - to achieve an end is OK. This is why govt pushes so hard for a monopoly on the means of coercive force.
On Fri, Jan 21, 2000 at 11:27:14AM -0800, Pat Myrto wrote:
Alex P. Rudnev has declared that:
e-mail me asking for the code.
Actually, you provided enough details, so any unix guy who knows his sockets can write the program in fifteen minutes.
This type of attack was known for a long time (and there are even nastier variations using TCP header bits and fragments), and, unfortunately, there's no good defense against it. There is one base rule - you (OS) MUST limit resources (CPU, MEMORY, buffers, sockets, etc) catched by any SINGLE origin (IP address, program, service).
Such approach broke just any except a few DoS attacks - for example, if you try to exhaust memory attaking single service, then (1) service can't catch all memory because it's the SINGLE origin, and (2) one SRC address can't catch many resources because it's SINGLE origin, and (3) you can't generate too many different addresses in case of reverse-filtering.
Any ideas/suggestions to hacks to kernel, etc (i.e., freebsd, linux, etc) to impose such limits (configurable by admin, preferably)? Especially in the CPU usage and memory areas (perhaps sockets/handles, too).
One can limit handles, memory, etc for a given user process, but I havent seen any such ability that would affect the TCP stack directly (the load of many of these attacks does not launch or run user-mode code - just eats up all the CPU and/or memory).
This idea sounds like one of the potentially more viable approaches. While this would not solve issues of saturating upstream links that cant handle volume, it WOULD help a lot to enable targeted machines/servers to weather an attack.
Routers - thats something the vendors should think about looking into.
The big loss in systems is sending out all those RSTs, the pcb hash lookups are secondary. Put a rate limit on the number of dropwithreset's you will even queue over a certain amount of time, else just straight drop. This applies to any kind of system generated "response" packet which can be stimulated to happen in large amounts, such as icmp errors. One of the more annoying things is dealing with all the paranoid people with their first firewall program and the urge to complain that the world is ending if they receive a single packet that looks out of place (especially if they contact your service provider and make false accusations or if you are the service provider and untrained in recognizing false accusations out of ignorance). I am continuingly supprised by how often this happens. The same can be said for allocating PCBs on syns in the first place. Much of this becomes a game to seperate the bad packets from the good. Routers face sheer packets/sec to deal with, underpowered ones always have and always will fail when forced to use CPU, nothing new about this. Some ASICs which work on establishing flows w/CPU and then doing high speed switching can fail miserably if the ability to program flows quickly hasn't been designed properly. A certain vendor's switching routers comes to mind. Just to point out the obvious about this one, the ack bit is set but the ack field is always 0, a condition which should really only occur when the ack field rolls over 32 bits. Food for thought. Many people seem to have problems understanding these concepts for some as-yet unknown reason. I'm not sure if this is fortunant or not, as it seems to apply to vendors and developers as well as packet kiddies. Nothing at all is "new" here, there is nothing "magical" about any of this stuff, and people who waste their time believing so are destined for problems. Personally I would be happy never to hear the name "stream.c" again. -- Richard A. Steenbergen <ras@above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) AboveNet Communications - AboveSecure Network Security Engineer, Vienna VA "A mind is like a parachute, it works best when open." -- Unknown
Pat Myrto wrote:
Alex P. Rudnev has declared that:
e-mail me asking for the code.
Actually, you provided enough details, so any unix guy who knows his sockets can write the program in fifteen minutes.
This type of attack was known for a long time (and there are even nastier variations using TCP header bits and fragments), and, unfortunately, there's no good defense against it. There is one base rule - you (OS) MUST limit resources (CPU, MEMORY, buffers, sockets, etc) catched by any SINGLE origin (IP address, program, service).
Such approach broke just any except a few DoS attacks - for example, if you try to exhaust memory attaking single service, then (1) service can't catch all memory because it's the SINGLE origin, and (2) one SRC address can't catch many resources because it's SINGLE origin, and (3) you can't generate too many different addresses in case of reverse-filtering.
Any ideas/suggestions to hacks to kernel, etc (i.e., freebsd, linux, etc) to impose such limits (configurable by admin, preferably)? Especially in the CPU usage and memory areas (perhaps sockets/handles, too).
from freebsd-current yesterday: Subject: half-fix for stream.c http://www.freebsd.org/~alfred/tcp_fix.diff damon
There is one base rule - you (OS) MUST limit resources (CPU, MEMORY, buffers, sockets, etc) catched by any SINGLE origin (IP address, program, service).
Such approach broke just any except a few DoS attacks - for example, if you try to exhaust memory attaking single service, then (1) service can't catch all memory because it's the SINGLE origin, and (2) one SRC address can't catch many resources because it's SINGLE origin, and (3) you can't generate too many different addresses in case of reverse-filtering.
Any ideas/suggestions to hacks to kernel, etc (i.e., freebsd, linux, etc) to impose such limits (configurable by admin, preferably)? Especially in the CPU usage and memory areas (perhaps sockets/handles, too). Hmm, you misunderstand.
Now a lot of places looks like: if ( p = getbuf(size) ) { ... } else { logmessage("Can't allocate buf\n"); return(-1);}; I'm talking about something like: set_owner(who_i_am); if ( p = getbuf.,....) This means - all resource should be associated with some owner or exactly the set of owners. Owner can be not only the process, but IP address, protocol, etc. And you can restrict: TCP stack - 80% resources UDP stack - 50% resources process - 40% resources user - 55% resources socket - 20% resources device ,... so that any type of attack or any broken program/system could not catch all resource and run the system out of the control. The simple example - CIsco router. It have IP memory and have memory. Today, if your BGP process run out of the memory, your OSPF process fail and your vty terminals refuse to work at all... On the other hand, I wich to restrict any single process to exhaust all system resources at once, because I prefer to keep system in control (and allow this single process to fail before all resources will be exhausted) to the existing behaviour. Of course, it's a simple schema, not more, and I am not talking I have said here completed idea; it was only an attempt to found some universal approach. Just as in case of the buffer overflow exploits - you can fight fight and fight, but you can simple (for example) use distinct stacks for the return-stack and fo the variables - and no any overflow can get control at all; or you can strictly restrict the rights of the process - and if hacker catch control fo the sendmail daemon, he never can run shell or open /etc directory (for example). Just here - you can search for the every new DoS hole, or can try to build stable system from the very begin. It's am,azing but (for example) multiprocessor systems are the kind of this approach. In the single processor system, if some process became crazy and run out of control, it can catch 100% CPU time and make the system useless; in the 4 processor Sequent system I have used a few years ago, we had such incidents once/day withouth any bad results because such process catched 1 processor only. Juts DoS attack - don't allow one single source of the influence (process, address , socket, protocol) to exhaust any single resource, and let's hackers waste time trying to run your system out of memory or CPU (of course, there is simple advice - don't run IRC in your system -:)).
One can limit handles, memory, etc for a given user process, but I havent seen any such ability that would affect the TCP stack directly (the load of many of these attacks does not launch or run user-mode code - just eats up all the CPU and/or memory).
This idea sounds like one of the potentially more viable approaches. While this would not solve issues of saturating upstream links that cant handle volume, it WOULD help a lot to enable targeted machines/servers to weather an attack.
Routers - thats something the vendors should think about looking into.
Pat M/HW
The core routers areindeed vulnerable; is there any router which > has an access list for restricting packet flow to the routing processor? (My knowledge of latest-and-greatest features from OFRV is somewhat outdated).
A toyed with the idea of reverse-path verification coupled with some kind of super-squelch message; but so far all such schemes have holes in them. DoS attacks are a real scourge.
--vadim
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
-- #include <std.disclaimer.h> Pat Myrto (pat at rwing dot ORG) Seattle WA How government differs from every other agency in society: The others persuade; government compels. Government is the only entity where the use of force - including deadly force - to achieve an end is OK. This is why govt pushes so hard for a monopoly on the means of coercive force.
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
participants (7)
-
Alex P. Rudnev -
Andrew Brown -
Damon M. Conway -
Pat Myrto -
Randy Bush -
Richard Steenbergen -
Vadim Antonov