Port 80 can't be blocked on WAN?



  • Hello,

    I'll start by saying I don't know that I'm asking in the right place (though I am using the latest 2.2RC) and that I'm a neophyte with pfsense (long time ipcop user).

    I've been testing my pfsense installation by doing a port scan from a different network to my external fixed IP, and I find that port 80 is open and seems to have a squid proxy (that's what nmap thinks it finds, anyway).  I'm only using what came with the 2.2RC (ie no additional packages) and I've added explicit drop rules for all tcp/udp from/to all at the end of my rule list.  Shouldn't I be able to block this port?

    Thanks!



  • it's closed by default. if it's open, you must have opened it.
    also, don't add block rules at the bottom, add them at the top



  • Are you sure the other network doesn't have a transparent squid proxy that's intercepting your port scan for port 80?



  • The other network is comcast, so I suppose they could be intercepting the port 80 traffic (for advertising purposes, I'm sure).  Is there a way for me to know?

    I must have misread the docs - I thought the rules were evaluated from the top down so if I first block everything, all traffic would match the 1st rule and nothing would be evaluated further - this is not the case?

    (and I think this thread is drifting from 2.2 concerns into newbie country - sorry about that)



  • I must have misread the docs - I thought the rules were evaluated from the top down so if I first block everything, all traffic would match the 1st rule and nothing would be evaluated further - this is not the case?

    Yes, rules are evaluated from the top down, and first match applies.
    If you block everything with the first rule, then everything is blocked - no point even having other rules on the interface.



  • @phil.davis:

    I must have misread the docs - I thought the rules were evaluated from the top down so if I first block everything, all traffic would match the 1st rule and nothing would be evaluated further - this is not the case?

    Yes, rules are evaluated from the top down, and first match applies.
    If you block everything with the first rule, then everything is blocked - no point even having other rules on the interface.

    Whew!  I was heading toward very confused there for a bit…

    I'm still wondering if there's a way for me to detect who's "providing" this squid for me - any thoughts anyone?



  • @di410733:

    I'm still wondering if there's a way for me to detect who's "providing" this squid for me - any thoughts anyone?

    Silly me!  I finally browsed to the fixed IP and I get the pfsense login page, so I know where it's coming from.  I checked again, and when I go to the "System: Package Manager"->"Installed Packages" tab there is nothing in the list - so it appears that squid on port 80 is always installed?  If so, that goes back to my original question - how can I disable it?


  • Netgate Administrator

    Where did you browse from? If it's internally you will see the wegui, that's expected behavior. The webgui listens on all interfaces but access to it from WAN should be blocked by default.

    Steve



  • Post the firewall rules on WAN. Then we can really help understand and sort out what is going on.

    If the "squid" detection thing is really happening when checking from another public internet, then the easiest way to confirm it is not pfSense is to air-gap your WAN - unplug the WAN cable then run the port scan to the WAN public IP. (Depending on your available methods of internet access, you might need 2 people to do this) Anything back from the scan must be your ISP somewhere in the middle. Note that if the scan returns nothing, that does not necessarily prove that pfSense WAN is the culprit - the ISP might only have "in the middle" stuff active when it sees your WAN is up.



  • @phil.davis:

    If the "squid" detection thing is really happening when checking from another public internet, then the easiest way to confirm it is not pfSense is to air-gap your WAN - unplug the WAN cable then run the port scan to the WAN public IP. (Depending on your available methods of internet access, you might need 2 people to do this) Anything back from the scan must be your ISP somewhere in the middle. Note that if the scan returns nothing, that does not necessarily prove that pfSense WAN is the culprit - the ISP might only have "in the middle" stuff active when it sees your WAN is up.

    Well, that was an interesting experiment!  I gave that a try, and found that with the WAN disconnected I still saw a squid on port 80, and didn't see the NAT port that I have configured (plus, when I browsed while disconnected, I didn't get the pfsense login page).  I then reconnected and tried again, and found that I could no longer browse to the pfsense page, and the error page indicated that it was the firewall of the network I was browsing from that was providing the error!  This firewall (ipcop) had a transparent squid proxy configured, so I disabled that and now see only the NAT port shows up as open.

    I wouldn't have expected this at all, but it explains things - sorta (well, I don't quite understand why nmap thought the squid was on the pfsense box, but at least I can now be confident about the pfsense firewall).

    Thanks for the help!



  • @di410733:

    @phil.davis:

    If the "squid" detection thing is really happening when checking from another public internet, then the easiest way to confirm it is not pfSense is to air-gap your WAN - unplug the WAN cable then run the port scan to the WAN public IP. (Depending on your available methods of internet access, you might need 2 people to do this) Anything back from the scan must be your ISP somewhere in the middle. Note that if the scan returns nothing, that does not necessarily prove that pfSense WAN is the culprit - the ISP might only have "in the middle" stuff active when it sees your WAN is up.

    Well, that was an interesting experiment!  I gave that a try, and found that with the WAN disconnected I still saw a squid on port 80, and didn't see the NAT port that I have configured (plus, when I browsed while disconnected, I didn't get the pfsense login page).  I then reconnected and tried again, and found that I could no longer browse to the pfsense page, and the error page indicated that it was the firewall of the network I was browsing from that was providing the error!  This firewall (ipcop) had a transparent squid proxy configured, so I disabled that and now see only the NAT port shows up as open.

    I wouldn't have expected this at all, but it explains things - sorta (well, I don't quite understand why nmap thought the squid was on the pfsense box, but at least I can now be confident about the pfsense firewall).

    Thanks for the help!

    Because traffic INTENDED for the pfSense box was being hijacked and intercepted.


  • Netgate Administrator

    Mmm, intersting scenario. This wouldn't have happened if pfSense was using https for webgui.
    Presumably at some point the pfSense webgui was open on WAN and the remote Squid cached it. Seems odd though. Like you wouldn't be able to login and any dynamic parts of the dashboard wouldn't work.

    Steve


Log in to reply