Wireshark is not capturing https packets. I've tried filtering them by portmap.port == 443 but no https packet is shown, however, http packets are captured fine.
Any suggestions?
portmap refers to the ONC RPC portmapper protocol. That's only used for ONC RPC protocols such as NFS, YP, and the portmapper/rpcbind protocol itself.
HTTP, and HTTP-over-SSL/TLS, i.e. "https", do not use ONC RPC and, in particular, don't use the portmapper. They run atop TCP, so you'd want a display filter such as tcp.port == 443. (If you want a capture filter, so the only traffic you capture is traffic to or from port 443, port 443 would be the equivalent capture filter.)
Related
I'm capturing traffic with winpcap on a Windows machine that is also a network gateway, so I see packets with src mac, src ip, dst mac, and dst ip which are different from the gateway's mac and ip.
What I'm trying to do is redirect some of those packets to a listening server (for example, redirect all port 80 HTTP packets to a local HTTP server instead of their original destination, something similar to a captive portal).
My idea is to disable IP forwarding on the gateway so packets won't go out, and reinject the captured packets to the interface again with winpcap. However, the listening server ignores these packets.
I researched this issue, and found out that maybe it has something to do with Rx, Tx. Apparently, when you send packets with winpcap, listening for those packets on the same interface won't work because listening is on the Rx channel and sending is on the Tx channel.
Does anyone know any workaround for this issue?
I installed Wireshark on macOS High Sierra and captured some network trafic while making HTTP calls to a local server using CURL.
The traffic captured in wireshark only showed TCP packets. When looking at the data whitin the TCP packets I could see the HTTP packets, but these were not recognized by Wireshark as the packet protocol.
Any way to make it properly parse the HTTP packets?
Here's an example capture:
One guess I had was that Wireshark only recognises a packet as HTTP if it's on port 80. If this is so, is there any way to change this setting?
P.S. No HTTPS involved here, just plane old HTTP from a client to a REST API.
Ok, figured out the issue.
My server was exposed on port 5000 (which is the default Flask port).
Turns out that port 5000 is conventionally used for IPA packets, which is a GSM over IP protocol. Wireshark aparently used the port number to determine the type of packet, and so it misclasified it as an IPA packet.
Once I moved my server to another port (e.g. 5001) - the problem was gone.
P.S. See https://osqa-ask.wireshark.org/questions/9240/data-which-has-been-sent-over-tcpip-has-been-recognized-by-wireshark-as-ipa-protocol for more details.
To supplement #MartanRubin's answer, it's also possible to indicate to WireShark that port 5000 is not GSM over IP. In Edit → Preferences → Protocols → GSM over IP remove port 5000 from the "TCP port(s)" field:
To persist the preference you also need to add 5000 to HTTP protocol "TCP port(s)" field. Then they survive restart (tested in a custom profile). Note however, that when you open GSM over IP protocol's preferences, 5000 is still there, but doesn't have effect. But when I save it (click OK button), my /home/user/.config/wireshark/profiles/CustomProfile/decode_as_entries gets messed up again, and I need to repeat the process on both protocol's "TCP port(s)" field. A counter-intuitive UI, I would say.
Specifically, I have a Windows server (Windows 7), but the netstat -an command only shows whether ports are TCP or UDP. I thought these were the only kinds of ports, but node.js seems to distinguish between HTTP ports and TCP ports (example at bottom of linked page). I'm currently using node.js in a program that will run on my server, and it opens HTTP ports by default. These appear as TCP ports under netstat -an.
Is there a command line trick for distinguishing whether an open port on this server is HTTP or TCP? I make requests to my Information Technology office about ports that I need on this server, and they need to know whether these ports will be TCP, UDP, etc.
If necessary to use a remote client, I have a Mac that can do the job.
HTTP is an application protocol. Its definition presumes an underlying and reliable transport layer protocol. The transmission Control Protocol is commonly used. However HTTP can use unreliable protocols too (example SSDP).
Now to answer to your question:
netstat -lt : List TCP Listening Ports
netstat -lu : List UDP Listening Ports
If you want to know wether a TCP Port is running HTTP or not, you can check the standard port on HTTP (grep :80). The standard HTTP port is 80. The standard HTTPS port is 443.
All HTTP traffic is transmitted over TCP Ports. I think what may be causing some confusion is that the first node.js example uses the http module and the second example uses the net module.
The http module is built on top of the net module (which handles the TCP layer underlying HTTP).
Refer to: nodejs - net or http module
EDIT:
Only one process can bind to a port. If you're having difficulties connecting, shut down any other applications that may be using the same port, such as your Java Hello World server. Run netstat -an to make sure you don't see the port listed that you're trying to listen on in you node.js TCP server (port 1337) in the example. If nothing is listening on the port, fire up your node.js TCP server and run netstat -an again to make sure it's actually listening on the intended port.
Another suggestion - temporarily turn off the software firewall then use the telnet client on the local server to attempt to connect to the port using the command telnet 127.0.0.1 1337 (replace 1337 with your port) from the command prompt. This will eliminate any network devices such as firewalls between the client (telnet in this case) and the server. If the screen goes blank, you've connected. If you get the message Could not open connection to the host, on port then it's still not listening on the TCP Port. If you can connect locally from Telnet but you cannot connect remotely then there is something blocking your connection.
I use Charles Web Debugging Proxy to watch traffic on ports 80 / 443 for HTTP and HTTPS requests. With Mac OS X, what program can I use to watch traffic on port 389 / 636 for ldap:// and ldaps://? I'm interested in seeing the actual requests / responses, partially to see how secure they are and what the differences are, and partially just because I'm curious as to what the requests look like.
As noted, Wireshark or tcpdump. You will not be able to judge the security of the requests and responses, because you must view the unsecured connection traffic. If it were encrypted, you would not be available to view the traffic unencrypted. SSL or StartTLS (as an extended operation) should be used to secure LDAP traffic. For more information about the LDAP message envelope, see RFC4511.
You can use Mac OS X's built in tcpdump command, I believe you want a call similar to sudo tcpdump -i en0 port 389,636, though there are other flags on the man page to print out the actual request data (try man tcpdump)
You can use Wireshark.
tcpdump -n not port ssh and port 389 and not broadcast and not multicast
How to capture only incoming TCP streams in WireShark?
(I would like to capture only HTTP connections to my web server, not any outgoing HTTP connections from applications.)
Based on my test,
1. You can use this capture filter for the WireShark that running on the server which you want monitor incoming packets:
dst host 10.58.123.456 and dst port 8080
And you can use following result filter to view traffic comes from certain client:
ip.src_host == 10.78.123.456
Use a filter like (ip dst host 192.168.0.1 and tcp dst port 80) or (ip src host 192.168.0.1 and tcp src port 80).