Can you use ARP-Poisoning (spoofing) to apply simu

2019-09-20 03:26发布

问题:

We are looking at ways of creating a network effects server. By this I mean a central server that will inspect all the packets on the network and apply logic (drop, delay, alter, etc) based on factors external to the actual network such as weather and line-of-sight.

This is all to do with running simulations of multiple real-world entities: a physical node in the network would represent a 3D moving entity in the 3D virtual world. As I mentioned, the effects would be calculated on line-of-sight, distance, interference, etc between the "virtual-world position" of the nodes.

I am aware of other tools that let you do these kind of effects (such as OPNET, which we might use as part of the solution), but they typically require you to route the data directly to them for processing. They also don't handle either UDP or TCP.

I need a way to transparently run our server and apply the effects without changing any existing software (and some can't be changed, anyway) for both UDP and TCP.

To that extent, we were thinking of using ARP-poisoning (or spoofing, whichever you prefer to call it), to force all the traffic through one (or potentially multiple for load-balancing) of these servers to perform the packet shaping.

Is this a feasible approach? (don't want to spend weeks developing before realizing that there are too many obstacles or that it is flat-out impossible)

If it is feasible, is RFC826 (plus 5227 and 5494) the latest document on ARP? Is there a better document out there?

Would this work when some of the network nodes are Virtual Machines (they might be bridged or NAT'ed)?

Are there any libraries that let you do this in C#?

(We are open to the language we use, but probably prefer C# or Qt-based solutions)

回答1:

Technically you can use ARP poisoning to do this, however I really don't think I would recommend it. I really don't understand why you're trying to do this, but from the sounds of it you're looking to similate the types of packet loss / corruption that could be caused by RF equipment.

First off, you mentioned C#, which really isn't the language for doing this, the low level networking is too far removed. I think C# does provide a raw socket class, but if you try to emulate TCP/IP and UDP and spoof addresses not belong to you're host, it actually drops you're packets. There might be a way to stop this, but you would have to research the .Net Raw Socket.

You can use WinPcap with a c# wrapper as well. But it's still not a native implementation and may suffer performance penalties. There is a C# wrapper for WinPcap which I have used called SharpPcap, however some parts aren't well implemented and I had to modify it for what I needed. I have done some simple tests of capturing traffic at 300Mbps, but that hasn't including any protocol analysis or any injection of the packets back onto the network. This can also be used for putting the packets back onto the network, but again in the past this was reputably low performance. Common perception amoung my networking peers is that this type of inspection cannot be done without hardware assist into the Gbps speeds.

I see you noted that you control the router and the lab. I don't know if Cisco has a minimum requirements for this feature, but you can point a static route to an interface. So if you hang you're intercept server off one port of the router and put routes in for every host to go to you're intercept server, it would feasibly receive all the traffic being routed through the router. You do this by defining an interface as you're next hop instead of an IP address.

*Please note Bob McCormick's note that it will only affect hosts on different subnets, however there is an easy cheat, on each host (if assigned static IP addresses) put the subnet mask to be /32 (ie. 255.255.255.255). This will essentially force the host to send all it frames to be routed by the router, since it is no longer aware of any other users on the same network as itself.

The last caveat is I have no idea if this will work in a virtual machine. I think it will if you use the one type of network interface in vmware, but I have not tried it, and have no idea about the other virtual machine providers.

However, if you are doing this level of work, I would suggest that again you look at using linux for the host you're sending you're traffic too, and maybe the tool Bob McCormick recommended. However, in linux i'm sure there are a great number of tools that can be set up to simulate these sorts of events you're looking for.



回答2:

I'm not an expert on ARP Poisoning, but I believe that to achieve its effects reliably and consistently you would need the consent of the router. I don't mean consent in terms of legalities, but consent in that the router will actually set you up as the middle-man for all devices on the network.

Is that a possibility?

Edit: Since you control the network, I don't think you need ARP Poisoning at all. I'm not sure what your topography looks like, but for a small/medium setup I would switch from a CISCO or equivalent device and investigate running a linux box as a router. Then whatever scripts and such as necessary to drop/delay/alter packets as needed. The Linux-instead-of-Cisco decision might be a little touchy, I'm not an expert but for a small lab it shouldn't be any sort of problem.

I personally use shorewall (a frontend to iptables) to segment my network and drop/reject/allow packets between segments. Hooking it up to use scripts controlled by external factors would be a lot of iptables work to add and remove rules dynamically, but certainly doable.

Disclaimer: I've never worked with Cisco devices, so I don't know what advanced functions they're capable of. Perhaps they are capable of running advanced logic like this, if so, so much the better - I was just assuming they weren't.



回答3:

Spoofing is never going to be reliable. It's basically a race between you and the legitimate owner of the IP address you're spoofing.

Note that any configurations that involves using a router, like the suggestion to use a linux router, etc., will only allow you to affect traffic between hosts that are on different subnets.

If that works for you, may I suggest that you begin with the Netem functionality (http://www.linuxfoundation.org/en/Net:Netem) in the Linux kernel? Netem will allow you to control bandwidth, delay, jitter, packet re-ordering, etc. for any packets forwarded by the Linux kernel. I've used it a number of times to simulate WAN characteristics between Cisco routers for testing QOS configurations.