IDS/IPS and antivirus on 2.1 release
-
Hi
It will be great If you add IDS and Antivirus packages in default installation or a user can select custom packages during installation. -
Some of these features will not work on every system like ebedded systems.
So if the user needs these packages/option then he can simply chose snort from package manager menu. -
From Pfsense site:
"This project started in 2004 as a fork of the m0n0wall project, but focused towards full PC installations rather than the embedded hardware focus of m0n0wall. -
@amirkabir:
From Pfsense site:
"This project started in 2004 as a fork of the m0n0wall project, but focused towards full PC installations rather than the embedded hardware focus of m0n0wall.I do NOT want IDS with zillions of false positives and daily hours of babysitting, nor do I want useless antivirus such as ClamAV - embedded or not. Kindly install those yourself if you find a need for them.
-
@amirkabir:
Hi
It will be great If you add IDS and Antivirus packages in default installation or a user can select custom packages during installation.That is already possible with Menu>>Systems>>Packages.
Just install the packages you want and configure according to your needs, viz snort, HAVP, squid, squidguard, pfBlocker among others.
From Pfsense site:
"This project started in 2004 as a fork of the m0n0wall project, but focused towards full PC installations rather than the embedded hardware focus of m0n0wall.Quoting something from almost the beginning of this century. A lot of water has flowed under <name your="" prefferred="" river="" here="">since then. With PHK's NanoBSD script commit to FreeBSD, it added a new dimension which became a part of pfSense now!</name>
-
There is a line between required features and base system bloat. Packages address needs beyond the boundary.
IDS and AV require frequent updates to stay current and functional. The base system stays stable for many months at a time. Packages allow those to be updated frequently and kept out of the base system.
I would not want to roll a whole new firmware release just because snort decided to change their rule format (again) or because clamav had a CVE or DB format change (again).
Those work perfectly as packages, and I don't see that ever changing.
-
I think basic functions such as Squid and Unbound should be part of the feature set instead of packages that work sometimes.
Maybe time to fork off an embedded hardware version so Pfsense can move forward with more energy without this baggage?
-
I think basic functions such as Squid and Unbound should be part of the feature set instead of packages that work sometimes.
And it will magically start to work always as soon as it's installed by default. :D I have no use for squid, and I have no use for unbound since we maintain DNS in active directory.
Maybe time to fork off an embedded hardware version so Pfsense can move forward with more energy without this baggage?
Bloat != move forward. If I wanted something similar, I'd install Untangle.
-
I think basic functions such as Squid and Unbound should be part of the feature set instead of packages that work sometimes.
Maybe time to fork off an embedded hardware version so Pfsense can move forward with more energy without this baggage?
Then you also shift the development burden of those away from the community helping with packages to the core team which is already busy keeping the main system in line. And see above, re: slow updates.
These features work best as packages. If they only "work sometime", then take it up with the package maintainers. Squid 2.7.x and SquidGuard work perfectly all the time in thousands of installs.
The quality of a function is not dependent on whether it's a package or in the base system.
-
I second jimp because it is always better to separate the base OS from additional whisltes and bells. jimp is right to point out that the base system remains stable for a longer period of time than the packages.
One can install additional whistles and bells on top of base OS as an when required. The most exciting thing about FreeBSD is PHK's NanoBSD scripts which pfSense seemed to have adopted to separate the OS from packages (although there doe snot seem to have adequate guidelines for packages (pbi in particular).
The only problem I found was when one wants to make changes to kernel level parameters.
PS: @jimp: is dev mailing list active? I am asking because I encountered some problems and posted that to the dev list a few days ago, and yet there does not seem any activity. ;-)
-
Plus Cisco just bought Sourcefire. Which means snort and clamav are now both Cisco products. Looks like we need to find replacements ASAP. :-)
@Zenny - dev list is hit and miss. Lots of us are quite busy and don't have a ton of time to respond to things, but depending on what it was, the Dev list isn't always the best place for it.
-
Plus Cisco just bought Sourcefire. Which means snort and clamav are now both Cisco products. Looks like we need to find replacements ASAP. :-)
Not a good news! :( However, checked seclists and sourcefire claimed that it shall remain open sourced, (http://seclists.org/snort/2013/q3/363). Since snort and clamav are GPLed, I guess they Cisco is required to release further changes, don't they?
@Zenny - dev list is hit and miss. Lots of us are quite busy and don't have a ton of time to respond to things, but depending on what it was, the Dev list isn't always the best place for it.
In that case, is it fine to post compilation of pfSense dev issues here? I had just visiting the dev list because it was categorically instructructed so in the link (http://devwiki.pfsense.org/DevelopersBootStrapAndDevIso) you referred to me somewhere in this forum. ;-)
-
However, checked seclists and sourcefire claimed that it shall remain open sourced
Look at what happened to MySQL.
Since snort and clamav are GPLed, I guess they Cisco is required to release further changes, don't they?
Nothing in GPL requires you to make new versions publicly available.
-
@amirkabir:
From Pfsense site:
"This project started in 2004 as a fork of the m0n0wall project, but focused towards full PC installations rather than the embedded hardware focus of m0n0wall.I do NOT want IDS with zillions of false positives and daily hours of babysitting, nor do I want useless antivirus such as ClamAV - embedded or not. Kindly install those yourself if you find a need for them.
Just because some functionality is well integrated, tested and part of the distribution doesn't mean you have to use it and enable it.
There's plenty of functionality in pfSense that I don't use, and a bunch of packages that sort of bite each other in unpredictable way, because there are no "standard" packages and the various interactions are not part of the testing.There may be other valid reasons not to include package <x>as part of the distribution, but the fact that n% of users won't use it or don't need it, isn't one of them.</x>
-
The quality of a function is not dependent on whether it's a package or in the base system.
Quite true, but the integration needs to be better. e.g. naming conventions: the base system names the menus usually BY FUNCTION, while packages tend to name the menues BY PROJECT NAME, which frankly is annoying.
Similarly, the packages as we have them now, do not signal in any way what is mutually exclusive, e.g. Dansguardian does not exclude HAVP and/or SquidGuard from being installed, which is something that could be solved with meta packages that are sorted by function, such that one can install only one IDS/IPS system, only one content filter, etc.
It's probably the majority of users that have one or more packages installed, but unfortunately, due to a lack of conventions and/or a system of enforcing these conventions, the fit and finish of the entire installation quickly takes a nose dive once a few packages are installed, which makes it feel inferior to other products, just because things get inconsistent, not because things really are inferior in substance.
-
Plus Cisco just bought Sourcefire. Which means snort and clamav are now both Cisco products. Looks like we need to find replacements ASAP. :-)
Suricata would seem to be a good choice, seems to also scale better and have other advantages, while still being able to work with Snort rules, if required.
ClamAV can be forked, if need be, but of course updating the rules may become an issue after a while. -
Would you trust anything coming out of Navy/HLS?? It means a lot of backdoors for the US gov to use.
Could we fork of SNORT instead and establish a community ourselves?
-
Would you trust anything coming out of Navy/HLS?? It means a lot of backdoors for the US gov to use.
Could we fork of SNORT instead and establish a community ourselves?
If it's open source, yes. Otherwise one couldn't use Tor, or for that matter the entire internet, which is just a renamed milnet/[d]arpanet.
If it were some close-sourced thing, that would be a different issue.
-
I think the Snort code is open-source but updates is something else.
But if they implemented SNort community rules anyway, then a merger would be good and the updates along the way.
-
Just because some functionality is well integrated, tested and part of the distribution doesn't mean you have to use it and enable it.
There's plenty of functionality in pfSense that I don't use, and a bunch of packages that sort of bite each other in unpredictable way, because there are no "standard" packages and the various interactions are not part of the testing.There may be other valid reasons not to include package <x>as part of the distribution, but the fact that n% of users won't use it or don't need it, isn't one of them.</x>
Actually, it is a perfectly valid reason. We recently removed OLSRD and RIP (routed) from base for that very reason. They were better as packages, they were no longer used by enough people to justify keeping them in the base system.
Quite true, but the integration needs to be better. e.g. naming conventions: the base system names the menus usually BY FUNCTION, while packages tend to name the menues BY PROJECT NAME, which frankly is annoying.
That's no reason to put them in base. Just fix/change the menu names. But that's a Bikeshed discussion for another thread. Naming by function breaks the moment you have two packages that have the same function but different actual names, and you can't tell them apart.
And again, if a package doesn't work like you want, submit patches or convince the maintainer to fix/make changes. That does not have any relationship to it being in base.
Similarly, the packages as we have them now, do not signal in any way what is mutually exclusive, e.g. Dansguardian does not exclude HAVP and/or SquidGuard from being installed, which is something that could be solved with meta packages that are sorted by function, such that one can install only one IDS/IPS system, only one content filter, etc.
It could use some "conflicts" type checking but the examples you gave aren't always really conflicts. I'm sure someone has a valid reason for combining those in some weird way, and if we stopped them from being installed, something else would break.
It's probably the majority of users that have one or more packages installed, but unfortunately, due to a lack of conventions and/or a system of enforcing these conventions, the fit and finish of the entire installation quickly takes a nose dive once a few packages are installed, which makes it feel inferior to other products, just because things get inconsistent, not because things really are inferior in substance.
If you have some examples of this with non-beta/non-development packages, feel free to cite actual examples and not generalities that aren't really true. Lots of us run many packages with no problems. Certain specific packages may have issues, but again, that's a problem with the individual package's code that isn't going to magically get fixed by bringing it into the base system.
If you want better packages, then help the maintainers make them better, submit patches to make them better, or fund the maintainers to help them get better.
