Tag Info

Hot answers tagged

39

If you have a recent enough kernel and version of iptables you can use the TRACE target (Seems to be builtin on at least Debian 5.0). You should set the conditions of your trace to be as specific as possible and disable any TRACE rules when you are not debugging because it does spew a lot of information to the logs. TRACE This target marks packes so ...


20

If you go to Edit -> Preferences -> Protocols -> HTTP, you should find a list of ports that are considered to be HTTP. Add port 9191 to that list. I believe you have to re-start Wireshark and re-open your capture file or re-start your capture for this to take effect. This is on the Windows version 1.0.3; it might be slightly different on other platforms. ...


16

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'?


15

In terms of analysis, there's nothing wrong with Wireshark. In fact, many enterprise products make use of Wireshark's code. I think where things change are how captures are done in larger environments. Whereas in smaller shops, if you need to run packet captures, a laptop running Wireshark is fine. However, once you get to larger environments with higher ...


10

There isn't any that I know of, but it theoretically shouldn't be hard to get something similar. Strace can be used to intercept networking syscalls. # strace -f -e trace=network -s 10000 /usr/bin/command arguments This will give you information about the data sent between the kernel and the process. The output of strace isn't exactly what you'd want. ...


10

The DF flag instructs routers who would normally fragment the packet due to it being too large for a link's MTU (and potentially deliver it out of order due to that fragmentation) to instead drop the packet and return an ICMP Fragmentation Needed packet, allowing the sending host to account for the lower MTU on the path to the destination host. This process ...


7

Microsoft Pro Support will often request that you install Netmon on a production server to help track down problems. If MSFT themselves want you to use a packet capture utility (in this case, Netmon) on a production server then that's a good indication that it's okay. (I suppose there's at least a few logical fallacies in that statement, but it sounded good ...


7

Open Edit→Find Packet. Under Find select String and under Search In select Packet list.


7

You could use iptables. If you're not already using it, you can use an open Accept configuration, but have a rule in place to do the counting. For example, on RHEL your /etc/sysconfig/iptables file could look something like: *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A FORWARD -j INPUT -A INPUT -s 10.10.1.1 -p tcp -m tcp ...


7

Sure - any network can be sniffed, as long as the sniffer can be connected in the right place. Communications between the phone and the cell antenna are encypted, though, so without some specialized equipment and processes, data is relatively safe on that path. After getting decrypted at the cell antenna site, though, it could be sniffed at one of hundreds ...


6

Tracedump Tracedump is a single application IP packet sniffer, which captures all TCP and UDP packets of a single Linux process. Download and description here: http://mutrics.iitis.pl/tracedump


6

I can't think of a direct solution, but I can think of a round about way of tracking a packet. Log each rule with a log prefix directive (--log-prefix "Rule 34") Generate a test packet or packet stream with scapy and set the TOS field to something unique grep the log file output for that TOS setting and see which rules logged it.


6

UDP is a stateless protocol - so, no states. To see what's listening for UDP: netstat -lnpu


5

That's because it's only set up to decode it if one of the sides of the conversation is on port 9191. You need to set it so it reads, "TCP Both". That way it'll decode TCP/9191 traffic as HTTP if the source port is 9191 or if the destination port is 9191.


5

If it is an internal box, then there should be a server acting as his gateway to the internet. Set up wireshark to monitor the traffic on this box, with a rule set for only his ip address. Alternatively, if you don't have a central node to watch across, set up ettercap and start an arp poisoning. His machine will silently send traffic to you, which you ...


5

You cannot decipher HTTPS traffic unless you do one of the following: Have the private key Do a Man-In-The-Middle attack where you intercept the SSL request, pretend to be the end client, decrypt it, inspect it, and then re-encrypt the data with your own root certificate and send it on to your end-client that trusts your root certificate. What you can ...


4

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 ...


4

Three answers on one post: 1) Debug by script: #!/bin/bash debug() { if [ -n "$debug" ]; then $@ || echo -e "The command which launched the error:\n$@" else $@ fi } debug=1 IPTABLES="debug /sbin/iptables" $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP .... 2) Debug by syslog From this website ...


3

This behaviour is not related to iPhone exclusively. According to RFC 3171, the IP 224.0.0.251 is used for Multicast DNS. The Multicast DNS feature of Bonjour technology allows devices on a local network to connect to each other by name without a separate DNS server. If you want to detect particular devices on your network, you should use nmap and remote OS ...


3

IMHO, there's no inherent risk or harm in running a packet capture program on a production server. In many cases, the problem is such that you need to run it on the "source" server to determine the cause of the problem.


3

These days it is almost guaranteed that you are in a switched network environment which also sounds like the condition you describe. You need to modify the switch to mirror traffic on the source or destination port to the port your machine is connected to. This will allow you to see the traffic you are looking for. If you have a typical consumer switch ...


3

sysadmin1138 and James F's responses are both correct. James' response is probably "more correct" in this case since changes to the HTTP protocol preferences are sticky between runs of Wireshark. In version 1.2.0 and above, you can quickly jump to protocol prefs by right-clicking on items in the packet detail (middle) pane. (Disclosure: I'm the lead ...


3

Learn to use filter expressions. Whilst this won't do the fancy trace stuff that you are asking for. It will allow you to remove nearly all of the "confusing stuff like IRC" from the capture. Additionally it's very useful to know the filter syntax for quick reference in the future.


3

Try Wireshark -- the command will be tshark tshark allows you to select filters on the traffic captured from an interface use other utilities like the debian lsof to identify the kind of communication done by your application of interest. Or, Do you really just want LSOF? I don't think there is a tool that will dynamically keep filtering for all ...


3

(Disclosure: My name is at the top of Wireshark's list of authors.) Wireshark's security record is one of the very few aspects of the project that I've been unhappy with. The good news is that we have a talented team of developers and a solid architecture. One of the reasons you hear about Wireshark's security is that we actively look for flaws and report ...


3

I don't use this stuff nearly as much as I used to, but I always liked Microsoft Network Monitor when I needed a free protocol analyzer to track down a problem. http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f


3

get windows version of tcpdump and analyze traces later with anything [ including wireshark ] on separate desktop box. or use network switch with port mirroring and attach linux [ or - in worst case - virtual machine with linux and bridging to separate ethernet interface ] and perform all sniffing on it.


3

Hmmm... hadn't heard of Smokeping. I use something pretty similar to it (almost identical), though looks like MTR has more field categories for Packet delivery and Jitter statistics.


3

There is also a tool called 'iftop' which displays bandwidth usage on an interface by host. I think iftop can do what you described but normally its interface is something like 'top'. So for your example, I think that you can just create config file to provide your filter-code. So here is my filter-code in my config file. $ cat /tmp/conf filter-code: port ...



Only top voted, non community-wiki answers of a minimum length are eligible