pfSense hacking

[Antibiotic]

Is it possible to hack pfSense firewall from outside. I mean any official evidence, that someone did this?

[SteveITS]

@Antibiotic without exposing the web GUI or SSH, I assume?

It seems likely it would need to be via an exposed service like IPSec/OpenVPN.

[johnpoz]

If someone got into someone elses pfsense - can almost promise you it was user shot themselves in the foot by exposing ssh or gui for example and not changing the default pfsense admin password.

Before they warned you about changing the password.. Now it seems they are forcing the issue.. I am not really a fan of forcing that, but you got a few users that don't follow instructions, or expose services to public internet with default credentials and they ruin it for all of us and now its forced.. I spin up pfsense VMs all the time, and sometimes I know just going to wipe it clean after done testing what I am testing.. Its never going to be exposed to any hostile network, let alone the internet. So do I really need to change the default admin password.. Now I have to move forward in the setup.

[Gertjan]

@Antibiotic said in pfSense hacking:

Is it possible to hack pfSense firewall from outside. I mean any official evidence, that someone did this?

The one that manages to do so has no interest in making his findings public.
I'll explain my reasoning after this :

Condition :
Download a copy from here : https://www.pfsense.org/download/ and install it on a bare bone, of the mill Intel based device with two network cards.
Use the keyboard for two things : assign a new password, and assign the two interfaces LAN and WAN.
Leave every other setting to default.
Hook up the WAN to your upstream 'internet' connection. Leave the LAN not connected.
From now on, leave it there. Just watch, inspect the system, look at the logs. See what happens.

Two things will happen : the system fails because of hardware degradation : the disk (SSD) wares out, caps start to explode, these kind of things.
At this stage : every packet coming into the WAN interface will get dumped into /dev/null, as no rules exist that tell the system to do 'something' with it.
If to much traffic comes in, what will happen when the system gets DOSsed, it might fail, the NIC and or driver will lock up. The system will panic and 'crash'.

This scenario can be done with every device you hook up to an Ethernet cable.
For example : when you rent a dedicated server, like one of these, you get a motherboard in a box, it's powered on, cooled, and has one NIC that is connected direct to the Internet. So just two wires go in : power and an Ethernet cable.
Install an OS. ANY OS.
Things already start bad : SSH on port 22 access is probably enabled.
You've received a password (the user will be 'root') and up to you to access your new server, change the password, disable SSH password login altogether and activate "public key only".
From now one, leave your server there. Just pay the bill. Don't do anything with it.
You'll find your server there many years later on. So put in in your will, so your kids can continue to 'watch' it. And so on ....

The conclusion is : things go bad as soon as humans (also known as the system admins) start to do "things" with a system. People don't know what they are doing, missed the real, or just - all - the impacts of their actions.

Also, IMHO, pfSense isn't any different as any other router out their, ISP routers included. And right now, billions of these routers (firewalls) are in front of every Internet connection in every house on planet earth. Do they risk something ?

In the end, there is only one thing that protect everybody : it isn't no the router, but the admin willing to learn how to handle his equipment.

[Antibiotic]

@SteveITS Do you mean OpenVPN server to expose world or OpenVPN as client as well?

[Gertjan]

@Antibiotic said in pfSense hacking:

Do you mean OpenVPN server ....

Half off planet earth was using OpenVPN in 2020 and 2021 for known 'reasons'.
The equation still stands :

Let X = OpenVPN
If X is set up correctly, then 
   NO issues
else
   Yes, majors issues.

I assigned OpenVPN to X as an example but you can assign anything you want to X and the equation stays valid.

An "OpenVPN client" doesn't expose anything. It behaves like a web browser.

[mer]

What @Gertjan says in his first reply is a good exercise for anyone hooking anything up to the Internet.
Make sure it's default deny on WAN, don't expose any ports, plug it in and just watch the logs. It can get scary very quickly.
But it does make one aware of the dangers and why you need to everything to minimize your exposure.

[Antibiotic]

@mer said in pfSense hacking:

Make sure it's default deny on WAN

I have only this:

Is it default deny?

[mer]

@Antibiotic To the best of my knowledge/understanding, by default on WAN pfSense will drop any incoming traffic unless it is a response to outbound traffic.

Go to your pfSense GUI, diagnostics, command prompt and enter the command pfctl -sr
That will list all the rules as generated, in the order they may be evaluated.
Near the top are block drop rules for IPV4 and IPV6 without a quick keyword. Those are your default deny on the interfaces.
pfSense is "last match wins" on the rules, order of evaluation starts at the top. The quick keyword on a rule terminates further rule processing on a match.

[johnpoz]

@Antibiotic all interfaces have default deny out of the box.. It is a hidden rule, no point in showing something that is on every interface and can't like change it or anything. If you do not have a rule to allow the traffic then it will be denied.

The reason those 2 rules are there and shown, is you can disable them.. But they are top of the list always.. Lets say you open up some port.. Your webgui port for example on your wan. Those rules would make sure that the source IP trying to talk to that service you opened is not rfc1918 or bogon.

Neither of which should route on the public internet anyway - so if your seeing traffic to those its most likely noise from your ISP network.

[SteveITS]

@Antibiotic said in pfSense hacking:

@mer said in pfSense hacking:

Make sure it's default deny on WAN

I have only this:

Is it default deny?

Yes you have no allow rules there. And as the message says all incoming will be blocked.

[Gertjan]

@Antibiotic said in pfSense hacking:

Is it default deny?

A firewall is what it says : hard to pass through. At least, that was the word they came up with in the middle of in the last century. These days, I tend to think my pfSense has a back hole in front of my WAN, 'visible' from the outside.
With this perspective in mind, why would you block a black hole with 'stop' rules in front it ? Stop signs that say : [first stop rule] no RFC1918 here. And [second rule] unknown flying sorcerers neither.
Just let them have it
As it should be obvious that anything imaginable (by humans) will get into the black hole, and from there its not our problem anymore.
Block rules do use CPU cycles .... why waste cycles on stuff that's going to be annihilated ?
So : no need to block access to black hole. It's a bit 'useless'.

The perfect WAN firewall list is ... an empty list.

There always will be some #d#ts that try to poke in a black hole to see if the can manage to do something with it.
They are just proving that physical laws exist, but they just didn't get that yet.
Using a firewall is actually a responsible social thing to do : its keep #d#ts busy and from the street, as they might be doing other things out there ^^

edit : wait : your stop rules can have a useful function !

This :

is useful so you can see if there are actually #d#ts out there that send you packets that match, thus hit, the rule.

Your 'Not assigned by IANA' has actually a double score counter : these packets shouldn't even be routed to you by your ISP, so they couldn't never reach you, as "non assigned networks" can't be used / routed on the Internet.
So maybe your on to something : your ISP is also a #d#t