No Title

February 3, 2008 4:12 PM

I am a computer illiterate person trying to understand the information from Wireshark. Help!

I have recently decided to beef up the security on my laptop. I have learned quite a few things so I am not completely clueless... until it comes to Wireshark. I have it installed on a Win XP HE running on a wireless LAN. I bridged my Firewire and and wireless NIC together and am using the bridge as the Capture Interface. It's running in promiscuous mode reading packets like crazy, but I have no idea what the actual readouts mean or how to relate that to security. I understand wireshark is for traffic analysis and by no means a security device. If it helps I installed it as a recommendation to see what "funny business"my Firefox extensions might be causing. The color coding of the program is marginally helpful. I see a few red readouts. Examples:

TCP http > nsjtp-data [RST, ACK] Seq=262 Ack=345 Win=0 Len=0

TCP http > saiseh [RST, ACK] Seq=734626 Ack=31207 Win=0 Len=0

TCP http > isis-ambc [RST, ACK] Seq=711639 Ack=31206 Win=0 Len=0

The source is some strange IP address and the destinations are my computer. They are lit in red and they are not the only ones. What does this info mean? What should I do? Any reference with a translation for us lay people would be greatly appreciated.

posted by Brandon1600 to technology (6 comments total)

Do you have the destination IPs? You can tracert the IP address and you'll see what it resolves to.

What you revealed isnt much. The items like nsjtp-data are the names of the ports. Youre better off googling those names or changing the app to reveal the port numbers instead of the names.
posted by damn dirty ape at 4:49 PM on February 3, 2008

OK. The first thing is: don't panic! Wireshark will help you learn the basics of TCP/IP networking fairly quickly, but you will need to allocate some time to learn about it. There are TCP/IP tutorials all over the place. As ever, w3schools is well worth a visit.

It looks like your Wireshark installation is configured to highlight the last packet in a closing TCP connection in red.

Try right-clicking on one of those packets and selecting "Follow TCP stream". For TCP connections carrying HTTP, that will give you the entire conversation between your computer and the remote one dumped as text.

On a switched Ethernet, which most are these days, there's usually no particular virtue in turning on Promiscuous Mode, since the only packets arriving at your computer will be ones that your local switch is sending to it, and the switch will only send packets that match your computer's own MAC address anyway. Promiscuous Mode is more useful in conjunction with a managed switch that can be persuaded to spit all the passing traffic out through a monitoring port.

When faced with obscure service names like nsjtp-data, Google is your first port of call.

Welcome to the high priesthood, former lay person :)
posted by flabdablet at 4:55 PM on February 3, 2008 [3 favorites has favorites]

Looks like a portscan from the source. nsjtp-data is port 1688, saiseh is port 1644, isis-ambc is port 1643; so if these packets are in order, something is scanning down the port range looking for open ports (probably to exploit).

You could block the source IP if you want to clean up the capture, but you'd be better off making sure that you have a firewall in place that blocks all incoming packets if they're not part of an existing stream, or unless you explicitly enable a specific service to receive packets from random, unknown hosts.

At this point, everyone should have such a firewall protecting them. I saw a statistic somewhere which stated that your average unpatched windows system will be infected within 3 minutes of being attached to the internet if not protected by a firewall (sorry, can't find a ref -- feel free to discount this assertion if you like, but the fact remains that connecting a system without ensuring that it's protected first is crazy)
posted by 5MeoCMP at 4:59 PM on February 3, 2008

Looks like a portscan from the source. nsjtp-data is port 1688, saiseh is port 1644, isis-ambc is port 1643

Nope, looks more like local dynamically allocated port numbers; endpoints for outgoing HTTP requests. XP seems to use 1024-5000 by default. Vista (and BSD's, OS X, probably Linux) uses 49152-65535, probably to avoid intersecting with services which might like to use those ports.

This article explains how to change it if desired.
posted by Freaky at 5:39 PM on February 3, 2008

What Freaky said, but more generally, only one half of the port pair is probably going to be accurately identified as a service, and if you're not on the server, it'll be the far end. Wireshark happily reports standard service names for well-known ports anyhow, but if it's the near end of a connection for which you're the client: ignore the service name.
posted by mendel at 9:01 PM on February 3, 2008

Just to amplify that a bit, here are the first few things I ever learned about TCP/IP.

First: Anything capable of TCP/IP connections is called a host.

Second: an IP address does not, in general, identify a host. It identifies a network interface on that host. Remember: Hosts don't have IP addresses. Interfaces have IP addresses.

If you have a single host with several network interfaces, each one of those will (in general) have its own IP address. In some cases, it makes sense for all of a single host's interfaces to be given the same address (for example, I do this on my laptop: the wireless LAN port and the Ethernet port are both assigned 192.168.119.1) but this is not a general requirement.

Third: TCP/IP connections are made between interfaces, not necessarily between hosts. It's perfectly possible for a given host to talk to itself via TCP/IP. In fact, it's even possible for a given interface to talk to itself via TCP/IP.

There is a loopback interface available on every host, and it's always accessible via the reserved TCP/IP address 127.0.0.1 (actually any address in the range 127.0.0.1 through 127.255.255.255 will do; 127.0.0.1 is the one conventionally used). The loopback interface is often used to allow programs running on a given host to make TCP/IP connections to services running on that same host in exactly the same way as would be done for services running on some other host.

Fourth: there is a 16-bit port number associated with each end of every TCP/IP connection. You can uniquely identify a given TCP/IP connection with four numbers: the source IP address, the source port number, the destination IP address, and the destination port number.

Fifth: TCP-accessible services running on a host will bind to a particular interface and port number. That means that incoming connection requests to that interface's IP address, bearing that port number, will succeed.

Multiple connections can share a given IP address and port number, as long as they do so only at one end. For example: every connection that anybody makes to the Metafilter server is going to involve port 80 and IP address 74.53.68.130, and these numbers will show up as the destination IP and port for all packets going to Metafilter, and the source IP and port for all packets coming from Metafilter. Connecting to a given port doesn't "use it up".

When host Alice initiates a TCP connection to host Bob, she sets the source IP address on the outgoing connection request packet to match the interface the connection request is going out on; sets the source port number to some arbitrary number; and sets the destination port number to the well-known port number the service she wants will be bound to (e.g. port 80 for HTTP requests).

The only restriction on the source port number is that it must be one that is not already in use for an existing connection from the same source IP to the same destination IP and destination port. Different systems will have different policies for choosing source port numbers, as Freaky mentioned.

Connection request packets go out with only the SYN flag set, and you'll see that in Wireshark.

Bob will reply to that connection request with a packet whose destination IP address and port number match the source IP and port in the initial request, whose source IP and port match the destination IP and port in the initial request, and whose SYN and ACK flags are both set.

Finally, Alice will send Bob a third packet with just ACK set. This sequence is generally referred to as the three-way handshake.

If you set Wireshark up to show you only the traffic involving one particular external host (put ip.addr == ip.addr.goes.here in the Filter box and click Apply) and visit that host with your web browser, you will easily see the three-way handshake happening.

Subsequent packets that form part of that connection will use the same source and destination IP addresses and port numbers as those used during the three-way handshake.

Freaky's point is that because Alice's source port numbers are essentially arbitrary, and because Windows has a tendency to use well-known port numbers when it's allocating source port numbers, Wireshark might mislead you about which service is in use. If you see two well-known ports identified in a given packet, you can be pretty sure this is what's going on. Check the three-way handshake at the start of the connection to get a better idea. After right-clicking on a given TCP packet, selecting Follow TCP Stream, and closing the stream dump window, you will find that the Filter is set up to select all the packets in that stream, and the three-way handshake will be right at the top).

Disconnecting TCP connections cleanly involves another little dance using the FIN and ACK flags, that I'll let you have the pleasure of figuring out yourself. Use filtering as before to limit distractions.

Finally, a TCP connection can be aborted at any time, from either end, using a packet containing the RST flag. Those will be the ones that Wireshark is showing you in red.

There is much more to TCP than this, and it's all worth learning (TCP is actually a really interesting mixture of elegance, practicality and design flaws). But these basics should get you going.
posted by flabdablet at 4:06 PM on February 4, 2008