Re: Land and Cisco question
At 10:58 AM 11/22/97 -0800, John Bashinski wrote: I was *extremely* unclear in what I sent since I was running out the door. Most cisco routers run by ISPs (here on NANOG) have at least 50 interfaces (subinterfaces) and usually average 100. Each and every interface/subinterface has to be blocked. So it is either create an extended access list with all 100 individual interface addresses blocked (and update it as new customers get connected) or block by subnet, i.e if all interfaces come from a 255.255.255.252 (/30) subnetted block, then block the whole /24. But then the problem I discussed below creeps up. Any recommendations on how to block this by subnet (assuming the router side always has the same bit position in the subnet)? -Hank
-----BEGIN PGP SIGNED MESSAGE-----
Does BGP use TCP or UDP?
TCP.
If TCP then we are in trouble.
I don't think so.
Almost everyone has access to the Internet via BGP. The line IP address is usually made up of a pair of addresses in the same subnet. You can IP spoof block all your internal IP addresses but if you block the IP address of your BGP connection to your BGP peer and BGP uses TCP, then the examples jbash gave out will stop BGP updates as well.
This was my example:
interface ethernet 0 ip address 1.2.3.4 255.255.255.0 ip access-group 101 in ! interface ethernet 1 ip address 5.6.7.8 ip access-group 101 in ! access-list 101 deny tcp 1.2.3.4 0.0.0.0 1.2.3.4 0.0.0.0 access-list 101 deny tcp 5.6.7.8 0.0.0.0 5.6.7.8 0.0.0.0 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
That only blocks the router talking to itself, not talking to any other host, whether on the same subnet or not. As far as I know, you don't have to have a TCP connection to yourself to run BGP, just to your neighbors.
-- John B.
-----BEGIN PGP SIGNATURE----- Version: None of your beeswax
iQCVAwUBNHcrO3emvD4nAHb9AQHpsAP+OV+xm3uQ+N1Xoc6auDyKfM/j0L9JPqvL n1pKNh73jqZz8vMzMWOkm8wcnGkW9u+JFQ0tSlkEtpkWrAG96f0kmSpXyfC6BRYo RvpkXL4hHT0A+1HSbVNmOjGjfThdEyWOdhcE9jJc35PxzErzarsyFTPnjK6Fl5Rl 8wVsoHAPNYU= =cAK5 -----END PGP SIGNATURE-----
I was *extremely* unclear in what I sent since I was running out the door. Most cisco routers run by ISPs (here on NANOG) have at least 50 interfaces (subinterfaces) and usually average 100. Each and every interface/subinterface has to be blocked. So it is either create an extended access list with all 100 individual interface addresses blocked (and update it as new customers get connected) or block by subnet, i.e if all interfaces come from a 255.255.255.252 (/30) subnetted block, then block the whole /24. But then the problem I discussed below creeps up. Any recommendations on how to block this by subnet (assuming the router side always has the same bit position in the subnet)?
you still do not get it. NO PER-CUSTOMER CHANGE! for each interface on a router block tcp which is both to and from that interface the problem, of course, is the performance hot for packet filters on OC3s etc. randy
So it is either create an extended access list with all 100 individual interface addresses blocked
you still do not get it. NO PER-CUSTOMER CHANGE!
for each interface on a router block tcp which is both to and from that interface
Um, if your concentrator router has one interface per L/L customer (or one subinterface per customer), you *do* need to add another line to the extended ACL for each new subinterface added, which looks like access-list 164 deny ip n.n.n.n 0.0.0.0 n.n.n.n 0.0.0.0 where n.n.n.n is the ip address of the new subinterface on the concentrator router, because the ACL has one line per (sub)interface on the router. However many of us (I think) don't run with a new subinterface for each new customer, and a still easier fix is to upgrade to one of the non-vulnerable IOS versions (there being at least one for each of 10.3, 11.0, 11.1 & 11.2). -- Alex Bligh GX Networks (formerly Xara Networks)
I'm sorry - but the Right Thing (tm) to do is to ingress filter, as I have already evangelized. Like it or not. - paul At 08:13 PM 11/22/97 +0000, Alex Bligh wrote:
Um, if your concentrator router has one interface per L/L customer (or one subinterface per customer), you *do* need to add another line to the extended ACL for each new subinterface added, which looks like
access-list 164 deny ip n.n.n.n 0.0.0.0 n.n.n.n 0.0.0.0
where n.n.n.n is the ip address of the new subinterface on the concentrator router, because the ACL has one line per (sub)interface on the router.
However many of us (I think) don't run with a new subinterface for each new customer, and a still easier fix is to upgrade to one of the non-vulnerable IOS versions (there being at least one for each of 10.3, 11.0, 11.1 & 11.2).
-- Alex Bligh GX Networks (formerly Xara Networks)
Randy Bush said:
for each interface on a router block tcp which is both to and from that interface
I don't think that's sufficient. What about spoofed packets arriving via interface A, with IP source and destination both set to the address of interface B? --apb (Alan Barrett)
On Sun, 23 Nov 1997, Alan Barrett wrote:
Randy Bush said:
for each interface on a router block tcp which is both to and from that interface
I don't think that's sufficient. What about spoofed packets arriving via interface A, with IP source and destination both set to the address of interface B?
--apb (Alan Barrett)
no ip source-route should fix it. Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services Up WAY too early on a Sunday... :)
for each interface on a router block tcp which is both to and from that interface I don't think that's sufficient. What about spoofed packets arriving via interface A, with IP source and destination both set to the address of interface B? no ip source-route should fix it.
<insert replay of we don't peer with LSR inhibitors discussion> Though temp inhibit until YFRV deploys fixed code is understandable. randy
Randy Bush wrote: :-> <insert replay of we don't peer with LSR inhibitors discussion> :-> Randy, I'm curious - is this a firm "NO" thing, or do you peer with people that offer alternatives ? We disable LSR a/x our whole net but still provide a traceroute server and (RSN) a looking glass. What other reasons do you want LSR enabled for ? :-> randy :-> Cheers, Lyndon Levesley GX Networks
I'm curious - is this a firm "NO" thing, or do you peer with people that offer alternatives ? We disable LSR a/x our whole net but still provide a traceroute server and (RSN) a looking glass. What other reasons do you want LSR enabled for ?
1. It's certainly a helluvalot easier to make a traceroute server lie, than to make LSRR lie. 2. Typically one wants to test from MULTIPLE borders of a given network to ensure that they are doing shortest-exit properly. A traceroute server is useless for this, unless you have one attached to every router. 3. There's a significantly higher probability that a traceroute server might be down, than that all backbone LSRR might be down. 4. With LSRR, it works the same way for everybody. No need to keep a database of address<>traceroute server correspondances, no need to worry about the subtlties of parsing other people's traceroute output [which version of traceroute did they use? do they let you specify arguments, etc., etc.] Clear? --jhawk
<insert replay of we don't peer with LSR inhibitors discussion> I'm curious - is this a firm "NO" thing, or do you peer with people that offer alternatives ? We disable LSR a/x our whole net but still provide a traceroute server and (RSN) a looking glass. What other reasons do you want LSR enabled for ?
We use LSR for debugging. We have many peers. We do not intend to maintain a procedure of the week manual for each peer. Hell to maintain and does not scale. randy
At 04:38 PM 11/23/97 +0000, Lyndon Levesley wrote:
I'm curious - is this a firm "NO" thing, or do you peer with people that offer alternatives ? We disable LSR a/x our whole net but still provide a traceroute server and (RSN) a looking glass. What other reasons do you want LSR enabled for ?
traceroute -g can be a surprisingly useful tool. - paul
Hello Paul, On Mon, 24 Nov 1997, Paul Ferguson wrote:
At 04:38 PM 11/23/97 +0000, Lyndon Levesley wrote:
I'm curious - is this a firm "NO" thing, or do you peer with people that offer alternatives ? We disable LSR a/x our whole net but still provide a traceroute server and (RSN) a looking glass. What other reasons do you want LSR enabled for ?
traceroute -g can be a surprisingly useful tool.
And what traceroute are you using ?????? None of the BSD versions have it . JimL
traceroute -g can be a surprisingly useful tool.
And what traceroute are you using ??????
None of the BSD versions have it . JimL
The canonical traceroute distribution is available via ftp from ftp.ee.lbl.gov. Another version is avaialble from ftp.nikhef.nl in /pub/network, but it's generally considered to be inferior. Consider reading the NANOG mail archive before asking your question, next time. --jhawk
On Mon, 24 Nov 1997 20:57:55 -0800 (PST) Network Operations Center <noc@nwrain.net> wrote:
traceroute -g can be a surprisingly useful tool.
And what traceroute are you using ??????
None of the BSD versions have it . JimL
/usr/home/neil:neil@NetBSD>traceroute -g Version 1.4a5 Usage: traceroute [-dDFIlnrvx] [-g gateway] [-i iface] [-f first_ttl] [-m max_ttl] [ -p port] [-q nqueries] [-s src_addr] [-t tos] [-w waittime] host [packetlen] -- Neil J. McRae. Alive and Kicking. Domino: In the glow of the night. neil@DOMINO.ORG NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>
At 4:54 AM -0500 11/23/97, Alan Barrett wrote:
Randy Bush said:
for each interface on a router block tcp which is both to and from that interface
I don't think that's sufficient. What about spoofed packets arriving via interface A, with IP source and destination both set to the address of interface B?
In this case the packets must eventually be transmitted via interface B and Interface B transmit rules should take care of that. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[ On Mon, November 24, 1997 at 19:38:49 (-0500), Dean Anderson wrote: ]
Subject: Re: Land and Cisco question
At 4:54 AM -0500 11/23/97, Alan Barrett wrote:
Randy Bush said:
for each interface on a router block tcp which is both to and from that interface
I don't think that's sufficient. What about spoofed packets arriving via interface A, with IP source and destination both set to the address of interface B?
In this case the packets must eventually be transmitted via interface B and Interface B transmit rules should take care of that.
There is already a modified version of the "land" attack that may make protection of vulnerable gear by it's own interface filters a bit tricky. It involves sending multiple spoofed SYN attacks in quick succession to more than one interface on the device and in such a configuration that there are pairs which point at each other. Supposedly this variant of the attack has been successful (or at least analysis showed it would be successful) against some versions of 4.4BSD TCP/IP. Indeed it still should be possible to write correct filters for all interfaces to protect against this variant of the attack, but without algorithmic help in defining them the problem may become too complex for the average human to solve without error. I think the "mkfilters" perl script included with ipfilter does a fairly decent job of writing such rules, though the one time I've had occasion to use it on a small core router with a mere six interfaces I still had so spend some time fixing its output up because it didn't handle subnet netmasks very well. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
participants (12)
-
Alan Barrett -
Alex Bligh -
Dean Anderson -
Hank Nussbacher -
Joe Shaw -
John Hawkinson -
Lyndon Levesley -
Neil J. McRae -
Network Operations Center -
Paul Ferguson -
Randy Bush -
woods＠most.weird.com