As one person explained to me, often miscreants broadcast a bogus route so they can launch an attack from a 'reserved' space. What I was probably not clear enough in my original question was why the person at bungi.com was even TRYING to traceroute to a 98/ address. Was it something that showed up in a access log as an failed attempt, or? Is it the case that above.net is black-holing packets with a *destination* in the RBL, but *not* filtering packets with a *source* address from the RBL? If so, this would still allow RPC-based attacks (and TCP as well, if the victim's box had bad sequence number prediction). What are other sites that use the RBL BGP feed doing in this case? (And yes, I understand that many routers can route to a blackhole destination a lot faster than they can apply an ACL on the source). -- Valdis Kletnieks Operating Systems Analyst Virginia Tech traceroute to 98.100.32.32 (98.100.32.32): 1-30 hops, 38 byte packets 1 main.bungi.com (207.126.97.9) 2.15 ms 1.73 ms 1.86 ms 2 above-gw2.above.net (207.126.96.217) 4.41 ms 4.88 ms 3.67 ms 3 core5-main2-oc3.sjc.above.net (216.200.0.205) 3.62 ms 4.56 ms 7.53 ms 4 core3-core5-oc48.sjc2.above.net (208.184.102.206) 6.34 ms 5.7 ms 5.3 ms 5 iad-sjc2-oc48.iad.above.net (216.200.127.25) 73.0 ms 79.7 ms 72.6 ms 6 hat.address.is.on.the.rbl.see.www.mail-abuse.org.for.more.information.above.net
What I was probably not clear enough in my original question was why the person at bungi.com was even TRYING to traceroute to a 98/ address. Was it something that showed up in a access log as an failed attempt, or?
I've seen plenty of attacks and SPAM originate from reserved space, though I don't know if either is what prompted Henry to ask.
I simply asked for a policy understanding is all. Mark Milhollan wrote:
What I was probably not clear enough in my original question was why the person at bungi.com was even TRYING to traceroute to a 98/ address. Was it something that showed up in a access log as an failed attempt, or?
I've seen plenty of attacks and SPAM originate from reserved space, though I don't know if either is what prompted Henry to ask.
-- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | |--------------------------------| Henry R. Linneweh
It showed up in a UDP probe on an Aussie connection, so I tracerouted it for the my associate, now I have a better understanding as to what is going on. Valdis.Kletnieks@vt.edu wrote:
As one person explained to me, often miscreants broadcast a bogus route so they can launch an attack from a 'reserved' space.
What I was probably not clear enough in my original question was why the person at bungi.com was even TRYING to traceroute to a 98/ address. Was it something that showed up in a access log as an failed attempt, or?
Is it the case that above.net is black-holing packets with a *destination* in the RBL, but *not* filtering packets with a *source* address from the RBL? If so, this would still allow RPC-based attacks (and TCP as well, if the victim's box had bad sequence number prediction).
What are other sites that use the RBL BGP feed doing in this case?
(And yes, I understand that many routers can route to a blackhole destination a lot faster than they can apply an ACL on the source).
-- Valdis Kletnieks Operating Systems Analyst Virginia Tech
traceroute to 98.100.32.32 (98.100.32.32): 1-30 hops, 38 byte packets 1 main.bungi.com (207.126.97.9) 2.15 ms 1.73 ms 1.86 ms 2 above-gw2.above.net (207.126.96.217) 4.41 ms 4.88 ms 3.67 ms 3 core5-main2-oc3.sjc.above.net (216.200.0.205) 3.62 ms 4.56 ms 7.53 ms 4 core3-core5-oc48.sjc2.above.net (208.184.102.206) 6.34 ms 5.7 ms 5.3 ms 5 iad-sjc2-oc48.iad.above.net (216.200.127.25) 73.0 ms 79.7 ms 72.6 ms 6 hat.address.is.on.the.rbl.see.www.mail-abuse.org.for.more.information.above.net
------------------------------------------------------------------------ Part 1.2Type: application/pgp-signature
-- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | |--------------------------------| Henry R. Linneweh
participants (3)
-
Henry R. Linneweh -
Mark Milhollan -
Valdis.Kletnieks＠vt.edu