A hacker's greatest ability is to edit a packet's header and change the return address to anything but their own. To prevent this we turn to the ISPs. Every ISP knows exactly where each packet from their clients came from. What regularily happens is that ISPs just act as a routers without checking the validity of the return addresses on packets sent to them. Here is the idea: ISPs will stamp the correct address in the header of every packet they receive from their clients. By doing this a hacker can change his or her address on every packet all they like but the ISP will correctly enter their real ip address on the packets. No more spoofing, better internet security and a whole lot less headaches in tracing DoS attackers and every hacker that tries to hide under a fake address.
How to prevent a hacker's greatest boon
- Thread starter Blackhawk2
- Start date
Zach thats a good idea. The one weakness is that a hacker could easily get a list of legitimate ip addresses for the ISP and then fake those addresses.
hahahahahahahahahaa. not going to work that well.
let us say, that I setup a proxy or router, wouldn't every packet now be given the improper reply address?
reply to this and I will see what I can muster up to rebutal you.
let us say, that I setup a proxy or router, wouldn't every packet now be given the improper reply address?
reply to this and I will see what I can muster up to rebutal you.
Hey that's a good idea in my opinion. Instead of stamping a new address, it might be more efficient to just discard the packets in question. What do you think?
Unfortunately, the point at which many DoS attacks originate is a dialup modem. It doesn't take much bandwidth to send a forged directed broadcast to an unprotected LAN on a T1 in BFE. Same thing with these IRC DoS attacks. The originating traffic from the hacker is hard to check because the dialup device is usually too dumb or too busy to worry about inspecting packets. But just because it is hard to do now, doesn't mean it is impossible.
One problem here is that policy-based routing creates latency and jacks up processor utilization on the provider's equipment. There are routers that do wire-speed policy-based routing (Juniper, not Cisco), but they are still a little on the pricey side for most providers. And they are not being implemented on the edge networks yet, just the core.
It's easy to say "This can't be done." If we can figure out a good way to do this, I can personally implement it on over 200,000 dialups nationwide. Any takers?
Unfortunately, the point at which many DoS attacks originate is a dialup modem. It doesn't take much bandwidth to send a forged directed broadcast to an unprotected LAN on a T1 in BFE. Same thing with these IRC DoS attacks. The originating traffic from the hacker is hard to check because the dialup device is usually too dumb or too busy to worry about inspecting packets. But just because it is hard to do now, doesn't mean it is impossible.
One problem here is that policy-based routing creates latency and jacks up processor utilization on the provider's equipment. There are routers that do wire-speed policy-based routing (Juniper, not Cisco), but they are still a little on the pricey side for most providers. And they are not being implemented on the edge networks yet, just the core.
It's easy to say "This can't be done." If we can figure out a good way to do this, I can personally implement it on over 200,000 dialups nationwide. Any takers?
The closet thing I know is using a check call RPF, Reverse Path Forwarding.
Basically what a router will do is DROP a frame if the source address of the frame was received on an interface that is not used to route to that address.
Router gets from from address 172.16.0.10 on interface POS-0. Before delivering the frame router checks route table for network 172.16.0.0 and finds the next hop is out of interface Serial 0/4. Frame dropped.
This is one of the BEST ways to avoid address spoofing. Sure you can still spoof an address but it has to be within the same network as your REAL ip. I could track you down lickety split.
cheers
Basically what a router will do is DROP a frame if the source address of the frame was received on an interface that is not used to route to that address.
Router gets from from address 172.16.0.10 on interface POS-0. Before delivering the frame router checks route table for network 172.16.0.0 and finds the next hop is out of interface Serial 0/4. Frame dropped.
This is one of the BEST ways to avoid address spoofing. Sure you can still spoof an address but it has to be within the same network as your REAL ip. I could track you down lickety split.
cheers
Yes Spidey07, I have seen that with Cisco! Source-routing is the first thing I thought of, but I know you don't want to source-route every packet that comes into your network. At least, my company doesn't. We transit a lot of traffic, as well as peer with several big providers. But if all if the edge providers did something like this, then there wouldn't be a need for source-routing at the core, right? So the next question is: how expensive is RPF in terms of processing, and is this a standards-based or proprietary solution?
Correct, it should definately be performed at the edge. Let the core do what it does best. Believe it or not if you have a CEF enabled router (12000, 7000) it is performed on ASIC and not by processor.
Standards or Proprietary? Don't know.
I forget the specifics of it but do a search on cisco.com on RPF. It was mainly developed in response to DoS attacks.
Heck I'd like to write a program that disables your link layer if you source more than 10 frames a day with spoofed addresses. That would keep'em out. But then again it would also disable poor joe user who accidentally misconfigured his PC/router.
spidey
Standards or Proprietary? Don't know.
I forget the specifics of it but do a search on cisco.com on RPF. It was mainly developed in response to DoS attacks.
Heck I'd like to write a program that disables your link layer if you source more than 10 frames a day with spoofed addresses. That would keep'em out. But then again it would also disable poor joe user who accidentally misconfigured his PC/router.
spidey
Check out section 4. I know for a fact our RAS vendors are not supporting this yet, but I'll make some inquiries.
Cisco AS5300s (and higher) support the Unicast RPF check.
Oh, well. Hey CTR you sound like a very experienced Net professional. Please feel free to E-mail me or put me on you "geek mailing list". Hopefully we can start sharing all those little tidbits of info that make this job easier.
spidey (john_royster@b-f.com)
Oh, well. Hey CTR you sound like a very experienced Net professional. Please feel free to E-mail me or put me on you "geek mailing list". Hopefully we can start sharing all those little tidbits of info that make this job easier.
spidey (john_royster@b-f.com)
Sure thing, I'll shoot you an e-mail later.
And one note on the Cisco RAS: who's still using it? Too expensive and not enough port density. 5800 is dead, btw. But anybody around here who is using the 5300 should speak up!
And one note on the Cisco RAS: who's still using it? Too expensive and not enough port density. 5800 is dead, btw. But anybody around here who is using the 5300 should speak up!
Got four, 192 modems/per in a 2u space.
LOVE IT!!!! Consolodates IP Dial and Voice over IP.
Anyways, back to blackhawks point. I hope the RPF stuff helps you out.
LOVE IT!!!! Consolodates IP Dial and Voice over IP.
Anyways, back to blackhawks point. I hope the RPF stuff helps you out.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 22K
-
News NVIDIA and Intel to Develop AI Infrastructure and Personal Computing Products- Started by poke01
- Replies: 384
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
Facebook
Twitter