OPNsense Forum
Archive => 17.7 Legacy Series => Topic started by: opnphil on November 06, 2017, 06:20:24 am
-
My first installation of OPNsense two days ago, after a couple of years with pfSense. I set up the usual, which is several subnets to compartmentalize traffic: IoT, home, guests, VOIP. I wrote some firewall rules, which are the usual for me: I give one subnet with a single management box a pass/any/any, and I use that one to access and manage the other subnets, which are walled off from RFC1918.
So here's where it all goes wrong. When I went back into the system today to make a firewall change I saw, to my horror, that I had not put the rule on the subnet's interface. Instead, I had put it into the floating rules. Moreover, it was automatically a quick rule; pass any any. And, strangely enough, the subnet I thought it should be under had no rules at all. That's something that should not have been able to happen, considering that I was getting out to the net just fine on that box; unless it was the pass any any that had made that happen.
Since then, I have been trying to figure out what happened, and what the consequences might have been. It seems to me that such a floating rule completely opens up the firewall, because it applies to the WAN in both directions. Indeed, I did a quick experiment by running Shields Up on the system with the rule in place, and sure enough it showed 80 and 443 open. Holy crow. I checked my logs for problems, but I'm not even sure I would find any. The configuration history did not go back far enough to show where exactly I had made the error.
Two days of having the router open to the WAN, with a not particularly strong password on it--what to do? Is there anything on that box that is going to be salvageable? My systems inside are all individually firewalled, except for an access point--so I don't think there's anything that could have jumped--but still....
This careless error, a combination of fatigue and of unfamiliarity with the interface, has me spooked. I don't actually have any clear idea what it means yet, or even how floating rules work, because the documentation on them is fairly scanty. Can anybody help, please?
-
Are you using ipv4 or ipv6?
ipv4: you should check if someone loged into pfsense. The lan-devices are not reachable from internet unless you set up NAT
ipv6: the lan devices could be reached from internet - but if the device firewalls are "up to date" there should be no problem. The accesspoint without firewall should be checked twice
Michael
-
Well - You could roll it back to the 1st day it was configured.
Then save the config.
Then do a fresh install, restore the config, make your passwords strong.
Then check your rules and make sure you don't have that floating rule.
Generally, I only use floating rules for blocks and not passes.
When you are done with this, run your port authority test. If all looks good, save your final config again.
Even if someone did get into your box, I doubt they would have modified your autosaved configs from the past, so I feel like it should be fine.
Or rebuilding from scratch is always an option. I think its unlikely you were hacked.
Also, you don't need a bunch of different firewalls. You can do it all from one Opnsense.
As far as how this happened? Simple. You likely finger fumbled and made a mistake. I do it allllllll the time.
-
Thank you for your patient and understanding replies. Thus encouraged, I hope you don't mind if I pursue this a bit and offer a few more details, probably too much.
I do use IPv4, and I actively try to disable IPv6 because it's too hard for my aging brain. It used to be easier in previous versions just to ignore it, but now it's creeping into the kernels everywhere.
My passwords were 9 mixed characters--hardly strong, but not "password" at least. Someone scanning the ports would have had to try for some time to get into the box. How long, I wonder, would such a password hold against a brute force? Would a bad guy even bother to try to brute force a dynamic public IP on Comcast? Not much return on the effort, but that's cold comfort, considering I see continuous blocked port scans in the logs on telnet ports.
I'd like to restore, or at least view, the earliest configs, but I can't. The "config history" feature only goes back to 60 changes. Because each firewall change is logged as a config change, and I had many subnets and firewall rules added, the original configuration had long since scrolled off the end. I went to open a shell into the logs--by the way, where is the command to open a shell in the gui menu tree? anyway I enabled SSH temporarily, and SSH'd into a shell -- to see if further changes were stored there; but I could not find the file that keeps the changes in /var/log. Where is that file? Might it hold earlier configurations than the gui offers, even if the gui is limited to 60? Anyway, I did use the gui to diff all the way back to the original configuration changes (great feature), but couldn't pin down where exactly the boo-boo happened. I don't mind re-installing from scratch, that doesn't bother me, but I'd really like to see exactly what happened, so I can learn from it.
I did find the record of the entry for the baneful change in the current config: it is noted as having been added by me, sometime during the initial configuration process, with a timestamp that I can't decode: format xxxxxxxxxxx.xxxx. I couldn't find out how to decode that to find out exactly when the entry had been made.
Where are the auth logs?
Am I correct that it was that fateful floating quick rule that allowed my personal subnet out to the internet, even in the absence of a pass rule on its tab? I was using that box all day for work, and it was only late in the day that I logged into the router and found the pass any rule, which I then deleted. Of course, that's when I lost access to my own router, and had to physically connect to the LAN subnet with its anti-lockout rules. I use that as a kind of informal IPMI. It has saved my butt many times.
Lastly; boy this is a long whine; sorry--is it possible that my noob error came about because the firewall rules menu opens a tab system that defaults to "floating"? The tabs are easy on the eyes; maybe the color highlighting the active tab could be have more contrast? I'm thinking that's what may have made it easier for me to err. In the years past using another, similar kind of software that shall not be named (which now seems broken in a dozen small ways; hence my presence here), I never even touched the floating tab. Not that I'm exculpating myself here: I should obviously have scanned the ports as part of the pre-production checklist. But still, anything to save someone else from the same midnight panic!
-
Would a bad guy even bother to try to brute force a dynamic public IP on Comcast?
Sure - People seem to have little else to do with their time.
When I open console and login, option 13 shows available restore points and dates. You should be able to tell by the date time stamp if a change was made after you put it online. Although, lots can be done via command line that won't be reflected in configs. That why I think an old config wouldn't have been tampered with. So, for me, restoring it to a new install would be fine.
Floating rules... Consider those to exist on every tab.
LAN or VPN is how you should be accessing the GUI. Perhaps SSH and a port forward is also good.
is it possible that my noob error came about because the firewall rules menu opens a tab system that defaults to "floating"?
More than likely. I've never applied a rule on the floating tab by accident but I have caught myself in there starting to make a mistake. I keep 1 floating rule to block IPV6 to netflix but thats disabled because I have a DNS fix for the problems it was creating. I don't have any reasons currently to make a floating rule, but they do make for handy blook-all rules.
As far as the other distro you are talking about, I currently run them side by side in one place, to get used to opnsense. So far I'm finding opnsense to work very well.
Anyway, whenever I make changes I export the config and save it in a folder so that when me or someone else breaks things I have it handy.
-
OK, to put some closure on this. I went and reinstalled pfSense and configured it again. In the process I noticed that it is much clearer which interface the rules are being applied to. Also, the firewall rule menu item defaults to WAN, which, while it has problems of its own, at least is not as dangerous as Floating.
If I may be permitted to offer some suggestions, they would be these: 1) default to the LAN interface, which is one that already has the most permissions by default, and so an error is least likely to cause a problem; alternatively, default to the last added interface; 2) make the tabs much larger and clearer; 3) offer a place to launch a BSD shell from the GUI; 4) put an auth log in the Users tab to show who has been logging in, or trying to do so; 5) document somewhere what the timestamps in the logs mean.
-
What hardware are you installing this on? Whats the system specs?
I ask this because if AES-NI isn't on the CPU you will likely be forced away from pfsense very soon, like it or not. While I am very familiar with their GUIs also, I try not to let minor GUI differences be the deciding factor.
What about NICS? All their hardware consists of a certain set of intel NICS. If they will put a poison pill in the code to detect the lack of AES-NI and abort install, whats to keep them from doing the same things with NICs, chip set, or any hardware... Basically purposely and artifically creating a "runs best on official hardware" scenario? Keep it in mind, because I really feel that is where they are headed.