Hot answers tagged sniffer
There are a few options: sersniff is a simple program to tunnel/sniff between 2 serial ports. Serial line sniffer (slsnif) is a serial port logging utility. It listens to the specified serial port and logs all data going through this port in both directions. Serial to Network Proxy (ser2net) provides a way for a user to connect from a network connection to ...
To complete David's answer, a switch learns who is behind a port by looking at the MAC addresses of packets received on that port. When the switch is powered on, it knows nothing. Once device A sends a packet from port 1 to device B, the switch learns that device A is behind port 1, and sends the packet to all ports. Once device B replies to A from port ...
I use Wireshark on Windows all the time - with a SPAN session or similar, plus cunning use of capture/display filters, you can get it to tell you pretty much anything you need. And you can make pretty graphs for your boss, too. What did you mean by 'security history'?
It is very difficult to detect sniffers, because they work passively. Some sniffers do generate small amounts of traffic and though, so there are some techniques for detecting them. Machines cache ARPs (Address Resolution Protocol). Sending a non-broadcast ARP, a machine in promiscuous mode (a network card that makes the card pass all traffic) will cache ...
Packet sniffing is a passive activity, it's generally not possible to tell if someone is sniffing your network. However, in order for someone on an wired, switched LAN to see traffic that's not destined just to or from their IP (or broadcast to the network/subnet) they need to either have access to a monitored/mirrored port that duplicates all traffic, or ...
What about the old email to staff@? "I just bought a monitoring tool that will tell me who's using up the bandwidth. Here's a link to the paragraph in the employee handbook that explains the policy on internet use. I will be installing it tomorrow. You've been warned. Thanks." Might work, and if not, you've got some suggestions from the nice people here ...
I think Wireshark is pretty much the open/free standard. Is there something you're looking for that it doesn't do?
You're understanding is basically correct. First I'd like to mention that if you know the PSK, or have a copy of the certificate, it's basically game over. Cracking the the session key is cryptographically trivial if you've got that much information. If you don't have the PSK or cert you're left with brute force, as you mentioned. Certificates are just as ...
More expensive switches will offer port mirroring, where they will mirror the traffic of one or more ports to a dedicated monitor port for (among others) problems like yours. But I am not sure at what price class features like that are offered.
We use MRTG (free) http://oss.oetiker.ch/mrtg/ to monitor traffic on our routers and switches. This will only work if you are using managed switches that support SNMP.
What you need if urlsnarf from the dsniff project. It will generate a log with all http request seen on one network interface. A very good tool !
This is a common misunderstanding. Unless it is statically configured, a switch must send every packet over every port that it cannot prove it does not need to send that packet out on. This could mean that a packet only gets sent to the port that contains the destination device. But this cannot always be the case. For example, consider the very first packet ...
Yes, it is possible. There are several ways: Connect your two PCs using a hub. All traffic will be sent to all ports. Use a man-in-the-middle attack program like ethercap. Use port-mirroring feature in a managed switch to forward all traffic from another port. You can use tcpdump or wireshark for packet capturing. I am assuming both hosts are located in ...
I tried to use slsnif, but I found that I got an error: Failed to open a pty: No such file or directory This mailing list item indicates that slsnif only supports the "legacy" pseudo-terminals (/dev/ttyp0 etc) which are probably not used on current Linux kernels. I tried interceptty, and was successful in using it. First I ran it on the port of ...
The (I believe) only way you can sniff all traffic on a switched LAN is with a 'man in the middle' attack. You basicly do ARP poisoning, stealing everyone's packets, reading them and sending them to the right computer afterwards. There are probably multiple tools that can do this, I only know of one: Ettercap can both perform the Mitm attack and detect one ...
Social engineering is the other way to do it. Set up a honeypot root/admin account or some other tempting target, broadcast its password in the clear and watch your logs.
I haven't run into anything free that is better. My work it too cheap to pay for a sniffer when Wireshark is so good at what it does. Yes, it seems Wireshark has a new vuln against a decoder every other day or so, but that kind of thing happens when you're by far the top package in a field like this. Yes, I'd like them to update a bit more often. But the ...
I've done quite a lot of this with wireshark. Sniff the traffic I want with tcpdump, ship it to somewhere I can launch Wireshark, and then view the trace with Wireshark. Tracing the TCP session gives me the request and answer in a nice ASCII form. Works great.
ngrep is very useful for this. Something as simple as ngrep -W byline port 80 would work, but you can filter on the content of the requests too (hence the grep part of the name), and it prints out the packet payload: ngrep -W byline some_string port 80
Basically this boils down to a question: what OSI level are you interested in? If you want to know about what exactly was transmitted, you cannot avoid Wireshark, tcpdump or alike. But if you are interested to learn patterns that appear in your network you have to analyze netflows, packet capture is simply an overkill. And for netflows there are many tools: ...
Like this. tshark -nn -i <interface> -s 0 -w mycapture.pcap <hostname> and port <portnumber> Replace <interface> with the interface name to capture on (e.g., eth0). Replace <hostname> with the name or IP address of the remote host you want to capture packets for. Replace <portnumber> with the port the service is running ...
Assuming you already know how to use filters with tshark, just supply the following display filter: ssl.handshake.type == 1 If you want all ssl traffic, simply put ssl as the filter. You cannot use these directly in the capture filters as the capture filtering mechanism doesn't know if the payload is ssl or not. Alternatively, if you know what port the ...
Packet tracing (what wireshark does) is undetectable, period. It merely reads data already present on the network and hence is entirely passive. nmap is nothing like a sniffer - it is an active network probe that sends and receives packets. The latter could be detected with applications such as snort; the Cisco ASA does not have this capability.
You don't mention what OS you're running on said system, but if it's running Windows you can use Microsoft Network Monitor, which shows the process ID for each "conversation" so it should allow you to focus your analysis. "Filtering" traffic per process ID is as simple as selecting the process in the left pane and viewing it's traffic in the right pane.
You could use iplog but it looks like it is very old (not updated since 2001 according to that web page.) There is also the possibility of using the host firewall to do it; just create a "null" rule that matches every packet and has a target of LOG; you can use GUI tools or iptables command to do this.
If I'm your ISP or hosting company, it's really easy. If I've compromised your ISP or hosting company, it's really easy. If I've compromised your server, I don't even have to sniff the traffic - I own you. Your visitor could also have a virus on his machine. The chinese company could own or have compromised a search engine or ad service that lets them know ...
Try using jpnevulator (debian packaged) or slsniff, from http://slsnif.sourceforge.net/
Install squid (an HTTTP proxy) on the MAC, enable logging, and tell the devices to use the proxy. If you need to see more detail then additionally install wireshark (packetsniffer) on the Mac and tell it to sniff port 80. You don't need to get fancy and install a router or a bridge or set up a transparent (intercept) proxy.
Check out Wireshark.
It looks like some issue about not sniffing from the same source. Different client application? Maybe you are using a client that HTTP analyzer is not connected to/cannot sniff. Different interface? Maybe you are accessing some service via LAN address (192.168.*) and some other via localhost (127.0.0.1)
Only top voted, non community-wiki answers of a minimum length are eligible