From: Church, Chuck (cchurch@wamnetgov.com)
Date: Sat Apr 24 2004 - 02:22:33 GMT-3
Of course. In the most simple BGP configs using actual interface
addresses as peers, it'd be easy via tracert to determine two peers.
Using loopbacks (possibly with static routes to get to that loopback) as
BGP peers like you mentioned certainly makes it much tougher and more
unlikely. MD5 and other methods will just make it that much harder. I
guess there's super-secure, super-vulnerable, and a bunch of strategies
that exist in the middle. You can bet that there's hackers with home
labs right now trying to get a functioning 'BGP-buster' tool to work
correctly :) Just trying to stay a step ahead...
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 1:10 AM
To: 'MMoniz'; Church, Chuck; 'Group Study'
Subject: RE: BGP TCP vulnerability - possible solution??
That would be true if we all connected with non-routable addresses!
That introduces other dilemmas though...
-----Original Message-----
From: MMoniz [mailto:ccie2002@tampabay.rr.com]
Sent: Saturday, April 24, 2004 1:04 AM
To: Scott Morris; 'Church, Chuck'; 'Group Study'
Subject: RE: BGP TCP vulnerability - possible solution??
Cool...another good thing that is coming, kind of here now is /31
peering and aes
can only be 1 peer regardless right? Kind of hard to spoof that
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Scott Morris
Sent: Saturday, April 24, 2004 12:50 AM
To: 'Church, Chuck'; 'Group Study'
Subject: RE: BGP TCP vulnerability - possible solution??
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