Port 22 and 53 open on WAN, when it shouldn't be?

timthetortoise

Dumb question but in Advanced -> Firewall/NAT, you don't have "Disable all packet filtering" checked, do you?

edinburgh1874

Hi, no I haven't selected that option as I need NAT for internet access, etc.

Cheers

johnpoz

The default rule is block on all interfaces.. Unless you have created a rule to allow the traffic, unsolicited inbound traffic to the wan is blocked.

So did you remove the default block?

block drop in log inet all label "Default deny rule IPv4"
block drop out log inet all label "Default deny rule IPv4"
block drop in log inet6 all label "Default deny rule IPv6"
block drop out log inet6 all label "Default deny rule IPv6"

Take a look with pfctl -sa
https://doc.pfsense.org/index.php/How_can_I_see_the_full_PF_ruleset

Did you put some rule in the floating tab?

edinburgh1874

No floating rules, and the default block rules are there too.

block drop in log quick inet6 all label "Block all IPv6"
block drop out log quick inet6 all label "Block all IPv6"
block drop in log inet all label "Default deny rule IPv4"
block drop out log inet all label "Default deny rule IPv4"
block drop in log inet6 all label "Default deny rule IPv6"
block drop out log inet6 all label "Default deny rule IPv6"

johnpoz

Well then your firewall is not working, which clearly it is since you say if you put in a rule stuff is blocked. Or they are coming in via lan maybe? You say your seeing

"I see a large number of failed password attempts in the system logs"

And what does this mean exactly?
"some of the boxes are instantly flooded with DNS traffic on the WAN port"

As you can clearly see by the rules - all unsolicited traffic is dropped unless its allowed with a rule before that.. So either you have rule that allows it before, or your maybe looking at something wrong.

Example here is blocked 22 in my log

edit: So logged in via ssh, so I could see what happens in the log
Jan 27 07:14:27 sshlockout[48866]: sshlockout/webConfigurator v3.0 starting up
Jan 27 07:14:27 sshd[48259]: Accepted publickey for admin from 192.168.1.100 port 1071 ssh2

So it does not tell me the interface that came in on.. So why do you assume its WAN? What is your detailed network layout?

blocked22.png_thumb

edinburgh1874

Hi,
Sorry, maybe I haven't been detailed enough.

What I am seeing is multiple failed SSH logins from WAN addresses in the system logs, e.g. failed from 68.77.69.1, etc.

This is a new setup at my home to replace an iptables firewall.

I mentioned the DNS issue, as I've seen it in a previous installation of pfsense at work, where we had to close off port 53 to stop a DDOS attack - that might have been something from the inside though.

My network setup is a PC Engines Alix 2d3 going into a Draytek Vigor 120 PPPOE modem.

My interfaces are WAN, pppoe0 and LAN, vr1 (10.100.0.0/24).

The strange thing is that ShieldsUP is intermittently showing ports 80,53,443 and 22 as open on my WAN address, but blocks IMCP.

When the ports are shown as open, I can verify this by SSHing into my WAN address from work, or trying the web interface.

When ShieldsUP shows the ports as closed, I cannot SSH into the address any more.

edinburgh1874

Looks like I'm getting some sort of crash according to the logs.

I tested open ports again, which were closed

Then ran speedtest, which appeared to cause high CPU and crashed the box according to below - right after this Shieldsup showed the ports as open.

Jan 28 00:09:32 php: rc.filter_configure_sync: Sending HUP signal to 1710
Jan 28 00:09:35 ipfw-classifyd: Reloading config…
Jan 28 00:09:35 ipfw-classifyd: Loaded Protocol: flash (rule altq)
Jan 28 00:09:47 check_reload_status: updating dyndns WAN_PPPOE
Jan 28 00:09:47 check_reload_status: Restarting ipsec tunnels
Jan 28 00:09:47 check_reload_status: Restarting OpenVPN tunnels/interfaces
Jan 28 00:09:47 check_reload_status: Reloading filter
Jan 28 00:09:58 php: rc.filter_configure_sync: Sending HUP signal to 1710
Jan 28 00:10:05 ipfw-classifyd: Reloading config...
Jan 28 00:10:05 ipfw-classifyd: Loaded Protocol: flash (rule altq)

Looking at the logs I appear to have been getting high CPU all day, whilst no devices on the network have been on.

I wonder if this little box is insufficient for PFSense, or faulty perhaps...I don't have any packages installed at the moment.

pf.jpg_thumb

johnpoz

"I wonder if this little box is insufficient for PFSense, or faulty perhaps…I don't have any packages installed at the moment."

Doesn't really take much to run pfsense - how many users do you have, this sounds like your home setup? If so shouldn't need much, I use to run it on a old P3 800MHZ box with 256 of ram..

I currently run it on a VM on a n40L with 512 given to it. You clearly got something going on there that is not right -- here is my cpu graph from RRD

Here is me maxing out my download with a speed test, see very minor usage.. And then an updated RRD, with multiple speedtests back to back to back trying to get the shot to attach..

cpu.png_thumb
multiplespeedtests.png_thumb

maxdownloadcpu1.png_thumb

edinburgh1874

Thanks johnpoz - since I removed that L7 rule, the CPU usage has stopped spiking.

There's just me and a laptop on the network, and there were no devices attached 0800 - 1800.

It's odd that the CPU was spiking, as there was no traffic during this time.

I'm more concerned that the firewall appeared to stop blocking these ports though!

johnpoz

Well if your crashed the OS and the filtering service stopped, then how would those ports be blocked?

I know in dns forwarder you can have it NOT listen on wan, as to ssh not listening on wan not sure - don't see anything right there in the gui when you enable it. I personally don't allow password auth anyway and only public KEY. so even if pfsense firewall failed and that was open I really wouldn't be all that concerned.

As to not having the web gui listen on wan - not sure either.

There have been threads in the past about services listening on all interfaces by default and relying on the firewall to block access. Your issue where the firewall service seems to crash is a good argument for only listening on the internal interfaces - allow for control of what interfaces different services that pfsense runs to bind too, etc.

Not sure - if you can duplicate the issue by redoing your L7 setup.. I would bring that up to the developers as a bug, or maybe somebody can explain why your L7 is causing the problem and its not a bug, etc. etc..

But if your not crashing your box - then your firewall rules should all work ;)

edit: BTW looks like your system pegged about every 15 minutes or so for a few minutes and then dropped off to normal again.. Either something really really working that L7 rule every 15 minutes or so on a schedule or pfsense had some cron running on the schedule causing the issue.