Here's the deal. pfSense is free software that rivals commercial software in many cases. Due to the fact that it's free its much easier to add more machiens to the mix. Let's use the FTP Server as an example. Should you run it on your primary firewall? Hell no. Should you setup an additional box running pfSense + a Firewall that is not a firewall? Hell yes.
The reason that we want to intergate these features into pfSense is not to always run them on one machine. Now with that said, does it make sense to run 3 firewalls and 20 users? Most likely not. At any rate, lets put this bikeshed to rest and move on. My inbox will thank you later. Thanks! On 9/24/05, Chris Buechler <[EMAIL PROTECTED]> wrote: > Dan Swartzendruber wrote: > > > At 09:07 PM 9/23/2005, you wrote: > > > >> Oh, I understood you. > > > > > > In that case, I guess we'll have to agree to disagree. This platform > > deliberately has the capability of running various services on it > > (unlike m0n0wall.) If someone has the CPU power and RAM to run things > > like squid and clamav already, I really fail to see how making that > > service available to the inside MTA causes a realistic chance of DoS > > unless the MTA is grossly misconfigured. > > > > both of you arguing are right and wrong. :) > > In theory, is this a great idea? No. If you have the resources, it's > certainly best to segregate services appropriately. At work, I would > never integrate AV and the firewall, or IDS/IPS, or any of the many > other things that pfsense either allows now or will allow in the > future. But I do side jobs for companies whose annual revenues are less > than our IT budget at work, and the reality is in those circumstances, > if it's going to be done at all it will have to be integrated. The > alternative is to not have it at all (whatever "it" might be that you're > running on your firewall that you wouldn't normally want to run on your > firewall). > > At a company with 20 or less users (likely > 20 in many scenarios), you > can't segregate things appropriately because you'd end up with an > unaffordable ratio of servers to users. In some of those environments > with 3-5 users, you'd end up with more servers than users. That's > obviously not feasible to setup and maintain in most every environment. > > With things like this, there is no clear cut "do it" or "don't do it" in > the real world. It depends on the level of risk inherent in the given > environment, the risk tolerance in the environment, the cost of the > associated risks, how much downtime costs, and the amount of money the > company can afford to spend on IT. If, for example, you get flooded > with viruses and it takes down your firewall, well I'd rather see that > than have the viruses happily passed along. <insert similar scenario > for any other service running on the firewall that shouldn't typically > run on a firewall> Usually better to have it in a place that isn't > ideal than to not have it at all. > > -cmb > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
