pfSense vs Some Other FW
-
Last week, I installed a pfSense box for some company with multiple branches. They had been using a slightly high-end firewall from some vendor. (For the sake of discussion, I'll call them FWVendor X and the device itself FWX).
The IT technician asked me to open a certain port (say port 1066). Being an IT guy, he knew the risk he was taking but he told me that the port had been being used by some front-end DB application in a few branches for quite some time to access an MSSQL instance on their Windows 2016 server. (I don't know what version of MSSQL.) Yes, I know that was unprofessional of me, and I'll continue regretting doing that for a very long time.
The next day, while I was tuning the new box remotely, I realised that the virtual machine running on the Windows 2016 server was not responding. I phoned the man and he tried to RDP to the server over VPN, to no avail.
Next day early in the morning, he arrived at the scene. The server had been hacked and all the important files crypto-locked. (We later found out that some other companies had been hacked as well.)
Of course, I opened a port and some wise guy somewhere took advantage of it. But the problem is, the IT guy that had worked there previously insists that it was because of pfSense that the server had been hacked. He maintains that FWX (somehow) had been warding off the attacks, and it was when we installed pfSense that we got hacked.
That does not make sense to me for two reasons:
- How could it know that the port 1066 was being used by MSSQL in the first place?
- How could FWX tell a legitimate MSSQL packet from a malicious one?
I believe it was by sheer bad luck that it happened. But still, I can't stop wondering: Can there be a shred of truth to it? Was there anything I could have done on pfSense to prevent it?
-
@scilek Two different angles:
1: Did you open the port to the whole wide internet (I assume so since you got hacked)? The simple “prevention” mechanism that FWX probably had been configured with, is that the FW port rule was resticted to only allow sessions from specific well known hosts (IPs) - the other branches of the company fx.
You should definitively have made such a restriction on pfSense as well since we are talking about SQL - THE most used attack vector.2: Firewalls can be equipped with a deep packet inspection system that can look deeper into the packets than just protocol and port compliance. This is usually called IDS/IPS (Intrusion Detection System/Intrusion Prevention System). Depending on the system being used to do this it might very well have been capable of detecting it was SQL traffic happening on the port, and if the exploit being attempted is well known (pattern based rules - much like antivirus), it could also have been setup to block it (and not just alert about it).
PfSense also has such a system in a package called “Suricata”. But setting that up and really making it usefull with realtime blocking requires quite a lot of skill. -
