53/tcp open domain | 80/tcp open http



  • Hi,
    When I run nmap scan on my wan interface I find 2 ports open.

    $ nmap 172.16.197.126
    
    Starting Nmap 6.47 ( http://nmap.org ) at 2017-04-29 23:27 IST
    Nmap scan report for 172.16.197.126
    Host is up (0.0032s latency).
    Not shown: 998 filtered ports
    PORT   STATE SERVICE
    53/tcp open  domain
    80/tcp open  http
    
    

    Why are port 53 and 80 open ?


  • Rebel Alliance

    You run NMAP from the WAN side ?

    172.16.197.126 is a "Private IP" (Not reachable from the "Internet")



  • You run NMAP from the WAN side ?

    172.16.197.126 is a "Private IP" (Not reachable from the "Internet")

    Thanks a lot for your reply.

    No I am running nmap from the LAN side. I am using cable broadband and my ISP has given me this  address (172.16.197.126) for the WAN interface.

    Okay then I guess there's  nothing to worry about  right ?


  • Galactic Empire

    $ nmap 172.16.197.126

    Starting Nmap 6.47 ( http://nmap.org ) at 2017-04-29 23:27 IST
    Nmap scan report for 172.16.197.126
    Host is up (0.0032s latency).
    Not shown: 998 filtered ports
    PORT  STATE SERVICE
    53/tcp open  domain.        << DNS from your routers LAN interface
    80/tcp open  http.              << HTTP access to your routers LAn interfaace



  • 53/tcp open  domain.        << DNS from your routers LAN interface
    80/tcp open  http.              << HTTP access to your routers LAn interfaace

    I just opened 172.16.197.126 using my web browser and the pfSense web interface opened.

    Does this mean that other users who belong to 172.16.197.0 can see my pfSense interface ?


  • Rebel Alliance



  • pfSense firewall rules are per interface, not per IP. Just because port 80 is blocked on the WAN interface does not mean the port is blocked for the WAN IP.



  • pfSense firewall rules are per interface, not per IP. Just because port 80 is blocked on the WAN interface does not mean the port is blocked for the WAN IP.

    My ISP blocks port 80.  Is there a way to find out if port 80 is open for the WAN IP ?


  • Rebel Alliance

    Do you have any FW rule on pfSense WAN ?

    (Attach Screenshot of your FW Rules)



  • Please see attachment.



  • Rebel Alliance

    Since you don't have any "Pass/Allow" Rule on your WAN, "ALL Ports are Closed" for "Inbound Traffic"

    In a "Default" pfSense install, ALL traffic from LAN to ANY (outbound) is allowed, and ALL traffic from ANY to WAN (Inbound) is Blocked.

    Please Take some time to Read/Check the Docs

    https://doc.pfsense.org/index.php/Main_Page

    https://doc.pfsense.org/index.php/Firewall_Rule_Basics

    https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order

    https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting



  • @ptt:

    Since you don't have any "Pass/Allow" Rule on your WAN, "ALL Ports are Closed" for "Inbound Traffic"

    In a "Default" pfSense install, ALL traffic from LAN to ANY (outbound) is allowed, and ALL traffic from ANY to WAN (Inbound) is Blocked.

    Now the default configuration has changed. Please see

    wan before and wan after attachments.

    Just to be sure all traffic from any to wan is still blocked correct ?

    ![wan before.png](/public/imported_attachments/1/wan before.png)
    ![wan before.png_thumb](/public/imported_attachments/1/wan before.png_thumb)
    ![wan after.png](/public/imported_attachments/1/wan after.png)
    ![wan after.png_thumb](/public/imported_attachments/1/wan after.png_thumb)



  • When you come from the LAN side directly to an internal pfSense IP address (like WAN address), the packet arrives on LAN and is filtered by the rules applying to LAN. Often LAN has a "pass all" rule (or at least "pass a lot of stuff" rules). So if traffic with source in LAN network and destination WAN address is passed, then that is as specified.

    For traffic from LAN to WAN address, the traffic does not leave the firewall again. So it does not "arrive" on WAN from "outside". Thus it is not processed by the firewall rule(s) on WAN.

    Yes, coming from "outside" (upstream of WAN - the big bad internet), traffic to WAN address is blocked.

    If you want to also block traffic from "inside" then you need to suitable rule(s) on LAN. But of course you do want to access the webGUI from somewhere (usually somewhere LAN-side) to manage pfSense. So you better make sure not to lock yourself out.



  • @phil.davis:

    If you want to also block traffic from "inside" then you need to suitable rule(s) on LAN. But of course you do want to access the webGUI from somewhere (usually somewhere LAN-side) to manage pfSense. So you better make sure not to lock yourself out.

    Do you think creating rules for the LAN interface is a sensible thing to do ? Or is it just too much for a home setup ?
    Doesn't leaving the Anti lockout rule intact rules out the chances of locking my self out ?



  • Do you think creating rules for the LAN interface is a sensible thing to do ? Or is it just too much for a home setup ?
    Doesn't leaving the Anti lockout rule intact rules out the chances of locking my self out ?

    True, the anti-lockout rule specifically just allows access to ports 80,443,22 on LAN address. So having that always at the top will get you in from LAN.
    So you could put a block rule on LAN straight after that:

    block source any, protocol any, destination "WAN address"
    
    

    or even:

    
    pass source any, protocol any, destination "LAN address", ports DNS...
    block source any, protocol any, destination "this firewall"
    
    

    "this firewall" gets turned into a list of all firewall interfaces. So that would cover WAN, LAN (and you get in there first by the anti-lockout rule and give users access to DNS… by a rule before it) and any future WAN2, OPT1 etc that might exist now or be added.

    For the webUI (80,443) and ssh (22) you do not really gain anything because it does not really matter if someone starts from LAN and goes to LAN address or WAN address to access - they are connecting to the same service.

    But it does protect against them accessing any other services on any interface that might be enabled/listening.

    Whether it is overkill for a home setup is a matter of if you like tinkering around.