Hi,
What if sessions were attacked without MD5 in place. We would just see session resets. As these happen anyway frequently at peering points is there any straightforward way to determine if the vulnerability caused the reset?
If you're referring to session resets because of a peer or user action then something akin to "Last reset due to FOO" can likely be gleaned from "show bgp neighbor" output, especially since BGP performs "graceful shutdown" via notification messages under normal conditions
I think what I'm trying to ask is: 1. Does anyone know if the exploit is actually being used? and 2. I assume there is no way to identify an exploit reset from the usual resets caused by routers hanging, ports failing, DDoS's, etc. However, I thought I'd ask... Kind regards, Mark
On 13-mei-04, at 13:31, Mark Johnson wrote:
I think what I'm trying to ask is:
1. Does anyone know if the exploit is actually being used? and 2. I assume there is no way to identify an exploit reset from the usual resets caused by routers hanging, ports failing, DDoS's, etc. However, I thought I'd ask...
This is from a couple of weeks, give or take, on an interface with 100 or so peers: deny tcp any any eq bgp rst log-input (3714 matches) If this is an attack I wish they were all like this. :-)
participants (2)
-
Iljitsch van Beijnum -
Mark Johnson