Security issues
-
I'm running the snapshot: pfSense-2.0-BETA4-1g-20101202-0339-nanobsd.img and I just had a scare after looking at the system logs. Apparently ports 22 & 53 were open on the WAN interface, yet there was no rule on the WAN interface to open ANYTHING. Pretty scary stuff. I'm going to try one of the snapshots from today and see how it goes.
I just wanted to let everyone know that it's a good idea to port scan your self when testing these builds.
-
I just upgraded to the latest snapshot and both 22 & 53 are open on the WAN port. Disabling SSH is an easy but an annoying fix, because I'd like to run it on the lan. I can make DNS requests against my firewall from the outside. This is crazy. I am running dnsmasq and setting a rule to block 53 on WAN has no effect. Maybe I should add that my WAN is tied to a PPPoE DSL line. Could that be part of the problem?
Any help would be appreciated.
-
I recently made a similar realization and it turned out one of my floating rules was the cause of the problem. If you want to post your /tmp/rules.debug here we can have a look, particularly the section beginning "# User-defined rules follow".
-
You could also check whether there are any pass quick rules above that section that are allowing those ports.
-
By default nothing is allowed in WAN, but if you add floating rules or WAN rules you can allow that traffic. It's not a security issue (well, it's a user-created one), just doing what you configure it to do.
-
I understand how to write firewall rules (most of the time). I have two rules on my WAN port.
1. tcp/80 –> web server
2. tcp/1194 --> openvpnThe only firewall rule that mentions port 22 is the anti-lockout rule on the LAN interface. However when SSHD is enabled in pfSense it's available to the outside. I'm glad I was reading the logs last night and that I have a strong password. Sure enough I could SSH in from my phone, until I stopped the daemon. I've never seen behavior like this from pfsense (or any other firewall).
While using nmap to see if anything else was open 53 showed up as open, and dig @myip was resolving addresses. This really freaked me out until I ran another port scan from the office this morning. I can say confidently that this port was never open and the false positive was a result of tethering through sprint's network. Any IP I scan through sprint 53 shows as open. I guess they always high-jack dns.
The good news is that 53 was never open; dnsmasq was not open. The bad news is that SSH was open. I'm not familiar w/ floating rules. I'll have to look into that tonight. Also I'll get the output of the tmp dir when I have a minute.
Can anyone replicate this issue w/ SSH? I'm running an Alix 2d3 w/ nanobsd 1g img.
Thanks for the feedback.
-
I just scanned my firewall using GRC.com's shields up page. Ports 22 & 53 were not available on my WAN interface.
I have both dnsmasq and sshd enabled on my box.running i386 full built on Sat Dec 4 01:05:18 EST 2010
-
I wouldn't expect 53 to be open as that was a nmap/Sprint false positive.
…but that's good to know that 22 is working properly. I assume you have SSH running, correct?
I'm sure I have something foobared in my config, but I really haven't done much to it. :| I'll troubleshoot more tonight when I'm home.
-
Clarknova, here's the output from /tmp/rules.debug
rules.debug: unmodified: line 1
WAN = "{ pppoe0 }"
LAN = "{ vr0 }"
DMZ = "{ vr2 }"
#SSH Lockout Tablepn }"
table <sshlockout>persist
table <webconfiguratorlockout>persist
#Snort2C tableGatewaysasesot>
set loginterface pppoe0poe0 XX.XX.XX.XX ) "
set loginterface vr0I tried enabling SSH on the snapshot from last night, and the behavior is normal. Nothing is exposed. This whole thing was strange. Sorry for over-reacting last night; I was kind-of freaked out.
PJ2, good call on using grc.com for scanning. That proves much more reliable that using a mobile network.
…I imagine this was user error like everything else. ;)
cheers,</webconfiguratorlockout></sshlockout>