Is there a program which users can run on an end-site workstation which
would test whether they are being some link which is doing BCP38, or some
related type of source-address ingress filtering?
I'm hoping for something that could be downloaded by users and run, and
try to forge a few packets to somewhere useful, which could be logged
somehow in conjunction with some unforged packets containing a traceroute,
so we could build up a database of leaky networks.
On a related topic, while I know GRC Research's Steve Gibson is a bit of
a polarizing personality, he does have a fairly sizable consumer audience,
and might be a great distribution venue for such a thing.
Or, perhaps, is there someone on here from Ookla?
Patrick? Could Akamai be persuaded to take an interest in this as a
research project?
I dunno; does that automatically submit the details to a central site,
and not bother the user with anything more than "Your connection appears
to be protected with BCP38 filtering" or "No, your provider appears not
to be using BCP38 filtering; we'll let them know"?
I believe that most everyone has a CPE of some sort, whether their service is resi or commercial. So, what about shifting the focus to the CPE manufacturers? They bend to technology and/or market pressures by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to their respective products in to satisfy technology limitations or security concerns or whatever. Why can't they help the cause by implementing some sort of RFC'ified BCP38 thing?
I can assume that If you are spoofing packets, resetting passwords on cpe
and replacing the box would be trivial. So it's questionable how useful
this is. It seems like it just adds cost to for customers that can't spoof
a packet to save their lives.
Is there a program which users can run on an end-site workstation which
would test whether they are being some link which is doing BCP38, or some
related type of source-address ingress filtering?
I'm hoping for something that could be downloaded by users and run, and
try to forge a few packets to somewhere useful, which could be logged
somehow in conjunction with some unforged packets containing a traceroute,
so we could build up a database of leaky networks.
On a related topic, while I know GRC Research's Steve Gibson is a bit of
a polarizing personality, he does have a fairly sizable consumer audience,
and might be a great distribution venue for such a thing.
Or, perhaps, is there someone on here from Ookla?
Patrick? Could Akamai be persuaded to take an interest in this as a
research project?
From my perspective, 99% of end-users probably don't understand (or care)
that their provider might be responsible for initiating or precipitating a
DDoS attacks, period. Most network operators are probably either too
inexperienced to understand or too lazy to care.
I believe that most everyone has a CPE of some sort, whether their service
is resi or commercial. So, what about shifting the focus to the CPE
manufacturers? They bend to technology and/or market pressures by bringing
things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to
their respective products in to satisfy technology limitations or security
concerns or whatever. Why can't they help the cause by implementing some
sort of RFC'ified BCP38 thing?
I can assume that If you are spoofing packets, resetting passwords on cpe and replacing the box would be trivial. So it's questionable how useful this is. It seems like it just adds cost to for customers that can't spoof a packet to save their lives.
Maybe it's useful for the people who have no idea that their computers are infected by bots that spoof packets.
Someone privately emailed me asking about the problems I had. When I looked at it some more, I found the autoconf error was just very misleading, and my build environment was incomplete. With all the right tools installed, it built just fine on the Ubuntu 12.04 64-bit machine I was playing on.
I guess I can see that. You then have a question of implementation.
Wouldn't a majority of those customers have a bridged connection with the
providers CPE being a transparent bridged modem. So either a customer's
cheap router (good luck getting those guys to add a feature) would have to
do the check, or the modem would have to check with the router for ip and
then do packet inspection.
I'm not debating that this would be a good fix and eliminate the effect of
botnets, but the home router market isn't going to be influenced by
providers. If it sells at a big box electronics store, it will be
in circulation. It seems that the only people who would care at the home
networking level aren't likely to be contributing to the botnets.
On the other hand, any ISP that would want this as a feature in their
modems, would find it easier to implement on commercial hardware.
It would work and it's a good idea, I just don't see it gaining traction in
the right places to be effective. The answer still rests with providers.
This thought crossed my mind earlier today, when I asked Jeff if IP-forged
packets would make it through a NAT, outbound. He said no (I think), but
I'm not entirely sure that's right.
While that would be egress filtering, from the POV of the home-LAN, it
would still help in the trojan-horse-bot situation, as long as it couldn't
be opened up via something like PPTP, and would thus still be useful,
to some extent, sure.
Welll - the packets might make it out, and be transmitted into the
Internet, but they would have a legitimate source address, namely an
outside address of the NAT router. A side effect of NAT is to clamp the
source address range of outbound packets to the configured NAT outside
address range.
I don't have a canned solution, but I've had good luck testing with nmap (-S and -e are relevant) while running tcpdump (and filtering for the protocols/ports) on a remote host. I can happily report that someplace upstream of my home connection is doing some filtering -- nice. I still need to test at work.
OK - how does one configure NAT so that the source addresses of outbound
packets are NOT clamped to a configured range on the outside of the NAT
device? Given this general scenario, of course:
> A side effect of NAT is to clamp the source address range
It depends on how the nat is configured.
OK - how does one configure NAT so that the source addresses of outbound
packets are NOT clamped to a configured range on the outside of the NAT
device? Given this general scenario, of course:
He said it depends on how NAT is configured; but really, before it
depends on that -- it first depends on what kind of device is used,
and what kind of NAT is being implemented.
In some implementations, only certain ranges of source IP addresses
are subject to translation. They might be NAT'ing based on network,
interface, or access-list.
It occurs that if the CPE are /truly/ clamping the Source address
space, then essence,
BCP38 is essentially happening at the CPE.
If your packet source address is clamped, then, by definition a host
can't spoof a packet, right; so maybe that's not a host that needs to
be tested further (the upstream provider might still have no BCP38,
it's just not exposed to that particular host).
Unless, of course, there are protocols your NAT device passes
unaltered such as possibly ICMP, or ICMPv6, in case NAT only
applies to IPv4, a host behind the NAT might still be able to spoof
IPv6 source addresses.
Folks should implement anti-spoofing southbound of their NATs, using uRPF, ACLs, IP Source Guard, Cable IP Source Verify, or whatever, in order to keep botted hosts attempting to launch outbound/crossbound spoofed DDoS attacks (such as spoofed SYN-floods) from filling up the NAT translation-table and making it fall over, thus creating an outage for everything behind the NAT. I've seen this happen many times, especially in the mobile/fixed wireless space.
Likewise, they should implement anti-spoofing northbound, eastbound, and westbound of the NAT (eastbound and westbound assume it's a network of some scope), so that nothing else on their networks can send spoofed packets to external networks.
Um - if no address translation takes place, then, by definition, NAT has
not taken place.
So it may well be that a particular device, capable of doing NAT and
other things, of NATting some packets but not others, may permit
spoofed-because-not-NATted outbound packets, but I remain unconvinced
that a spoofed packet can make it through a NAT process and head
outbound without getting its source address clamped to a configured
range of outside addresses.
Now I'm imagining a NAT process that translates only *destination*
addresses - hm, is there such a beast?
Sure - you just have rules in place which map the destination IPs of incoming packets, based upon classification criteria expressed in the NAT config, to the destination address(es) of choice.
Those who ill-advisedly run servers behind NATs use this functionality.
You can also turn a NAT with this type of configuration 'upside-down', so that the 'public' side is nearest the traffic sources, if desired.
