[HOWTO] ShowEQ with a switch

[linuXfreak]

Hi @all,
I managed to get ShowEQ to work with a windows box, a linux box and a router. You do not need a hub if you use some creative networking.

Let's say the IP of the windows box is 192.168.0.3, the IP of the linux box 192.168.0.2 and the IP of the router 192.168.0.1.
Normally, the standard gateway of all boxes is set to the router, e.g. 192.168.0.1 . Now, to use ShowEQ we need to get all packets through the linux box. The key to doing this is to set up the linux box as a router too.
The packets are sent over the linux box to the router, over the router to the internet.
Only "problem" is that the packets are NATed twice, but I use this method and do not have any problems, latency is fine too.

Now, how to do this:

I'll say that the interface of the linux box is eth0.
Type the following at a root prompt:



iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface eth0 -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward


Now, go to the Windows box and change the default gateway from the ip of the router to the ip of the linux box.

If you now do a tcpdump on the linux box, you'll see that everything is routed over the linux box, no matter if you use a switch, hub or router in your network.

[edit]
If you want to make the setup on the linux box permantent, you should add the commands above to /etc/init.local or whatever your distro uses for custom startup commands.

[Cryonic]

Yep, you make the linux box be a router... Think the FAQ points out something similar to this as a possible solution.

[madmatt]

Another solution that in my opinion works better (in the sense that it can be turned on and off with a single command from the linux box) is to use ettercap.
In your case the ettercap command would be:
ettercap -T -i eth0 -M arp /192.168.0.3/ /192.168.0.2/

What ettercap does is 'poisoning' the arp cache of the switch, so that all packets coming/going to the windows machine are redirected to the linux machine first.
As soon as ettercap is killed, the 'poisoning' ceases and the windows machine packets aren't redirected anymore from the switch to the linux machine.

[Circles]

still playing with ettercap myself. I've not had any luck yet. You specify the -T for sniffing, which is a offline mode switch, and -M which doesnt exist. what version of ettercap are you using?

Edit Nevermind, turns out i had an old man page sigh.

ok I found what i needed.

My config is fairly simple. 1 PC, to a router, that is my internet gateway, so i have to use the remote option. the command is as follows:

ettercap -T -M arp:remote /172.16.2.100/ /172.16.2.158/

2.100 is my gateway/router and 2.158 is my EQ computer.

I was able to find a ettercap RPM for fedora core 3, and only had to Yum a single dependancy. (if your using fedora and dont know about yum, i suggest looking it up. Its a great tool for retrieving missing dependancy files)

[Backspace]

Just want to confirm this iptable method works just fine. Thanks for the tip.

[Supjohndog]

I tried the iptables and ettercap on Fedora Core 4 and I can't get internet access when they are enabled yet I can ping/tracert.

[SchwannyT]

I tried the iptables and ettercap on Fedora Core 4 and I can't get internet access when they are enabled yet I can ping/tracert.

What commands are you using? I'm using FC4 on my laptop, a switch and ettercap. It works just fine most of the time. I've tested it with the wireless and the ethernet adapter and both work.

[Supjohndog]

What commands are you using? I'm using FC4 on my laptop, a switch and ettercap. It works just fine most of the time. I've tested it with the wireless and the ethernet adapter and both work.
ettercap -T -M arp:remote /192.168.1.1/ /192.168.1.138/

.1 router and .138 eq machine.

I can see the packets fly by in ettercap but then the internet doesn't work on the eq machine. The eq machine uses wireless.

I can get it to work using wired and an old 10mb hub but I would like to avoid the cables.

[gsosure]

I've tried using ettercap on my wireless laptop but it will only let me surf but i can't see the EQ machine. I'm not sure if there are settings inside of seq i need to change or what i'm missing but as far as i could tell it should be working.. any idea?

[SchwannyT]

I've tried using ettercap on my wireless laptop but it will only let me surf but i can't see the EQ machine. I'm not sure if there are settings inside of seq i need to change or what i'm missing but as far as i could tell it should be working.. any idea?

Just make sure that seq is watching the same interface that you are using to sniff the packets. Easiest is to start seq with "showeq -i <interface>" and you should see the connection info start rolling by in the console as soon as you zone (you wont see anything but the seq startup stuff until then

[gsosure]

yup, I had the ip address reversed like a noob. switched them and boom the info wouldn't stop scrolling. Thanks though.

[avejidah]

arp poisioning(dsniff, etercap, nemesis.. whatever you use) works but you will loose a lot of packets, and eventually it is my experience(I've used showeq with arp poisioning on debian, freebsd, fedora core 4 and redhat 9 all with the same result) that you will no longer get spawn updates. If you pay attention to the traffic in your packet sniffer, you will notice that when your router(or another computer on your network) makes an arp broadcast specifing their MAC and IP address, that your arp cache is reverted to it's prepoisioned state temporarily(arp -a to check for yourself), therefor causing you to loose packets. You can use a packet sniffer on the linux box and another on the windows box(I use tcpdump and tethereal) to verify this for yourself. The windows box will transmit almost 20% more packets than the linux box recieves. Also with arp poisioning, if the arp cache is not set back to it's origional state(i.e. if you just kill ettercap) then you will loose connectivity for a while(which is just plain annoying, especially if you have a bunch of people on your network), either until the arp cache naturally restores itself, you reset your router, or reset the arp cache with a packet injection tool like nemesis. Also, arp poisioning isn't going to work if your network uses static arp(if your network is administered than arp is probably static). Therefor the better solution is using the linux box as the router. Not only that, it actually saves you a step(you dont have to install an arp poisioner). The reason that ettercap isn't working for some of you, however, is because you don't have routing enabled. You need to do this

sysctl -w net.ipv4.ip_forward=1

or

echo 1 > /proc/sys/net/ipv4/ip_forward

which does the same thing

and if you can ping and traceroute, but other stuff isn't working(like dns and file sharing), it's because you are not masquerading traffic(as stated in another post).

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

If you have done this much, might as well make the linux box a router(it doesn't require a second NIC). If your router is 192.168.1.1 then type this in the linux box, along with the above commands.

ifconfig eth0 192.168.1.2
route add default gw 192.168.1.1

then set the windows box's default gateway to 192.168.1.2 in your network connections.

you may also want to edit /etc/resolv.conf so that your linux box can resolve domain names(DNS). Make /etc/resolv.conf look like this.

search localdomain
nameserver 192.168.1.1

[datadog]

i nominate this for post of the month!

Good stuff Avejidah!

[SchwannyT]

Hey does anyone know is wireless traffic "switched"? I mean can any wireless device that can connect to a network listen to all the wireless traffic? (Like a wired connection over a hub). I'm just wondering because I'm going to be using 2 wireless connected computers, one for eq and the other for showeq and was wondering if I'd even need to arp poison or route the traffic. Anyone know for sure?

[Cryonic]

Wireless isn't switched, but most wireless cards do not allow them to enter promiscuous mode. So you can't sniff with them.

[eqd00d]

Type the following at a root prompt:


iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface eth0 -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward

Now, go to the Windows box and change the default gateway from the ip of the router to the ip of the linux box.

If you now do a tcpdump on the linux box, you'll see that everything is routed over the linux box, no matter if you use a switch, hub or router in your network.sah-WEEET

did this exactly, it worked perfectly. Plus now I've got a free router.


Sorta.

;)

[avejidah]

That's the same stuff i posted just stated differently. --table rather than -t, and echo 1 > /proc/sys/net/ipv4/ip_forward rather than sysctl -w net.ipv4.ip_forward=1. iptables has it's FORWARD chain set to ACCEPT by default, that's why I didn't mention it. I figured that if your iptables FORWARD chain's policy is not ACCEPT, then you changed it and hence know how to use iptables =). iptables -P FORWARD ACCEPT will set iptables FORWARD chain's policy to ACCEPT. With wireless, yes any other wireless device can see all traffic broadcast by other wireless devices(nodes and access points), so long as you can go into promisquis mode(as stated previously by d man, Cryonic). So no you wont need to arp poision or route, just need a card that can handle it. I reccommend the Aironet 350 or the Linksys WPC11(version 3 and prior use the prism chipset which works well in linux, can enter rf monitor mode, and can channel hop. After version 3 it uses a belkin chipset, which is non linux compatible, so make sure you check the version if you use a linksys.). I have one of each card and I have tested both with showeq running on debian sarge kernel 2.6, both work well but the Cisco is of course better because of how many options it has(like changing the MAC address). Kismet maintains a descent list of compatible wifi cards. If it is compatible with kismet, you should not have a problem with showeq. Check the list here http://www.kismetwireless.net/documentation.shtml , under section 12. Capture Sources