From: Scott Morris (swm@emanon.com)
Date: Sat Apr 24 2004 - 01:49:53 GMT-3
NSP has some pretty bright guys on it! And I wholeheartedly agree that
there is potential for that to happen.
But with all of this, it begs some questions....
1. Who has really been victimized by this?
2. What are the chances of it happening?
3. Presumably, the bigger networks are the most at risk and most likely to
be attacked, so why wouldn't there be some simple filters in place?
4. We are talking about the edge of the network now, not the core...
Perhaps an easier solution would be to work with your peers and create a
specific loopback address that each router has. Peer between those
loopbacks and have it be a private address that is not shared with any other
routing protocol. Everyone else has a supernet route to null0 statically
for whatever range is used in the network.
Hence you kill reachability to or from that particular IP by any other
device outside of the two routers that are talking.
*shrug*
For Juniper, you could also do "set routing-options forwarding-table
unicast-reverse-path active-paths"
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: Church, Chuck [mailto:cchurch@wamnetgov.com]
Sent: Saturday, April 24, 2004 12:28 AM
To: swm@emanon.com; Group Study
Subject: RE: BGP TCP vulnerability - possible solution??
True, but the problem discussed on the NSP list was that now you could
become a victim of a CPU DOS, where you're getting hit with large amounts of
MD5 packets, having to do a decryption of each one to see if it's legitimate
or not. A lot of people on that list were leery of MD5 for that reason. If
everyone's using a different random DSCP instead of the standard precedence
6, it's another level of security. I suppose you could combine the MD5 with
the DSCP, assuming re-writing the DSCP doesn't break the MD5 hash. Then you
could filter out most hack attempts with a CPU-friendly ACL, and then get
the rest with the MD5 authentication. Not sure if Juniper has this
functionality, so maybe it's a moot point...
Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Wam!Net Government Services - Design & Implementation Team
13665 Dulles Technology Dr. Ste 250
Herndon, VA 20171
Office: 703-480-2569
Cell: 703-819-3495
cchurch@wamnetgov.com
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=index&search=cchurch%40wamnetgov.
com
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Saturday, April 24, 2004 12:15 AM
To: Church, Chuck; 'Group Study'
Subject: RE: BGP TCP vulnerability - possible solution??
Well... Ok, but we'd have to work that out with every one of our own
providers in a unique fashion.
If we all do the same thing, it would become predictable, therefore not much
help.
If we have to talk to each of our BGP feeds anyway, why not set up a
password? :)
Just a thought!
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Church, Chuck
Sent: Friday, April 23, 2004 11:13 PM
To: Group Study
Subject: BGP TCP vulnerability - possible solution??
All,
Been brainstorming a bit, came up with this. How about setting
either the IP precedence or DSCP with a route map and local policy, and
allowing only BGP to and from your router with this particular precedence
set? BGP defaults to precedence 6, so I used something else:
RTR1:
ip local policy route-map setprec
!
access-list 100 permit tcp any eq bgp host 192.168.0.1 range 11000 65525
access-list 100 permit tcp any range 11000 65535 host 192.168.0.1 eq bgp
access-list 120 permit tcp host 192.168.0.1 eq bgp host 192.168.0.11 range
11000 65535 precedence flash-override access-list 120 permit tcp host
192.168.0.1 range 11000 65535 host
192.168.0.11 eq bgp precedence flash-override
access-list 120 deny tcp host 192.168.0.1 eq bgp host 192.168.0.11
range 11000 65535
access-list 120 deny tcp host 192.168.0.1 range 11000 65535 host
192.168.0.11 eq bgp
access-list 120 permit ip any any
!
route-map setprec permit 10
match ip address 100
set ip precedence flash-override
RTR2:
ip local policy route-map setdscp
!
access-list 100 permit tcp any range 11000 65525 host 192.168.0.11 eq bgp
access-list 100 permit tcp any eq bgp host 192.168.0.11 range 11000
65535
access-list 120 permit tcp host 192.168.0.11 eq bgp host 192.168.0.1 range
11000 65535 precedence flash-override access-list 120 permit tcp host
192.168.0.11 range 11000 65535 host
192.168.0.1 eq bgp precedence flash-override
access-list 120 deny tcp host 192.168.0.11 eq bgp host 192.168.0.1
range 11000 65535
access-list 120 deny tcp host 192.168.0.11 range 11000 65535 host
192.168.0.1 eq bgp
access-list 120 permit ip any any
route-map setdscp permit 10
match ip address 100
set ip precedence flash-override
With these two setup as eBGP peers, it works fine. But if you disable the
local policy routing on one side, the access lists block the packets as
expected, which would block a rogue SYN/RST. If you can take the
performance hit on an interface or on the control plane of a router, this
might help. This example used precedence, but with DSCP, you've got what,
64 different combinations? Certainly makes it much harder for a hacker to
get it right.
Just a thought...
Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Wam!Net Government Services - Design & Implementation Team
13665 Dulles Technology Dr. Ste 250
Herndon, VA 20171
Office: 703-480-2569
Cell: 703-819-3495
cchurch@wamnetgov.com
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=index&search=cchurch%40wamnetgov.
com
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:54 GMT-3