NODE 94dab28fRe: PANIX.COM down: denial of service attack
Duncan Frissell <frissell@panix.com>Fri, 13 Sep 1996 05:55:20 +0800
Here are the gory details from the first MOTD last Saturday:
The attacker is forging random source addresses on his
packets, so there is no way to find his/her location. There
is also no way to screen out those packets with a simple
router filter.
This is probably the most deadly type of denial-of-service
attack possible. There is no easy or quick way of dealing
with it. If it continues into Saturday we will start working
on kernel modifications to try to absorb the damage
(since there's absolutely no way to avoid it). This
however will not be an easy job and it could take days to
get done (and get done right).
For those who are IP hackers, the problem is that we're
being flooded with SYNs from random IP addresses on
our smtp ports. We are getting on average 150 packets
per second (50 per host).
We are not the only site being attacked in this way. I
know of one other site that is being attacked in an
identical manner right now, and I know of three others
that have been attacked in the last two weeks. I hope that
this means that the attacker is merely playing malicious
games, and will soon tire of molesting our site. If that is
the case, mail will come back up as soon as the attack
ends. But if the attacker is really interested in damaging
Panix specifically, the attack may *never* stop and
service won't be restored until we can write kernel
modifications.
Since then the packet streams have hit almost all the ports for news, www,
telnet, etc.
DCF
NODE 24303faaRe: PANIX.COM down: denial of service attack
M C Wong <mcw@hpato.aus.hp.com>Fri, 13 Sep 1996 16:16:02 +0800
> Here are the gory details from the first MOTD last Saturday:
> The attacker is forging random source addresses on his
> packets, so there is no way to find his/her location. There
> is also no way to screen out those packets with a simple
> router filter.
> This is probably the most deadly type of denial-of-service
> attack possible. There is no easy or quick way of dealing
> with it. If it continues into Saturday we will start working
> on kernel modifications to try to absorb the damage
> (since there's absolutely no way to avoid it). This
> however will not be an easy job and it could take days to
> get done (and get done right).
> For those who are IP hackers, the problem is that we're
> being flooded with SYNs from random IP addresses on
> our smtp ports. We are getting on average 150 packets
^^^^
Can't access to this port be guarded against by a filtering
router which is configured to accept *only* a number of
trusted MX hosts ? That is the target itself *never* permits
any incoming traffic to smtp port *not* in the list of trusted
MX hosts, which does buffering for the target ?
Info on such MX hosts be hidden from secured way of DNS
setup so attacker will not learn about the MX hosts easily.
In case on MX host get flooded, there will be at least one
backup host to take over to prevent a total D.O.S.
> Since then the packet streams have hit almost all the ports for news, www,
> telnet, etc.
> DCF
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M.C Wong Email: mcw@hpato.aus.hp.com
Australian Telecom Operation Voice: +61 3 9210 5568
Hewlett-Packard Australia Ltd Fax: +61 3 9210 5550
P.O. Box 221, Blackburn 3130, Australia
NODE 04417757Re: PANIX.COM down: denial of service attack
"Perry E. Metzger" <perry@piermont.com>Fri, 13 Sep 1996 14:57:55 +0800
M C Wong writes:
> > For those who are IP hackers, the problem is that we're
> > being flooded with SYNs from random IP addresses on
> > our smtp ports. We are getting on average 150 packets
> ^^^^
>
> Can't access to this port be guarded against by a filtering
> router which is configured to accept *only* a number of
> trusted MX hosts ?
Sure -- if you only want to accept mail from fifteen machines on
earth. If on the other hand your users might get mail from anywhere on
earth, your mail ports have to be open to connections from anywhere.
.pm
NODE 2714d0d4Re: PANIX.COM down: denial of service attack
M C Wong <mcw@hpato.aus.hp.com>Fri, 13 Sep 1996 15:21:59 +0800
> M C Wong writes:
> > > For those who are IP hackers, the problem is that we're
> > > being flooded with SYNs from random IP addresses on
> > > our smtp ports. We are getting on average 150 packets
> > ^^^^
> >
> > Can't access to this port be guarded against by a filtering
> > router which is configured to accept *only* a number of
> > trusted MX hosts ?
> Sure -- if you only want to accept mail from fifteen machines on
> earth. If on the other hand your users might get mail from anywhere on
> earth, your mail ports have to be open to connections from anywhere.
No, I am saying that we use MX field in DNS to specify our MX hosts, so
other hosts from anywhere else will timeout connecting to the target smtp
while trying to deliver mails directly to it, and hence will have to send
the message to next best MX host instead, and the firewall is configured
to permit access *only* from those MX hosts.
The problem here becomes how one can protect all those MX hosts instead.
DNS cannot hide those info properly I believe since it will mean it also
hides info of mail delivery to the host, a D.O.S in itself,. 8-((
> .pm
NODE 62edcc32Re: PANIX.COM down: denial of service attack
"Perry E. Metzger" <perry@piermont.com>Fri, 13 Sep 1996 15:36:10 +0800
M C Wong writes:
> > > Can't access to this port be guarded against by a filtering
> > > router which is configured to accept *only* a number of
> > > trusted MX hosts ?
>
> > Sure -- if you only want to accept mail from fifteen machines on
> > earth. If on the other hand your users might get mail from anywhere on
> > earth, your mail ports have to be open to connections from anywhere.
>
> No, I am saying that we use MX field in DNS to specify our MX hosts, so
> other hosts from anywhere else will timeout connecting to the target smtp
> while trying to deliver mails directly to it, and hence will have to send
> the message to next best MX host instead, and the firewall is configured
> to permit access *only* from those MX hosts.
>
> The problem here becomes how one can protect all those MX hosts instead.
You can't. All you are doing is moving the problem. I don't see how
that could be of any possible interest. The machines in question are
already the MX hosts for the zone.
Perry