It is primarily GUI-driven, which won't cut it for automation, version control, or some auditing.
AFAIK it is still based on m0n0wall. The init scripts are written in PHP. There is (or was when I used it years ago) one big PHP script with a bunch of includes. If any part of the PHP script fails the rest may fail.
This led to a bunch of problems with packages. For example I installed the RADIUS package through the web UI, decided I didn't want it, removed the package through the web UI. Removing the RADIUS package removed something the large PHP init script was trying to include, which led to the script exiting immediately with an error.
The PHP script was also reasonable for loading the firewall rules, but it exited before loading the rules. Which resulted in a booted internet gateway with _no firewall_ (allow any).
This aspect of pfSense may have changed, so I'm not trying to hate on it, just trying to point out that it may have shortcomings for some use cases.
I've managed straight pf on OpenBSD for gateways/firewalls. pf is very nice to work with, much nicer than iptables/tc for internet gateways. But that also won't scale to large enterprises or datacenters . The amount of data is too much for OpenBSD and generic hardware, at least as for as I've seen. At one employer the largest Palo Alto Networks firewalls couldn't handle our office network traffic, they had to be replaced by firewalls from another vendor.
So it really isn't fair to compare FortiGate firewalls, some models of which can do 300+ Gbps, with 40/100 GbE ports, to a little box running pfSense.
You forgot: and an ssh backdoor
Fortunately (for us), the large consulting firms disagree with your assessment.
Case-in-point: AES-GCM, including AES-NI support, and support for same for IPsec.
There are other, more minor contributions, such as the new 'tryforward' code (replaces what was 'fast-forward', but doesn't break IPsec). r290383
Or r290028, where we eliminated the performance impact of IPsec (which is now on by default in -CURRENT).
I could go on to detail around 30 recent changes to FreeBSD, but I think the point is made.
In any case, it's a bit more than "bundling it all up and slapping a web interface on top of it", as you assert, but you're not the only person who thinks this way.
Your point that we leverage others work is correct.
Have at it.
What is your definition of "quality code"? (Without going in to a huge rant.)
https://www.reddit.com/r/BSD/comments/391nyj/pfsense_conside...
1. Clear description of every feature and requirement in system.
2. Mathematical spec of those where English ambiguity could effect results.
3. High level design with components that map 1-to-1 to those.
4. Low-level, simple, modular code mapping to that.
5. Source-to-object code verification or ability to generate from source on-site.
What people in faux security mocked as mere "paperwork" or "red tape" were actually pre-requisites for defeating subversion my mentally understanding a system from requirements all the way to code. A problem like this would've been impossible in such a system because it would be beyond obvious and probably unjustifiable with requirements tracing.
Every story like this further validates the methods that consistently produced systems without all the security problems plaguing modern security products. Situation isnt inevitable or even necessary: merely an inversion of scientific method where security companies and professionals consistently refuse to use what's proven to help and reuse tactics proven to fail. It's gotta stop.
That it wont is why I favor liability legislation tied to a reasonable baseline of practices. We can use an inexpensive subset of what worked in highly assured systems. 80/20 rule. Baseline would look more like Secure64 or HYDRA firewall than shit like Fortinet and Juniper. Hackers would work for exploits. I know Im dreaming, though, as DOD and NSA just dropped mandate to EAL1 w/ 90 day review for some stuff. (Rolls eyes).
We're kidding ourselves to put our faith into these closed-source products and that's only just now becoming clear. Open source. It's the only thing that will work for us long term.
And no, OSS with reproducible builds is nowhere near enough for software to be trustworthy. It's why even Orange Book had more than one sentence in its feature and assurance activities recommendations.
Let's put it to the test though. If Im right, most the majority of OSS software will be similarly to proprietary full of easily-prevented holes, undocumented/barely-clear functionality, and difficulty even building it. Whereas high assurance systems would've had the opposite attributes while faring well during professional pentesting w/ source.
One of us was right for a decade straight. Maybe it's because the principles and practices I promoted... work? Evidence in the field is on my side. Neither OSS nor good builds are enough.
Not sure what your definition of modern is, but this is a pretty old school "support interface".
PC and Internet eras were really getting going around that same time. Languages and approaches that introduce vulnerabilities one way or another became huge. INFOSEC research and products shifted toward all kinds of tactics for hardening, analyzing, monitoring, and recovering such inherently, insecure stuff. Revisionism kicked in where people forgot the old wisdom, starting to reinvent it slowly, plus how and why they got there in the first place. The products, both regular and security, had tons of vulnerabilities old methods and tools prevented. I call this the Modern Era of INFOSEC. It's still running strong.
Good news is the Old Guard published tons of papers and experience reports telling us what to do, what not to do, and so on. There's a steady stream of CompSci people and some in industry building on that. Keeps advancing. Even mainstream IT and INFOSEC adopted some of the strategies. Rust, "side channels" analysis, unikernels, trusted boot... all these are modern variations (sometimes improvements) on what was done in 70's-early 90's. So, it's not dead but it's mostly ignored and barely moving.
That's what I'm thinking when I see another modern firewall or whatever with less security than the guards from the 80's that predated them. You'd think they'd have learned something by now past just the features. The assurance activities were there for a reason. Guards, if you were wondering... https://en.wikipedia.org/wiki/Guard_%28information_security%...
Good essay on security assurance from engineering rather than subjective point of view that development often takes:
What does a mathematical specification of "secure" look like?
We develop a tool to verify Linux netfilter/iptables firewalls
rulesets. Then, we verify the verification tool itself.
Warning: involves math!
This talk is also an introduction to interactive theorem
proving and programming in Isabelle/HOL. We strongly suggest
that audience members have some familiarity with functional
programming. A strong mathematical background is NOT required.
TL;DR: Math is cool again, we now have the tools for "executable
math". Also: iptables!
Credibility is in a way binary - you either have it or don't.
https://www.schneier.com/blog/archives/2015/12/back_door_in_...
https://www.shodan.io/search?query=product%3Afortinet
Of course not all of the results also expose SSH but some do.
USG probably would have had better luck if they pitched backdoors as a consumers protection measure and had a law mandating that:
1. Software companies must always have a remote and practical method to correct dangerous flaws in the software they issue.
2. To protect consumers' valuable records, all device manufacturers must back up all data on any device the produce. Such backups should ensure that the data is always accessible by the user even if the user were to lose their password or keys.
It would be a security disaster, and it already is.
Source: Fortinet admin
I don't quite understand the special handling. Looks like it takes a byte from the server's output, hashes a special string containing that byte, and passes that back to the server. This is the backdoor.
Edit: Maybe that "special handling" is just standard protocol and it's just sending a plaintext password. I dunno.
EDIT: 5.0.7, not 5.0.2
On top of that I am now in an organization where we're starting to implement security levels on networks, anything above level 0 requires 2FA to access and you can never connect a lower level to a higher level. So best practices are a good thing.
Doesn't help. The attacker just has to get user-level access on some machine on the intranet or in the data center, which can be obtained via other attacks. Then then can attack other machines via the local network to escalate.
This is where VPN services like Junos (ironically Juniper) work well because they give you 2FA and group based access. So if you're not in the networking admins group then you have no reason to have SSH access to the networking equipment.
if you want to do backdoor probably should do it better, something like port knocking to start with at least.
Come to think of it, backdoors are fundamentally "security by obscurity". Or insecurity through obscurity, depending on your POV.
This one is. But they aren't always.
For example, if a manufacturer put in a support/recovery backdoor, documented it, and utilised a secret that only the end user and manufacturer should know (e.g. something on the physical label), then that would be a backdoor while not relying on any obscurity for its security (or no more than a password does).
The biggest difference between a "good" backdoor and a "bad" one is if it is documented. If the manufacturer is too scared to document it then it likely sucks and they know it.
Similarly hardcoding someone's SSH public key isn't going to help anyone else gain access just by knowing it's there, is it?
People that discover these these types of exploits each machine code for breakfast.
For this, there'd have to be a specific function in some Fortinet products for handling the special challenge/response backdoor.
A magic string like `"FGTAbc11*xy+Qqz27"` in firewall source code is going to jump out at you. Unlike an extra goto...
Do you mean "hopefully someone else will"? Because that's what I mean.
Does this sound familiar?
Maybe it is time we build open hardware and software for important things. Can't trust anyone.
Doing audits of open hard and software is a whole other problem however.
> It leaves no traces in any logs (wtf?). It keeps working even if you disable "FMG-Access". It won't let you define an admin user with the same name to mitigate it, so make sure that SSH access on your devices is at least restricted to trusted hosts!
I really believe this has already begun with the FANG[0] tech giants with Open Hardware initiatives. At some point you can begin pooling your resources to create safe, secure, and fast platforms that everyone can use.
[0] facebook, amazon, netflix, google