Help needed: Required core hooks to build a fwknop package
-
Hi.
I might just spend some time adding fwknop support to pfsense (scratching one of my own itches…)
The way I'm considering to do this is to use the power of pf to simply add a rule that checks the source IP to a dynamic IP table, and then make pfknop update the pf table with any IP addresses authorized through fwknop (by calling pfctl as an external command).
In the pfsense UI, then, the user should be able to select "fwknop authorized addresses" or something like that in the SRC/DST IP field. (Maybe it would later be possible to add some extra complexity, to permit different access levels, but one access level will be sufficient to scratch my particular itch, as well as the most common use case. :-)
Now, I spent some time browsing through firewall_rules_edit.php, and it seems it's not possible to do something like this the way pfsense is currently written, without changing core code. Sure, I could probably make a package to apply a patch to the core code at install time, but I'd rather not, since it sounds kinda nasty. (Also, I'd have to change the code that generates firewall rules as well...)
One way would be so packages would be able to register one or more tables (they might even turn up in the aliases UI, so that it makes some sense to the user), then the firewall rule could added just by adding a rule that matches the source IP to an alias... by registering the table it should appear in the aliases UI, and it should be possible to inspect and (maybe) flush said table on-the-fly from there. When making firewall rules, just use the table just like any other alias, just happens that that current table is managed by the external app (fwknop)...
Now, after skimming through the docs on package development -- if such a hook were in place in the core code, it should be relatively easy to make the fwknop package complete with fancy UI. I think I should be able to throw a fwknop package together, as a complete novice to pfsense packages, however as for the hooks in the core code, I'd need some help.
Even without such a hook it might be possible to throw together a mostly-workable fwknop package, if the user is instructed to make an alias manually with the proper name (so that firewall rule creation doesn't complain), and then just manipulate the underlying table behind the scenes, however, that would mean that the table would be clobbered every time the firewall aliases were applied and reloaded from config.xml, which would be kinda inconvenient if fwknop were used to control remote admin of the firewall for example...
-
For those not familiar with the name: fwknop stands for the "FireWall KNock OPerator"
There was a discussion in the past about implementing some kind of port knocking service. IIRC sullrich even started working on it.
At that time it was considered sub-optimally and put on hold because a way stronger security scheme already exists with the pfSense's VPN capabilities with certificates.Port Knocking is -more or less- security by obscurity which never proved to be reliable…
This is NOT to put your efforts down but to explain why a similar thread you may find in the forum search has ended before completion.
-
I'm not intending to deploy fwknop as anything more than a first line of defence, a way to make reconnaisance of the system harder. Fwknop is valuable as a tool to hide the existence of a certain service, and to reduce the surface area of possible attack. This is true whether you use fwknop to protect access to a VPN service or to protect access to SSH.
For example – ssh is a strong security measure, in theory. When working properly, I trust it to keep the bad guys out. However, a zero-day exploit in ssh would make it possible to gain access if the firewall port is unconditionally open. The same could be said about VPN services like OpenVPN.
In other words, I'm not expecting fwknop to be the solution to all security problems, but rather to be an extra layer of obscurity in a defence-in-depth security scheme. What they can't see, they can't attack. And as a first layer of defence, I'd argue it's more secure than any other scheme, because it's 100% stealthy to any attacker who isn't able to sniff the network, and because the code is so small that finding a security hole will be that much harder. Finally, breaking fwknop security barely even gets you in the door.
Also fwknop is more advanced than simple port knocking. All authorization is done in a single packet, which is protected by strong encryption, and is not vulnerable to replay attacks, like other port knocking schemes are.
Either way, the feature I'm requesting help with is not specific to fwknop itself, but will be useful for other security schemes or even VPN servers that require creation of custom firewall tables.