Pfsense open ports [SOLVED]
-
I have done a fairly default install and did an nmap external to my network
Starting Nmap 5.21 ( http://nmap.org ) at 2011-03-02 10:13 EST
Nmap scan report for x.x.x.x (x.x.x.x)
Host is up (0.013s latency).
rDNS record for x.x.x.x: ME.comcast.net
Not shown: 996 filtered ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
443/tcp open httpsNmap done: 1 IP address (1 host up) scanned in 5.06 seconds
I have enabled ssh and that is about it… why are all of these other ports Open to the internet!!! when I try to log into the web interface it does not work, thankfully, but I can ssh into it.
-
Did you do this from another computer like @ work or a friends house or lan side? All those ports are open LAN side by default.
-
yep, I am at work now… decided to check on it and got surprised by those results
-
Yikes, what's your WAN ruleset look like?
yep, I am at work now… decided to check on it and got surprised by those results
-
pretty much I added on for my torrents and one for OpenVPN and everything else is default. I can not get into it now using the web interface, but I can check at lunch, unless someone knows how to get it from SSH. I did do the Filter Logs option in the CLI and I see connections being blocked.
-
Well, I allow a few ports from my work IP, however I have a T-Mobile card on a laptop I decided to run nmap on. And this is what I came up with as well….
Starting Nmap 5.51 ( http://nmap.org ) at 2011-03-02 10:05 Central America Standard Time
Nmap scan report for WAN IP
Host is up (0.076s latency).
rDNS record for WAN IP
Not shown: 993 filtered ports
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
110/tcp open pop3
143/tcp open imap
443/tcp open https
8080/tcp open http-proxy
-
Anyone know if this is because pfsense is rejecting packets instead of dropping packets for these ports?
-
You might want to test to make sure you can not proxy through your box externally, unless you have it set that way on purpse.
-
No reverse proxy set up, using linux if I try to connect to it on any port via nmap it fails. I also see in the firewall logs where it is all being blocked.
No machines are on at my home at the moment, and I do not host any of the services listed beyond 80/443 externally.
I believe it's showing up as open because of the response nmap got, I'm just wondering what response.
-
After firing up a PC @ home, ShieldsUP! (https://www.grc.com/x/ne.dll?bh0bkyd2) shows all ports as closed. I understand nmap uses a little more "thorough" method, however if it can't make a connection, then what response is causing nmap to see it as open?
I don't want to give people the false impression I have a port open and then they start hammering away.
-
On my end I can get to the login screen for my admin web interface, but it will not allow me to log in. I am not a huge fan of that even if it does prevent login
-
The ports would only be open if you opened them. Everything is blocked by default.
A lot depends on not only where you run the scan from but from what kind of router you are running the scan from behind.
If you are running a scan from a system behind a proxy (ftp proxy, web proxy, etc) you may be getting lured into that proxy instead of actually hitting the box you are trying to scan.
A scan from somewhere else like GRC is likely to be more accurate than an nmap scan from a 3G dongle/tethering setup.
If you can hit the web port on pfSense, you can login. If you can't login, you are probably hitting something else – not your firewall.
A packet capture on WAN during the scan could confirm more of this.
-
I just ran a nmap scan from work to my pfsense box at home.. Just the ports I want open are:
Discovered open port 443/tcp
Discovered open port 21/tcp
Discovered open port 80/tcp
Discovered open port 3389/tcpI'm using nmap on a xp box… Funny, because my web server is a windows box, its 90% sure i'm running windows..
What I did notice the scan states that port 15000/tcp is closed. I've seen this before and can't remember what triggers this.
-
That's a little more reassuring. I cannot connect to any ports using ncat, or simply by accessing the service. I do not get the webportal like the OP.
I believe you are right, I'm sure T-Mobile uses some sort of in between to do QoS and other fancy filtering.
I'm using Zenmap (nmap gui), and it gives me option of "intensive" scan, and it did show 3 hops before it got to my actual computer. So what you are suggesting is that I ended up testing one of the nodes instead of my box @ home? Sort of neat how that works out. More interesting that some/partial of my connections are being made to the node, and possibly the node is making connections on my behalf like a MITM.
Jimp, as always you're very informative and helpful :-D
The ports would only be open if you opened them. Everything is blocked by default.
A lot depends on not only where you run the scan from but from what kind of router you are running the scan from behind.
If you are running a scan from a system behind a proxy (ftp proxy, web proxy, etc) you may be getting lured into that proxy instead of actually hitting the box you are trying to scan.
A scan from somewhere else like GRC is likely to be more accurate than an nmap scan from a 3G dongle/tethering setup.
If you can hit the web port on pfSense, you can login. If you can't login, you are probably hitting something else – not your firewall.
A packet capture on WAN during the scan could confirm more of this.
-
You must be hitting something else along the way that is redirecting ports into itself.
The most common example of this is pfSense's FTP proxy. If you do an nmap scan from behind a pfSense router for an external IP, it will show FTP open if you have the FTP proxy on, because the proxy is grabbing the FTP traffic.
If you really want to know for sure, PM me an IP and I'll nmap it from a known good source and tell you what is really open. :-)
-
The ports would only be open if you opened them. Everything is blocked by default.
A lot depends on not only where you run the scan from but from what kind of router you are running the scan from behind.
If you are running a scan from a system behind a proxy (ftp proxy, web proxy, etc) you may be getting lured into that proxy instead of actually hitting the box you are trying to scan.
A scan from somewhere else like GRC is likely to be more accurate than an nmap scan from a 3G dongle/tethering setup.
If you can hit the web port on pfSense, you can login. If you can't login, you are probably hitting something else – not your firewall.
A packet capture on WAN during the scan could confirm more of this.
I would be in shock if I somehow got redirected to someone else's pfsense 2.0 box because I was behind a proxy. Plus I can connect to the SSH port, shouldnt this need to be added manually or was there an option I must have accidentally selected?
I tried the filter option and I do not see any reference to my webpage connection, but I did see a reference to a blocked ping when I tried to ping it.
The error message I receive from the web interface after I try to log in is this:
An HTTP_REFERER was detected other than what is defined in System -> Advanced (https://mywebserver). You can disable this check if needed in System -> Advanced -> Admin. -
Did you enable the SSH service? What packages did you install? If you have a mobile, could you try connecting to the web portal that way, see if you get the same error?
The ports would only be open if you opened them. Everything is blocked by default.
A lot depends on not only where you run the scan from but from what kind of router you are running the scan from behind.
If you are running a scan from a system behind a proxy (ftp proxy, web proxy, etc) you may be getting lured into that proxy instead of actually hitting the box you are trying to scan.
A scan from somewhere else like GRC is likely to be more accurate than an nmap scan from a 3G dongle/tethering setup.
If you can hit the web port on pfSense, you can login. If you can't login, you are probably hitting something else – not your firewall.
A packet capture on WAN during the scan could confirm more of this.
I would be in shock if I somehow got redirected to someone else's pfsense 2.0 box because I was behind a proxy. Plus I can connect to the SSH port, shouldnt this need to be added manually or was there an option I must have accidentally selected?
I tried the filter option and I do not see any reference to my webpage connection, but I did see a reference to a blocked ping when I tried to ping it.
The error message I receive from the web interface after I try to log in is this:
An HTTP_REFERER was detected other than what is defined in System -> Advanced (https://mywebserver). You can disable this check if needed in System -> Advanced -> Admin. -
Then you probably aren't getting proxied, you just have the port open for outside access on your WAN rules. It doesn't open itself… :-) (Or you are scanning from an interface/IP that has access)
-
vorgusa:
Nmap scan report for c-x-x-x-x.hsd1.fl.comcast.net (x.x.x.x) Host is up (0.10s latency). Not shown: 65529 filtered ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 5.4p1 (FreeBSD 20100308; protocol 2.0) 53/tcp open domain dnsmasq 2.55 80/tcp open http lighttpd 1.4.28 443/tcp open ssl/http lighttpd 1.4.28 2189/tcp open sip FreeBSD/8.1-PRERELEASE UPnP/1.0 MiniUPnPd/1.4 (Status: 501 Not Implemented) 40122/tcp open unknownYou really do seem to have overly permissive WAN rules. If you post a screenshot of them were we can advise what might be causing it. (I scanned 1-65535)
-
Something else people seem to forget about too is that if you have UPnP enabled, anything on LAN can open up and forward whatever ports it wants. Even if you aren't hitting the pfSense box with a scan you could be hitting a port forward that opened up via UPnP.
-
upnp is disabled by default correct?
-
Yes, upnp must be enabled by hand.
-
heavy1metal - I got nothing open when I scanned your IP. Though I only scanned 1-3000 due to it being slow (presumably since they were filtered)
-
Excellent :-) That covers all the "normal 1-1023" service ports anyway. I'm a bit worried about the OP's open ports, he mentioned he has a port open for torrent traffic I believe, possible he wild-carded the destination port by accident?
Also, did you scan from two IP addresses? Or is that the result of load balancing from a dual WAN setup? Or maybe for once in my life I had an US port scan me :-) So used to the Chinese trying to scan me checking if I'm an open proxy. Thank you for checking :-)
heavy1metal - I got nothing open when I scanned your IP. Though I only scanned 1-3000 due to it being slow (presumably since they were filtered)
-
I took screen shots of the dashboard, NAT, Rules, and upnp settings. UPNP status is empty and I do not see why upnp would end up leaving port 53 open, seems like all my open ports are pfsense services. I am masking IPs and stuff in the screen shots and they will be up soon. I forgot to take a screenshot of the general settings for the ssh connection though.
-
Very frustrating to post attachements! :)
-
Here are the last two
-
As I posted in my other thread, I have reset everything to factory defaults and reconfigured it again. I noticed that when I originally installed everything I never saw the startup wizard, so I have a feeling its related to that. I also experienced unusually high CPU usage while nothing was going on and my other unusual problems are gone. I will scan it tomorrow with nmap and see if the problems are fixed.
-
You have/had port 443 open to the public/world by not specifying a source address. Also torrents only require TCP, they do not use UDP packets.
As for the upnp, you might want to do a port scan and then watch what ports open up. Or try disabling it, and then do a scan.
As for port 53, would anyone know if the "upnp port mapping (for windows)" would be letting windows services open up ports?
Maybe pfsense is opening port 80 on behalf of itself? Unless you have a web server back there trying to get out?
Also I assume your torrent port is 40122? Sort of the only one open that looks out of place.
Just saw your system.txt, in there I saw
Mar 2 19:19:30 miniupnpd[12590]: HTTP listening on port 2189
Mar 2 19:19:30 miniupnpd[12590]: HTTP listening on port 2189Is upnp intended to open ports even if it is a service on pfsense that wants them open?
 -
After the factory defaults, I am still getting the ports open. The previous port 443 was done by the OpenVPN wizard because I designated that as the port for it. Right now I have OpenVPN at the default port (1194) and upnp enabled, but only for the LAN. The only port forwarding and Rules I have done are for Torrents and what the automated wizards has done.
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
443/tcp open https
1194/tcp open unknown
2189/tcp open unknown
40122/tcp open unknownWhy would the Upnp even be there if I selected it to only be there for the LAN section.. seems like PFSense services are before the Firewall
-
That is strange, and you're still able to access the web portal from work? If you tried now to log in does it give you that redirect error you were getting before?
-
Yep, same error and for some reason I can not get an IP from OpenVPN, but that might be a problem on my end. I will look into that tonight, but then again, I will probably go back to 1.2.3 if these ports keep showing up… I could probably try to manually block them using the firewall.
-
How is your network wired up?
Is that public IP directly on WAN, or do you have something else in front doing NAT?
Can you post the contents of /tmp/rules.debug - it might help show what the issue really is.
-
I never re-enabled ssh, but I will head home for lunch and set it up. By the way, I have never done anything related to port 53, so I know that should not be showing. At work, if I do:
host -T internalserver.local MyWAN-IP
I get my internal IP address for the internal server, so that is definitely not being blocked in any way (-T is for TCP connection)
-
here is that file
-
pass in quick on $WAN reply-to ( re0 x.x.x.x ) proto TCP from any to x.x.x.x keep state label "USER_RULE: OpenVPN Home wizard"There is no port on that rule for OpenVPN - so it's letting all TCP traffic in to your WAN IP.
Did you alter that rule?
-
Nope I did not, both times I just let the wizard create the rule (USER_RULE: OpenVPN Home wizard) and did not alter it. I will check on it when I get home
-
the screenshot I put of my rules page clearly has port 443 on it before hand. That would be the port you were talking about in the previous line? why would the port be listed there but not in the rules.debug?
-
ok, edit and save your OpenVPN rule, see if that fixes it. Make sure to re-select UDP as the protocol if it's supposed to be UDP and not TCP.
I fixed a bug with the wizard earlier today that was apparently causing this to happen, too.
The protocol (TCP or UDP) was getting into the rule as upper case, not lower case, and the port was being left off because it didn't match "tcp" or "udp".
Anyone on a new snap should be OK though. At least the next new one.
-
Just attached part of the config.xml If I change the 3rd one to match the other two and then restart my box, would that fix the problem? /cf/conf/config.xml
