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
Related
I'm attempting to write a script to connect to a DLNA audio renderer.
There are a few articles on the web giving information on how to do this using UDP and curl, however in my particular scenario I'm having some difficulties.
The first step is to send a UDP multicast announcement over the network to discover DLNA devices on the network.
The message sent to discover devices is:
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MX: 5
Man: "ssdp:discover"
ST: urn:schemas-upnp-org:device:MediaRenderer:1
All lines in this message sent over UDP should have crlf line endings and the last line should have an extra crlf according to this article
That all seems fine. And if the message above is in a file devicediscovery.txt supposedly it's possible to use netcat to send out this message:
cat devicediscovery.txt | nc -u -4 239.255.255.250 1900
239.255.255.250:1900 is the multicast address and port over which DLNA devices communicate.
This all seems fine too, however, as is pointed out in the linked article netcat ignores the response from the dlna media renderer because there is a mismatch in IP addresses the message is sent out over the dlna multicast address, though the response comes from the router. The article suggests using tcpdump to capture the response, however I'm on Windows and using Bash on Windows WSL so tcpdump is not available and such a technique would possibly be complicated when developing a script to automate the dlna connection.
Would it be possible to use two seperate instances of netcat? One instance sending the message over the dlna multicast address and the other listening for the response from the router?
I have tried to get this working, however I'm unsure which port netcat should be listening on to hear the incomming response. Is there a standard port that netcat should listen on?
I've tried commands such as: nc -luv 192.168.0.1, however I get an error Servname not supported for ai_socktype. I've tried to remedy this by playing around with /etc/services but had no luck.
What command can I use and how must I configure the system to listen for the response from the search for dlna devices? I'd like to parse the response in a script so that the dlna connection can be automated.
Although you mention issues with DLNA it looks that you are really asking for how to best troubleshoot this.
Network cards don't allow access to incoming traffic unless set in promiscuous mode. Netcat won't be able to do what you need because of this. But, you can use Wireshark to read the traffic on the interface. TCPdump and Wireshark have close ties and almost interchangeable.
https://www.wireshark.org/
I would recommend to use it to troubleshoot further. Ppost the capture (not just a picture) and show where it failed.
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.
I tried to run a simple 1-page site with Flask in Python on port 5000 of my computer 192.168.0.113, which is running Windows 10. On the same computer, I can view the site by using localhost:5000 in a web browser.
I tried to use another computer 192.168.0.134 on the same LAN to view the site. However, 192.168.0.113 never replied with a SYN/ACK packet to the SYN packet from 192.168.0.134, even if the firewall of 192.168.0.113 is completely turned off. This image is the captured flow of the packets:
If I did it reversely (i.e. 192.168.0.134 as the server to host the site, and 192.168.0.113 tried to connect as the client), then 192.168.0.113 is able to connect.
I noted from some previous posts (especially this one) that the problem can be solved by disabling TCP window scaling and TCP timestamps. I checked in netsh of 192.168.0.113 and noted that TCP window scaling had already been disabled and TCP timestamps was normal. I tried to disable both of them, and also tried to disable just one of them. However, all combinations failed and 192.168.0.113 still wonn't sent SYN/ACK packets in response to SYN packets from 192.168.0.134.
How can I get this fixed?
More broadly you are only showing traffic going in one direction in the Wireshark capture.
You probably are not listening on an external IP addresses. The Flask application takes an IP address argument to listen on, if it is localhost or 127.0.0.1 it will not respond to external connection. Set this to 0.0.0.0 to listen on all IP addresses. Verify this by running the command netstat -a -b to see which IP address you application is listening on.
The Flask Quick start page goes through this (see Externally Visible Server)
flask run --host=0.0.0.0
In MDN's proxy example, I have seen that they use 127.0.0.1:65535 as an invalid url
(link to the source):
const allow = "DIRECT";
const deny = "PROXY 127.0.0.1:65535";
...
function FindProxyForURL(url, host) {
if (blockedHosts.indexOf(host) != -1) {
browser.runtime.sendMessage(`Proxy-blocker: blocked ${url}`);
return deny;
}
return allow;
}
Is there anything special about port 65535? Is it safe to assume that no process will ever listen to that port?
In the documentation of Proxy Auto-Configuration (PAC) files, I did not see a straightforward way to block requests otherwise. For instance, there is DIRECT, PROXY, SOCKS but no REJECT or DENY. I assume that PROXY 127.0.0.1:65535 is the official way to deny requests.
Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?
Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?
No, it's not safe.
It's just the very last port on the local machine. I'm perfectly able to open it without any special privileges and send data to it.
They are simply using it as a valid address but a port that's unlikely to be used. Not the best solution, but probably good enough for example code.
There's no special stipulation and 65535 a valid port for a proxy. If you just happen to run a valid proxy there the example will fail to block.
Normally "9" is used as the default port for "discard service". 65535 is nothing special but the biggest possible port number. I assume they use it because they believe no one will listen to the port.
However, this approach is not safe because 1) anyone can write a server socket listening to port 65535; and 2) the port number might be randomly allocated to a client as ephemeral port.
In addition to the other answers, the Discard Protocol (port 9) is the closest equivalent to /dev/null. To quote from the Wikipedia article:
The Discard Protocol is the TCP/UDP equivalent of the Unix filesystem node /dev/null. Such a service is guaranteed to receive what is sent to it and can be used for debugging TCP and/or UDP code requiring a guaranteed reception of payload sent.
On various routers, this TCP or UDP port 9 for the Discard Protocol (or port 7 for the Echo Protocol relaying ICMP datagrams) is also used by default as a proxy to relay Wake-on-LAN (WOL) magic packets from the Internet to hosts on the local network in order to wake up them remotely (these hosts must also have their network adapter configured to accept WOL datagrams and the router must have this proxy setting enabled, and possibly also a configuration of forwarding rules in its embedded firewall to open these ports on the Internet side).
Also blocking requests via the proxy API is not the typical usage. Instead the webRequest API is better suited for blocking requests. There are discussions to change the example.
I assume that explains why there is no explicit support for denying requests in the PAC de facto standard, and why the workarounds of redirecting traffic to unused ports or domains are used.
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.