Printable View
Short of using a switch with a mirror port is there a good way to split a 100MB ethernet connection for sniffing so you can just sniff whats on that one line? In this case I dont want to do any kind of arp poisoning. I tried to use an old 10MB hub to split the connection but it did not work that well, best I could manage was half duplex. I'm making a new tutorial about Cain and it would help if I could figure it out. Thanks.
I'm not quite sure what you mean by this? Do you mean to monitor it? If this is the case a network tap would be the best idea. A hub works in the same manor except it can generate collisions which cause problems.Quote:
I just googled them, wat out of my price range. But thanks for pointing them out.
I have an idea but I have NO idea if it would work... Could you physically cut the cable, and connect two wires to each of the wires in the original cable, then connect one set back to the original cable, then connect the other to your sniffer computer?
That's my best idea, though I doubt it'd work.
Thanks Grunt, but I tried that, best I could do by splicing wires was a half duplex sniff. Could be I wired it wrong, but I can’t think of a way you can do that without screwing up the transmit and receive lines.
I think you would nead a custom routing table, how you go about that is well beyond me. Ho hum.
Hey Hey,
As far as I can gather, you're attempting a setup like this..
Instead of splicing the wires, which would cause massive amounts of cross talk (removing the shielding and twists from a section of CAT5 is never a good idea)... Why do you just combine them? You're PC will transmit on pins 1 & 2 and receive on pins 3 & 6.. You only need to receive data to sniff.. Combine the cables at the end... it'll be a pain in the ass to slide two of them into a single RJ45 connector.. and will require some fancy work on your part.. but it's what I'd try..Code:Victim PC ----- Switch
Sniffer--/
Step 1: Strip and prepare the ends of two lengths of Cat5 as you normally would.
Step 2: Using your teeth, or small enough wiring strippers, remove the sheathing on the individual copper lines for pins 3 & 6 (White-Green and Green for example), Only do this to one end of each of the lengths of cable.
Step 3: Twice the bare ends together (3 to 3 and 6 to 6).. twist really tight because you're going to have to fit it into the groove of the RJ45 connector...
Step 4: Wire the end of the one cable (2 spliced ends and then 6 ends from one of the 2 lengths).. I'd apply a little electrical tape around this end for safe measure.
Step 5: Wire the opposite ends of both cables as you normally would.
Step 6: Plug the spliced end into the switch, plug the fully wired opposite end into the victim and the partial wired opposite end into the sniffer..
I believe that would work for ya... however, I'm extremely tired.... so who knows..
Good luck and let me know your results.
Peace,
HT
I have built this one in the past with great fun and success..
http://www.snort.org/docs/tap/
It's just a couple bucks.
I think the best you can do is 1/2 until something re-assembles...AFAIK.
Thanks HTRegz, I've tried something like that before but I only could get one side of the date (in other words, not full duplex). I would need someway to isolate the send wires from the receive otherwise it looks like the switch just faults on that port because it sees a loop back problem (I could be misinterpreting what I see).
Thanks ss2chef, it's kind of like what HTRegz was geting at. With the tap and two NICs I could get something like full duplex.
Hey Hey,
I'm not sure what you mean by you could only get one side of the date (assuming data)... If you had the wires melded you would have your send and receive isolated.... and I dont' see a reason why you wouldn't get full duplex.. (you only get half duplex when you're connected to a hub, or a dumb device where you can't always send/recieve at the same time..
I'll see if I can't draw a picture of what I mean..
Peace
HT
[Edit]
Attached Image:
The goal is to make sure that both ends are in the connector and not a splice in the cable... i'm going to create one tomorrow to test it, but I'm pretty sure it should work.
[/Edit]
Hi Irongeek,
The primary purpose of ss2chef's idea is to make a recieve-only tap, so the computer connected to the sniffer would not be able to send traffic, or for that matter any kind of electrical signal the wrong way down the wire. The sniffer box is completely invisible on the network. If the sniffer box has access to the transmit pins on these wires, any signal it sends, whether this IP traffic, hardware negotiation or any kind of electrical signal, would interfere with the signal already on the wire and destroy it. I have tried a setup much like what HTRegz suggested before and encountered this problem.
I have built the snort taps before. I have three of them which I use to sniff traffic. They have the added benefit of making the recieveing computer(s) invisible, since it is not connected to any transmit pins. But yes, the recieved traffic is only half duplex. Each NIC will recieve traffic travelling only in one direction. Merging these two streams, however, is not at all difficult. Iptables is capable of rebuilding these streams with the bonding driver, which is more normally used to increase network bandwidth.
If you have "bonding driver support" enabled as a module in the linux kernel, a bonded interface, which will recieve traffic from eth1 and eth2, can be set up as follows:
I have had some success with this. Any application listening on bond0 will now recieve traffic entering the box both on eth1 and eth2. This is my usual solution when sniffing traffic in this manner. I can see full duplex traffix on bond0, but I am still unable to transmit anything to the network, making it impossible to overwrite the signal with stray electrons.Code:ifconfig bond0 up
fconfig eth1 promisc up
ifconfig eth2 promisc up
ifenslave bond0 eth1
ifenslave bond0 eth2
This should work for you.
<EDIT>
hrm... I don't have ifenslave here, so I guess you might not either. I'll attach the source to save you the trouble of looking for it. It's just a single C source file.
</EDIT>
Correct me if im wrong but cant you just put 2 network cards in your computer and setup network sharing so that it does something like this:
Comp 1 Sniffer WAN
nic---------------------------nic1--nic2------------whatever
then the computer would see all traffic going through it... unless you are looking for it not to hit your computer for whatever reason
Yes, I too am not sure what you are trying to do.
A Hub will be half-duplex, cause collisions, but it is cheep and can be deployed easily. The biggest problem is how it will affect network performance. But it will see BOTH sides of the transmission.
A Tap, as Striek said, will only see one side of the transmission, either coming in OR going out. Combining both can be done in several ways if you want to monitor both sides, say to know requests as well as responses. If you are using a commercial Tap ( which you say you can not afford ) there should be two ports which need to be combined. If you use home made taps you may need two, then combine them. ( not fun ) If you use really expensive Taps, some can, as I understand it, combine them in the hardware, but then again, you can't afford the cheep ones so .....
Again, I don't know what you are trying to capture. I would think it would be better to capture both sides of the transmission then sort through what you need. To do this I would still suggest the hub. Even though a hub may cause collisions, those packets that are not received should be resent . ( it is my understanding that using a hub to connect two Taps is a very bad idea because it can introduce collisions that the monitor doesn't see, and neither do the sender or receiver because for them no collisions occurred. So the monitor can miss packets and never know it because they were never re-sent ) whew.
Again, with the hub, how much performance derogation will there be on your application? You would need to determine your available bandwidth and your bandwidth usage.
The only other alternative I can see is what Spyrus recommended.
Put together a spare computer with duel NICs, and set it up as a Bridge. Monitor ( capture ) all the traffic that passes through. If it is not that fast, put in a third NIC to connect to your computer that will do the Cain stuff.
Hope this helps. ( Hope I made sense! )
Hi Striek. Cain is a Windows only tool so I can't use the Linux solution, but thanks for the information.
Hi Spyrus . I dont think just sharing would work because not all broadcasts and such would be forwarded (since it would be NATed). Bridging might though. See:
http://www.microsoft.com/technet/pro.../xpbrdgnt.mspx
I'll have to try it, thanks.
Thanks, I've tried a hub but for some reason the best I can do with it is seeing half on the connection by hooking the main line in to the uplink, connecting the phone into the port thats tied to it (not sure what to call it) and hooking my sniffer to one of the normal ports on the hub. If I hook it up any other way the phone can't find the server.Quote:
Originally posted here by IKnowNot
A Hub will be half-duplex, cause collisions, but it is cheep and can be deployed easily. The biggest problem is how it will affect network performance. But it will see BOTH sides of the transmission.
Oops. Missed the Cain part.
Windows is capable of interface bonding as well. It is also known as link aggregation. It is mainly used, as I said, to increase bandwidth, however it will accomplish what you need. You would need third-party trunking software installed. Two possibilities are Sun Trunking Software or Nic Express. Sun Trunking Software has a $1000 price tag, so I doubt it will be good for your tutorial. Falconstor does offer a trial version of Nic Express though.
I'm thinking some sort of trunking software would do the trick with a tap. I'm not sure if bridging could do it. You could possible set something up where nic1 and nic2 are both bridged to nic3, but most users would be unable to accomplish this. I'm not even sure if it's possible. That may not work either.
So I have two solutions for you... some kinf of trunking/link aggregation/bonding software, which will allow the traffic to be sniffed in real time, or stream reassembly software which will reassemble a single stream from two capture files.
again I am confused. You have a hub with a phone jack?
Yes, you may need to use the up-link side, or use a crossover cable ( damn, is that the name? I can't remember, I'm way drunk )
But the hub still should show you both sides of the connections.
Just a guess here ... you have DSL? You connect to the DSL modem via ethernet.
You would place the hub between the normally connected computer and the modem, the modem would be connected to the hub either via a crossover cable or “ uplink”
The other computers would connect via the normal ethernet connections.
The only problem I have heard of is when mixing 10, 10/100, and 100 M ethernet cards.
I have heard of some 10/100 hubs that would negotiate differently causing lost data.
If this is your situation make sure all can negotiate to the same speed. You said the hub is 10MB so if all the NICs are either 10MB or 10/100 they SHOULD negotiate to 10MB. Make sure they are all compatible, or force the hardware to do so.
No, NIC1 and NIC2 would form the bridge, have no IP address, NIC3 would have a private address to access the tcpdump files that the box captured.Quote:
I'm not sure if bridging could do it. You could possible set something up where nic1 and nic2 are both bridged to nic3
I have a VOIP phone that hooks to ethernet. It may not be able to negotiate down to 10Mbit.
If you have a laptop with two NICs you can set up a MAC bridge and that works also, better yet you get both sides of the conversation. More details here:
http://www.microsoft.com/technet/community...guy/cg0102.mspx
Just tested it and it works great.
So what you are doing then is putting a laptop between two hosts, bridging the connection and then sniffing traffic on that bridge (or one of its member interfaces)?
The only problem I have had with this is the bridge not learning MAC addresses quickly enough, or keeping addresses of the previous setup in the cache. It would probably be a good idea to cover some method of clearing the bridge cache when switching the location of the laptop.
The only advantage a tap would have over this setup would be a lower latency. For a tutorial though, the bridge setup may be a better idea, depending on the target audience. They are relatively easy to set up with XP.
LOL. Why make life complicated?
http://cgi.ebay.com/ws/eBayISAPI.dll...category=67279
or
http://www.duxcw.com/digest/Reviews/...ats/index.html
:p
Hey Hey,Quote:
Originally posted here by thehorse13
LOL. Why make life complicated?
http://cgi.ebay.com/ws/eBayISAPI.dll...category=67279
or
http://www.duxcw.com/digest/Reviews/...ats/index.html
:p
Will this actually serve the purpose as desired? If you look at the pin-out, the lines are completely seperate, the one plug utilizes lines 4,5,7 and 8... The idea of this actually seems fairly futile and useless, it let's you send two seperate ethernet connections along a single line, all it really seems to do is save you a single cable run (yet requires two of these adapters).... Based on their schematics, you couldn't use them to sniff from one to the other...
Peace,
HT
Hi, Iorngeek I am not sure if this is something your looking for but i think it would work for what you are asking for. What I am talking about is making your own device what you could do it get 3 RJ-45 jacks and what you would do is connect them together side by side (glue works good) then punch down the two end Jacks with a piece of cable and in the center jack only punch down the send or receive wires (meaning if you only want to look at information the node is sending punch down the send or vice versa) then what you could do is plug the wire to your switch into the first jack your computer into the second/middle jack and the switch into the end jack. now you can try and sniff all the traffic you want :cool: . I hope this explanation was good I am kinda in a rush so sorry if it is not post back and i will give a better explanation if needed(which I think is sorry :rolleyes: )
Quote:
Originally posted here by Irongeek
I have a VOIP phone that hooks to ethernet. It may not be able to negotiate down to 10Mbit.
May not or wont? cause if that is your only concern it seems it would easier to test it for 40 seconds and see instead of wasting a bunch of time on crimping/splicing/joining wires
or go the other route
surely a cheap switch that will negotiate 10/100 isnt out of your budget?Code:Internet----Switch-<--IP phone
-----Hub---<---computer one
---computer two
From my limited test it does not seem to work with the 10Mb hub (unless I hook it up as shown in the video), but a 100Mb switch was fine.