Checking for an Open Port
-
I periodically run a "Shields Up" scan using the grc.com website, and I recently noticed port 445 showing as closed instead of "stealth"-seems to happen only when running from a browser on a windows box.
I don't see any reason why this port should be visible at all. There should be no traffic using it. To make sure, I have a floating rule on WAN that blocks a bunch of ports that should never hit the internet (including 445).
I do have a couple of rules to open ports for OpenVPN -- One UDP and One TCP, but when I turn the TCP server off, the TCP port shows as stealth, and the UDP port isn't detected at all.
It is possible that my cable modem (which is in bridge mode) is responsible for this, but I have no way of knowing. For security purposes I consider my cable modem to be hostile/untrustworthy.
I need to make sure that I don't have anything strange/bug on the firewall. Any useful comments/suggestions would be much appreciated.
If you find my post useful, please give it a thumbs up!
pfSense 2.7.2-RELEASE -
@guardian said in Checking for an Open Port:
I don't see any reason why this port should be visible at all. There should be no traffic using it. To make sure, I have a floating rule on WAN that blocks a bunch of ports that should never hit the internet (including 445).
Start inspecting devices bewteen your pfSense and the Internet : your modem.
Also : if possible, don't float.Btw : pfSense is installed with no NAT neither rules on WAN, so the only possible result is :
@guardian said in Checking for an Open Port:
It is possible that my cable modem (which is in bridge mode) is responsible for this, but I have no way of knowing.
Well ... now you know ^^
-
445 smb over tcp port of windows? Why would your modem be doing anything with that?
Its possible your ISP is blocking it and sending back reject which is why its showing closed.. Sniff on pfsense wan when you run your scan... Do you see any traffic on 445 hit pfsense? Do you see pfsense send anything back?
-
Yeah this is 90% your ISP to protect their customers for not having SMB open to the whole world.
-Rico
-
I agree with @johnpoz said , unlikley ISP's hate portscan and if you do more intensive scanning at once, isp will reject for you "indesiderable" traffic.
@guardian , You can see status of your network anytime and anywhere by quick do a look trought some pfSense tools, basically States table and States summary offer a good overview of your system, and you can also check pfTop and pfinfo .
If you look at this example below, you can see active connections, ip address, related port and so on. Finally you can sort table entry as would you like for port number, src addrees, age ... It's simply and effective to do:
-
@guardian said in Checking for an Open Port:
I need to make sure that I don't have anything strange/bug on the firewall. Any useful comments/suggestions would be much appreciated.
Try running Nmap against your WAN port. It will do a port scan and, unlike ShieldsUp, also scans IPv6.
-
So here -- something upstream (my isp most likely) is blocking 445
I use your grc tool and 445 comes back stealth - but I get nothing on pfsense wan.. Packet capture for 445 shows nothing..
I then pick another port 8888 in this case, and it still shows stealth - but pfsense actually sees this traffic, it just drops it - but it sees it..
So possible my cable modem is blocking this, such ports are clearly possible to be blocked inside even a modem. If you could do a query to your modem via snmp you might see something like
SnmpMib = docsDevFilterIpDestPortLow=445
SnmpMib = docsDevFilterIpDestPortHigh=445But it really should not be sending back anything, it should just drop it.. But a sniff on pfsense will tell you if pfsense is seeing it, and then if pfsense or something behind pfsense is answering at all - So if sends back say a RST you would show it as closed vs no answer gets back the so called "stealth"
You say you created a floating rule - did you set that rule a REJECT vs block?
Here now I set a rule to reject 8888, shows closed and you can see pfsense set back a RST
-
@johnpoz @jknott @babiz @rico @gertjan Thanks for taking the time to put together such great info!
I ran the test again with a promiscuous packet capture on WAN, and I saw a SYN for all ports, and one retransmission for all ports, and this time it passed the test. I also noticed (unfortunately I forgot to raise the # of packets and I missed the capture) I was getting port 135 showing up as closed occasionally.
If the cause is upstream, I guess I don't need to worry about it. Should I do any further investigation, or just consider the matter closed?
I'll combine additional questions/replies below:
@johnpoz said in Checking for an Open Port:
So possible my cable modem is blocking this, such ports are clearly possible to be blocked inside even a modem. If you could do a query to your modem via snmp you might see something like
SnmpMib = docsDevFilterIpDestPortLow=445
SnmpMib = docsDevFilterIpDestPortHigh=445Can this be done within pfSense?
You say you created a floating rule - did you set that rule a REJECT vs block?
My rule is set to block
@jknott said in Checking for an Open Port:
Try running Nmap against your WAN port. It will do a port scan and, unlike ShieldsUp, also scans IPv6.
Can I do that with the nmap package within pfsense, or do I need to get some hardware between pfSense and the modem? (If so, what about option? Am I correct in assuming: The address ifconfig shows on em0 in for IP or Hostname, and WAN as Interface and SYN for Scan Method and option -P0)
As for IPv6, I'm currently blocking all IPv6 traffic. I've got to say IPv6 scares the cr*p out of me when it comes to security/firewalling!
@rico said in Checking for an Open Port:
Yeah this is 90% your ISP to protect their customers for not having SMB open to the whole world.
You would hope... I read in a forum somewhere that when Rogers rolled out IPv6, there gateways had no firewalling on IPv6 and anyone with a default Windows Install was sharing their drive shares with the world!
@johnpoz said in Checking for an Open Port:
445 smb over tcp port of windows? Why would your modem be doing anything with that?
It wouldn't surprise me if the did something like that to update the modem--I would certainly hope not, but anything is possible.
@gertjan said in Checking for an Open Port:
Start inspecting devices bewteen your pfSense and the Internet : your modem.
I assume I need some sort of hardware to do that? I'm in a residential setting, so the only thing between pfSense and the modem is an ethernet cable.
Also : if possible, don't float.
Sorry for my noobishness: What does float mean in this context?Btw : pfSense is installed with no NAT neither rules on WAN, so the only possible result is :
What about all the Automatic Rules/Mappings on the Outbound NAT page?
@guardian said in Checking for an Open Port:
It is possible that my cable modem (which is in bridge mode) is responsible for this, but I have no way of knowing.
Well ... now you know ^^
So I assume you are saying that the problem must be upstream.... either in the modem or further upstream.
-
@guardian said in Checking for an Open Port:
Can I do that with the nmap package within pfsense, or do I need to get some hardware between pfSense and the modem? (If so, what about option? Am I correct in assuming: The address ifconfig shows on em0 in for IP or Hostname, and WAN as Interface and SYN for Scan Method and option -P0)
You need to run Nmap from outside the firewall for the rules to affect it. Test against the WAN address. Sometimes it helps to use a cheap router to act as the Internet, for testing purposes.
As for IPv6, I'm currently blocking all IPv6 traffic. I've got to say IPv6 scares the cr*p out of me when it comes to security/firewalling!
Why? The same rules apply. You configure the rules to allow only the traffic you want to the addresses you want, just as with IPv4. In fact, with some rules it's possible to do both IPv4 and IPv6 with the same rule.
-
You can always give your WAN a static address, then run a cat-5 cable to a laptop with NMAP on the other end. Scan until you're happy with it. Or simply run the scan from another location.
It's better to use NMAP than GRC's site as I don't believe the shields up does UDP scanning. Only TCP. ( correct me if I'm wrong ) Also, be aware GRC is only scanning the first 1000 ports and you'll probably want to scan the entire range ( both TCP and UDP ) instead.
Depending on what version of NMAP you're using the command is something along the lines of:
( This will take a long time to process as NMAP has to wait for the full timeout on UDP )sudo nmap -p0-65535 -sT -sU target_ip_address
sudo : admin / root permissions
-p0-65535 : port range to scan ( can also use -p- to indicate the entire range I think )
-sT : TCP
-sU: UDPA test run of the above command modified for only the first 1000 ports took ~70 seconds.
Assuming it can maintain that speed, it would take ~75-80 minutes to complete a full scan. -
Stealth means the packet is being dropped and their crap scan isn’t getting a rejected packet notifying them that it’s blocked.
Steal or blocked, it’s working properly.
