Re: [pfSense Support] antivirus and etc
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. 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]
Re: [pfSense Support] antivirus and etc
At 04:12 PM 9/24/2005, you 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. 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. I was probably not clear then. I understand what you're saying (and agree.) I just didn't appreciate people making cheap shots about hobbyists and shooting oneself in the foot. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] antivirus and etc
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. 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]
Re: [pfSense Support] antivirus and etc
If you refer to my solution (squid+redirector+clamav), I have to say that yes, clamav is running on the local machine, yes it uses tcp socket, but no, it cannot be accessed from outside 127.0.0.1 (the daemon is listening only on lo). First, because of security reasons (that other guys altready told you); second, because this kind of operation (scanning incoming traffic) is something that slow down the navigation a lot! If you have to contact a clamav service outside the box, I expect even worse results. This is my opinion.. but as Gary already told you, if someone really wants to shoot himself in the food... Ah, remember: I am _not_ preparing a package for clam! In the moment, I have only manual updates: I need to spend my time to make it wok, not to make it easy to install..Maybe in a futureOn 9/24/05, Gary Buckmaster <[EMAIL PROTECTED]> wrote: So you're opening up a port on the firewall to a critical service which hasthe potential to DoS the firewall for a feature that only a handful of IT hobbyists might consider using?-Original Message-From: Dan Swartzendruber [mailto:[EMAIL PROTECTED]]Sent: Friday, September 23, 2005 7:27 PMTo: support@pfsense.comSubject: RE: [pfSense Support] antivirus and etcAt 08:22 PM 9/23/2005, you wrote:>Dan,>>You're opening up a real potential for DoSing the firewall if you have an >especially busy Exchange server that gets hit by some mass mailer worm. I>would rather have a separate instance of clamav running on my postfix (or>whatever MTA you choose to love) box.Well, I did say that was an option. That said, I'm not sure I buy that. Keep in mind, the clamav instance running on pfsense will onlybe as busy as the MTA makes it. Most non-enterprise MTAs (like mine)will only allow a handful of inbound connections at a time, and until the virus check is complete, no further smtp connections will beallowed. I guess it's a decision to make depending on the CPUhorsepower available on firewall and mail server.- 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]
RE: [pfSense Support] antivirus and etc
At 09:31 PM 9/23/2005, you wrote: That's the good thing about pfSense and its developers. They do everything they can to discourage people from shooting themselves in the foot, but if you are bound and determined . . . whatever. i'd take you more seriously if you were presenting any facts in this discussion. i'm done... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] antivirus and etc
That's the good thing about pfSense and its developers. They do everything they can to discourage people from shooting themselves in the foot, but if you are bound and determined . . . -Original Message- From: Dan Swartzendruber [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 8:20 PM To: support@pfsense.com Subject: RE: [pfSense Support] antivirus and etc 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. - 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]
RE: [pfSense Support] antivirus and etc
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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] antivirus and etc
Oh, I understood you. -Original Message- From: Dan Swartzendruber [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 7:48 PM To: support@pfsense.com Subject: RE: [pfSense Support] antivirus and etc At 08:45 PM 9/23/2005, you wrote: >So you're opening up a port on the firewall to a critical service which has >the potential to DoS the firewall for a feature that only a handful of IT >hobbyists might consider using? I think you may have misunderstood me. I wasn't talking about making the clamd port open on the WAN, but on the LAN. - 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]
RE: [pfSense Support] antivirus and etc
At 08:45 PM 9/23/2005, you wrote: So you're opening up a port on the firewall to a critical service which has the potential to DoS the firewall for a feature that only a handful of IT hobbyists might consider using? I think you may have misunderstood me. I wasn't talking about making the clamd port open on the WAN, but on the LAN. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] antivirus and etc
So you're opening up a port on the firewall to a critical service which has the potential to DoS the firewall for a feature that only a handful of IT hobbyists might consider using? -Original Message- From: Dan Swartzendruber [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 7:27 PM To: support@pfsense.com Subject: RE: [pfSense Support] antivirus and etc At 08:22 PM 9/23/2005, you wrote: >Dan, > >You're opening up a real potential for DoSing the firewall if you have an >especially busy Exchange server that gets hit by some mass mailer worm. I >would rather have a separate instance of clamav running on my postfix (or >whatever MTA you choose to love) box. Well, I did say that was an option. That said, I'm not sure I buy that. Keep in mind, the clamav instance running on pfsense will only be as busy as the MTA makes it. Most non-enterprise MTAs (like mine) will only allow a handful of inbound connections at a time, and until the virus check is complete, no further smtp connections will be allowed. I guess it's a decision to make depending on the CPU horsepower available on firewall and mail server. - 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]
RE: [pfSense Support] antivirus and etc
At 08:22 PM 9/23/2005, you wrote: Dan, You're opening up a real potential for DoSing the firewall if you have an especially busy Exchange server that gets hit by some mass mailer worm. I would rather have a separate instance of clamav running on my postfix (or whatever MTA you choose to love) box. Well, I did say that was an option. That said, I'm not sure I buy that. Keep in mind, the clamav instance running on pfsense will only be as busy as the MTA makes it. Most non-enterprise MTAs (like mine) will only allow a handful of inbound connections at a time, and until the virus check is complete, no further smtp connections will be allowed. I guess it's a decision to make depending on the CPU horsepower available on firewall and mail server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] antivirus and etc
Dan, You're opening up a real potential for DoSing the firewall if you have an especially busy Exchange server that gets hit by some mass mailer worm. I would rather have a separate instance of clamav running on my postfix (or whatever MTA you choose to love) box. -Gary -Original Message- From: Dan Swartzendruber [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 5:12 PM To: support@pfsense.com Subject: [pfSense Support] antivirus and etc It seems to me that if someone is going to port clamav as a package, please make sure that clamd can be run as a TCP daemon. Since clamav would need to be running for any kind of squid proxy to scan incoming pages, it could just as easily be available to someone running a mail server behind the pfsense. Currently, for example, I'm running postfix on a freebsd server, with clamav. If clamav were running on the pfense (for squid), I could point my MTA at the pfsense LAN IP and not run it on the mail server. Conversely, of course, if whatever squid redirector can use a network-enabled virus scanner, I could do it the other way around, and leverage my already running clamav on my Freebsd server. Comments? - 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]
