53/tcp open domain | 80/tcp open http

security_paranoid

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 ?

ptt

You run NMAP from the WAN side ?

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

security_paranoid

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 ?

NogBadTheBad

$ 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

security_paranoid

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 ?

ptt

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

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

https://forum.pfsense.org/index.php?action=search

Harvy66

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.

security_paranoid

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 ?

ptt

Do you have any FW rule on pfSense WAN ?

(Attach Screenshot of your FW Rules)

security_paranoid

Please see attachment.

wan.png_thumb

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.

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

security_paranoid

@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)

phil.davis

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.

security_paranoid

@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 ?

phil.davis

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.