looks like the cisco access-list debugger doesn't show enough detail.
as soon as the path to the attacker crosses a MAE, you need to know the
source MAC level address of the router that's splattering you.
==>looks like the cisco access-list debugger doesn't show enough detail.
==>as soon as the path to the attacker crosses a MAE, you need to know the
==>source MAC level address of the router that's splattering you.
Paul is correct; I left out the caveat that you have to go "hunting" once
you get to a multi-access media network.
However, a good tool at this point becomes the monitor option/port found
on certain switches which will redirect traffic bound for a certain port
to also appear on the monitor port for sniffing. I don't know if the
GIGAswitches have such a monitoring option or port; if so, cooperation
from the various IXP operators would be a great help in determining the
hop.
(I also think implementing a MAC-level packet debug would be very
beneficial to help find culprits in this case, not to mention help
troubleshoot other problems).
/cah
} Paul is correct; I left out the caveat that you have to go "hunting"
} once you get to a multi-access media network.
I've already tossed most of the messages from this thread, but someone
mentioned using Cisco's flow statistics to track the attacker. Mark even
offered the URL to an analysis toolkit he's been working on.
After using either flow or accounting data to track down the attacker,
further flow data can be extracted to provide next hop and/or AS_path
information. AS_path could direct you to the final ISP or organization in
the path of the network address. (This doesn't take into account if the
attacker has hacked an account, etc. 
This should severely limited the
ammunition required to go hunting, but it does have the requirement of
using Cisco's NetFlow feature(s).
} However, a good tool at this point becomes the monitor option/port
} found on certain switches which will redirect traffic bound for a
} certain port to also appear on the monitor port for sniffing. I don't
} know if the GIGAswitches have such a monitoring option or port; if so,
} cooperation from the various IXP operators would be a great help in
} determining the hop.
I don't recall if the Gigaswitch supports this or not (a scan of the
"Manager's Guide" doesn't mention anything), but even if it did; each
port would have to be replicated independantly, eating alot of the IXP
operators' time.
Jonathan Heiliger \|/ _____ \|/ I S I
VP, Research & Development @~/ . . \~@ Internet Systems, Inc.
________________________________/_( \___/ )_\____________________________
\__U__/
E-Mail: loco@isi.net Phone: 415.943.2915
Maybe I'm missing something here, but wouldn't these Denial of Service
attacks cause a severe mismatch in the numbers of SYNs and SYN-ACKs on a
given router interface?
If so, then couldn't we just sweet-talk cisco into providing 5 minute
counts of syns and syn-acks on an interface? You know something like:
5 minute SYNS: 123423 5 minute SYN-ACKS: 50000
Then, if the ratio got too high, it can start yelping about "Potential SYN
D-O-S Atttack in progress on Interface Serial 1"
In this manner "good" isp's wouldn't unknowingly carry these attacks. I
envision this being done on the somewhat bigger isp's where putting
inbound filters on their customer interfaces would be not a good idea
(Sprint, MCI, Net 99, etc.). If the feature was enabled by default, some
smaller ISPs would probably notice it--if they are watching their cisco
logs at all.
Personally, I know that these attacks aren't going to originate at our
site, as I have the filters on. However, I am quite concerned about
getting hit with one...
Your suggestion has two flaws:
1. missed SYN ACKs due to asymmetric routing.
2. missed SYN ACKs due to diode routes.
One could argue, of course, that notification of this condition (without
speculating on whether the condition is any of an asymmetric route, a diode
route, or a SYN attack) might be worthwhile...
I'm gonna have to go digging in my archives for the messages I sent to the
CERT and the IETF about this potential problem after it happened to me at
Apple, three years ago, due to a diode route. I publically recommended to
the IETF mailing list that the edges of the network be filtered, and I
privately recommended to the CERT that they begin flogging the systems
vendors for robustness in the face of precisely this denial of service
attack in their hosts. You can imagine the incredible levels of
enthusiastic "can do" attitude I got...
Erik Fair