|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: New form of packet attack named Stream
> > 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/
|