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? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
You mean like this? :-) http://spoofer.csail.mit.edu/ - ferg On Sun, Mar 31, 2013 at 7:48 AM, Jay Ashworth <jra@baylink.com> wrote:
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?
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
-- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
----- Original Message -----
From: "Paul Ferguson" <fergdawgster@gmail.com>
You mean like this? :-)
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"? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
They should updated their autoconf. It fails on modern 64-bit Linux. On Sun, 31 Mar 2013, Paul Ferguson wrote:
You mean like this? :-)
- ferg
On Sun, Mar 31, 2013 at 7:48 AM, Jay Ashworth <jra@baylink.com> wrote:
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?
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
-- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
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. On Sun, 31 Mar 2013, Jon Lewis wrote:
They should updated their autoconf. It fails on modern 64-bit Linux.
On Sun, 31 Mar 2013, Paul Ferguson wrote:
You mean like this? :-)
- ferg
On Sun, Mar 31, 2013 at 7:48 AM, Jay Ashworth <jra@baylink.com> wrote:
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?
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
-- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 2013-03-31, at 10:48 AM, Jay Ashworth <jra@baylink.com> wrote:
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?
----- Original Message -----
From: "Jason Lixfeld" <jason@lixfeld.ca>
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?
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. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Sun, 2013-03-31 at 22:32 -0400, Jay Ashworth wrote:
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.
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. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
In message <1364787851.2136.7.camel@karl>, Karl Auer writes:
On Sun, 2013-03-31 at 22:32 -0400, Jay Ashworth wrote:
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.
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.
Regards, K.
It depends on how the nat is configured. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Mon, 2013-04-01 at 15:07 +1100, Mark Andrews wrote:
In message <1364787851.2136.7.camel@karl>, Karl Auer writes:
A side effect of NAT is to clamp the source address range of outbound packets to the configured NAT outside 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: Inside Outside Nasty spoofing scum ----> NAT ---> helpless victims Outbound ---> Honest question - just 'because I don't see it doesn't mean it isn't possible :-) My NAT configs have generally been pretty plain vanilla. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
On 3/31/13, Karl Auer <kauer@biplane.com.au> wrote:
On Mon, 2013-04-01 at 15:07 +1100, Mark Andrews wrote:
In message <1364787851.2136.7.camel@karl>, Karl Auer writes:
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.
Inside Outside Nasty spoofing scum ----> NAT ---> helpless victims Outbound --->
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. -- -JH
On Apr 1, 2013, at 1:31 PM, Jimmy Hess wrote:
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).
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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Mon, 2013-04-01 at 01:31 -0500, Jimmy Hess wrote:
On 3/31/13, Karl Auer <kauer@biplane.com.au> wrote:
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 [...] In some implementations, only certain ranges of source IP addresses are subject to translation.
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? Continuing to seek enlightenment... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
On Apr 1, 2013, at 3:02 PM, Karl Auer wrote:
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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 4/1/13, Karl Auer <kauer@biplane.com.au> wrote:
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
Yes. Many NAT devices of reasonable quality are fully capable of such things. And skipping NAT or NAT'ing the source IP address on the outgoing interface to the same as the source IP address the packet had on the incoming interface, is the likely default, when NAT has been configured based on source IP address range, on some devices.
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.
Ah, but did you actually test your guess on a reasonably large variety of NAT platforms? It just takes 1 instance of the right platform to be in significant use for something to be different than expected. I remain unconvinced that all CPEs in all common configurations will clamp the source address to a legitimate one in all cases. It would just be way too much luck and convenience for that to happen by coincidence.
Now I'm imagining a NAT process that translates only *destination* addresses - hm, is there such a beast?
Of course there is... in some implementations you may need two NAT rules to define a 1:1; a source NAT rule, and a destination NAT rule; if you define only the Source NAT rule, you just translate the source IP address ranges selected to the translation IP address range(s) selected for outgoing connections, and new incoming connections are not translated; if you define only the DNAT rule, you translate only the WAN interface destination IP for incoming connections, and outgoing connections are not translated. In various implementations you can have full-cone NAT, address-restricted cone NAT, port-restricted cone NAT, symmetric NAT, and various combinations and variations (even different kinds of NAT in different directions), for each of source and destination address, with or without storage of a mapping for return traffic. Different source or destination IP ranges or TCP/UDP ports might be NAT'ed differently or not at all. Not all implementations allow all possible useful NAT configurations.
Continuing to seek enlightenment...
Regards, K. -- -JH
----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
Ah, but did you actually test your guess on a reasonably large variety of NAT platforms?
He may not have, but now that I'm thinking (caffeine is a wonder drug), I have: I've worked on, for customers, nearly every brand of consumer router on the market, and all of them do outbound NAT the same way: Pick up a DHCP address from the carrier, and use that as the source IP on all translated outbound packets. I have never found anything for which that's *not* the default config. Upscale things like Snapgears, and routers running -WRT or Tomato, etc, can be configured to do other things, but even on those, that's the default config for outbound NAT.
It just takes 1 instance of the right platform to be in significant use for something to be different than expected.
Sure, but the question here is "is it reasonable to think that the *magnitude* of the problem is substantially reduced because consumer NAT routers are doing much of the work for us" and that answer is decidedly "yes, it is". Sure, it's egress filtering, and a bad actor can get around it, if only by *not using a router*. But a *trojan* likely cannot, and that helps us a lot too; 4-6 orders of magnitude, depending on your opinion of the penetration of consumer edge routers.
I remain unconvinced that all CPEs in all common configurations will clamp the source address to a legitimate one in all cases.
"All"? Yeah, probably not. But I think we're getting 99%, and you know what? I'll take that.
It would just be way too much luck and convenience for that to happen by coincidence.
Once in a while, you win.
Now I'm imagining a NAT process that translates only *destination* addresses - hm, is there such a beast?
Of course there is... in some implementations you may need two NAT rules to define a 1:1; a source NAT rule, and a destination NAT rule; if you define only the Source NAT rule, you just translate the source IP address ranges selected to the translation IP address range(s) selected for outgoing connections, and new incoming connections are not translated; if you define only the DNAT rule, you translate only the WAN interface destination IP for incoming connections, and outgoing connections are not translated.
In various implementations you can have full-cone NAT, address-restricted cone NAT, port-restricted cone NAT, symmetric NAT, and various combinations and variations (even different kinds of NAT in different directions), for each of source and destination address, with or without storage of a mapping for return traffic.
Different source or destination IP ranges or TCP/UDP ports might be NAT'ed differently or not at all.
Not all implementations allow all possible useful NAT configurations.
And the majority, by implementation count, don't allow *any* of those. They allow outbound-SNAT, and configurable inbound-DNAT, maybe. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Mon, Apr 01, 2013 at 12:31:05PM -0400, Jay Ashworth wrote:
From: "Jimmy Hess" <mysidia@gmail.com>
Ah, but did you actually test your guess on a reasonably large variety of NAT platforms?
He may not have, but now that I'm thinking (caffeine is a wonder drug), I have: I've worked on, for customers, nearly every brand of consumer router on the market, and all of them do outbound NAT the same way:
Pick up a DHCP address from the carrier, and use that as the source IP on all translated outbound packets.
The key issue at hand (I believe; please correct me if I'm wrong) is that "all translated outbound packets" may not equal "all outbound packets". Depending on how a NAT device is configured, it may pass some packets *untranslated*, and that allows a malicious actor behind the NAT device to still get their spoofed traffic out. To relate it back to something concrete, imagine this iptables rule in an otherwise "fully open" configuration: iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o wan -j MASQUERADE Now, spoof a packet from behind this NAT box as coming from 192.0.2.12... what happens? It gets passed through the NAT box, *without* being NATed. Oops. Of course, it isn't hard to stop this sort of thing... iptables -A INPUT ! -s 192.168.1.0/24 -i lan -j DROP (or any number of other equivalent rules) The question is, how many in-common-use CPEs have considered this attack vector and are actually doing something functionally equivalent to the DROP rule above? I don't know, because I haven't tried it, but I'd only be surprised if the answer was "none" or "all of them". - Matt
On 4/1/13, Jay Ashworth <jra@baylink.com> wrote:
It would just be way too much luck and convenience for that to happen by coincidence.
Once in a while, you win.
The trouble with winning by coincidence or winning as a side-effect... Do you keep winning? What happens with IPv6 CPE devices, when there is no NAT? No translation occurs, so possibly rogue source IP packets get through, unless the device specifically applies uRPF or clamping source addresses to the LAN interface subnet. It would be nice if the RFCs specified Ingress filtering by default in router requirements for IPv4 and IPv6, as a MUST requirement; instead of some 2nd class citizen, optional best practices document. By specifying ingress as the default, it then becomes an implementor responsibility to understand when and where in their network they have to override the default for things to work properly, when it is safe to, and where the filtering is required. -- -JH
----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
On 4/1/13, Jay Ashworth <jra@baylink.com> wrote:
It would just be way too much luck and convenience for that to happen by coincidence.
Once in a while, you win.
The trouble with winning by coincidence or winning as a side-effect... Do you keep winning?
Depends on how you won.
What happens with IPv6 CPE devices, when there is no NAT?
Well, that's going to be an interesting question in general: will v6 edge routers a) exist, b) handle the addressing, c) handle DHCP, d) actually not do NAT, or e) NAT a v4 home network to a v6 address/network?
No translation occurs, so possibly rogue source IP packets get through, unless the device specifically applies uRPF or clamping source addresses to the LAN interface subnet.
It would be nice if the RFCs specified Ingress filtering by default in router requirements for IPv4 and IPv6, as a MUST requirement; instead of some 2nd class citizen, optional best practices document.
Nah. That's *not* ingress filtering, for all practical purposes; it's *egress* filtering -- filtering that's under control of the network operating entity, and thus semi-useless for the purposes at hand. (On re-reading that, I see I'm not entirely clear: any filtering has to be done on the upsptream end of the link, so that it is *not* in control of the entity which might be originating the bad packets; John Carmack illustrated why in his piece about Quake cheating. What; you haven't read that piece? And you run networks? :-) Cheers, -- jra Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On 04/01/13 04:02, Karl Auer wrote:
On Mon, 2013-04-01 at 01:31 -0500, Jimmy Hess wrote:
On 3/31/13, Karl Auer <kauer@biplane.com.au> wrote:
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 [...] In some implementations, only certain ranges of source IP addresses are subject to translation. 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?
Continuing to seek enlightenment...
Regards, K. While I was reading this... thinking that a NAT is a NAT is a NAT... ( I spend "some" time writing/porting NAT code in my youth )
I'm sad to confirm that my spoof test was successful with a: . SageMCom modem+router, which is used by a big TelCo around my part, for both their residential and commercial ADSL2+, VDSL customers. . 4 well know Tier-2(?) provider :( why I'm wasting time filling up "paper" LoA if its only going to be used for BGP. But on the other hand... it failed on a: . Cisco (*cought* LinkSys) WRT54G loaded with DD-WRT v2.4-sp2 micro (2010/10/09); . SonicWall 2040 with 4.2.1.3; . Thompson SpeedTouch 516; ( I'm looking around for more CPE I could "use", for testing =D ) PS: I'm not promoting the listed vendor, products. Its only a quick test with what I had on my hand during breakfast. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
On Mon, 01 Apr 2013 09:34:31 -0400, Alain Hebert said:
I'm sad to confirm that my spoof test was successful with a:
. SageMCom modem+router, which is used by a big TelCo around my part, for both their residential and commercial ADSL2+, VDSL customers.
You might want to check more carefully exactly what the failure mode was. I'm willing to bet that the router has been configured to assign addresses inside a specific RFC 1918 /24, and will do Something Terrible to spoofed packets in that range, but will figure you know what you're doing and pass them if you source a packet from outside that /24.
On 04/01/13 10:09, Valdis.Kletnieks@vt.edu wrote:
On Mon, 01 Apr 2013 09:34:31 -0400, Alain Hebert said:
I'm sad to confirm that my spoof test was successful with a:
. SageMCom modem+router, which is used by a big TelCo around my part, for both their residential and commercial ADSL2+, VDSL customers.
You might want to check more carefully exactly what the failure mode was. I'm willing to bet that the router has been configured to assign addresses inside a specific RFC 1918 /24, and will do Something Terrible to spoofed packets in that range, but will figure you know what you're doing and pass them if you source a packet from outside that /24.
My test script is very very very basic... but passes. And as per spoofer.csail, which is way more comprehensive in its testing. CPE tested with spoofer this morning. For the SageMCom 2864 with FAST2864_v6740S firmware: Received (at MIT AS3): 1.2.3.4 | x.x.x.x | The IANA unalloced source was successfully received. 6.1.2.3 | x,x,x,x | The spoofed packets were successfully received. There is no ingress or egress source filtering on your network for this IP address. Your host can spoof 16777215 neighboring addresses (within your /8 prefix) For the SpeedTouch 516: Received (at MIT AS3): 1.2.3.4 | x.x.x.x | Source address rewrite. The source address of the probe packets we received differs from the original address. It appears that a Network Address Translation (NAT) device is rewriting your packet headers. 6.1.2.3 | x.x.x.x | <same> 172.16.1.100 | x.x.x.x | <same> Your host can spoof 0 neighboring addresses (within your /32 prefix) ^ the /32 is a bit confusing. PS: This was just a few empirical tests and is in no way, shape, or form, a judgement about the quality of the devices tested. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
----- Original Message -----
From: "Karl Auer" <kauer@biplane.com.au>
On Sun, 2013-03-31 at 22:32 -0400, Jay Ashworth wrote:
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.
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.
D'oh. Of course. Hmmm. That says things about the penetration of NAT routers at consumer eyeball connections vs. directly connected PCs that surprise me. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On 2013-03-31 08:48, Jay Ashworth wrote:
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 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. Jima
Hi, http://spoofer.csail.mit.edu/ is really the best place to certify for BCP38. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 04/01/13 00:36, Jima wrote:
On 2013-03-31 08:48, Jay Ashworth wrote:
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 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.
Jima
participants (12)
-
Alain Hebert -
Dobbins, Roland -
Jason Lixfeld -
Jay Ashworth -
Jima -
Jimmy Hess -
Jon Lewis -
Karl Auer -
Mark Andrews -
Matt Palmer -
Paul Ferguson -
Valdis.Kletnieks＠vt.edu