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)?
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.
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?
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.
[ On Mon, November 24, 1997 at 19:38:49 (-0500), Dean Anderson wrote: ]
Subject: Re: Land and Cisco question
>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.
