On Mon, Dec 5, 2011 at 9:51 PM, Steve Edwards <asterisk....@sedwards.com> wrote: > (This horse just won't stay dead...) > > My apologies if I mis-attribute who wrote what. > >> On Fri, Dec 2, 2011 at 11:35 AM, Jim Lucas <li...@cmsws.com> wrote: > > >>> How is using Fail2Ban less resource intensive then me writing (by hand) >>> iptable rules? > > > On Mon, 5 Dec 2011, C F wrote: > >> Sorry I wasnt very clear in my first writing, I'll try to clarify. Using >> iptables only detects one type of attack (aggressive connections). While his >> machines might be secure enough to allow any other attacks and still not >> compromise his machine, iptables will still allow them thru and therefore >> the attack will be using his bandwidth/resources, with f2b one can add as >> many rules as/when they arrive. > > > I think you are over-generalizing. > > You can write iptables rules to detect and respond to many types of attacks.
Possible. But working off the logs makes lots more sense for creating more accurate to the point rules, and to mention on the fly. > > Since F2B is just an automated front end to iptables you can have as many > rules as you need with or without F2B. Also, since packets are 'stopped' at > the same place (iptables) any bandwidth savings would only be to services > that you are running that either aren't or can't* be nailed down. You didn't get my point. If someone is trying to exploit some type of dialplan hack in slow motion. iptables will probably not detect it and your machine is secure enough that the exploit doesn't work, but the script kiddie behind the attack doesn't know that and keeps trying. Your wasting resources and bandwidth. With f2b you can have him added to iptables after the first try. Once all packets are dropped from that IP, while the attacker is still using resources/bandwidth while trying after a while they will stop as all packets are dropped. The reason they are trying is because it wasn't blocked but now that it is they will stop. > >>> Also, since both methods involve the use of iptables, where exactly is >>> the bandwidth savings? > > >> In detection. > > > How about 'in responding to an attack your iptables rules don't already > mitigate and you do have F2B rules defined for?' 'Detecting' an attack means > close to nothing if you don't respond to it :) I think you are just explaining my point. Correct me if I'm wrong. > > I'm not hating on F2B, it's just not a silver bullet nor is it appropriate > for all environments. Agreed, like another poster said, its the easy way out since it's an easy front end. The only reason for this thread is because someone mentioned he doesn't *need* it. > > Your security needs depends on your environment. At this point in time, all > of the hosts I manage for my clients exist in very limited environments and > have very small attack surfaces. They are racked in secure data centers. Speaking of which, how secure? I have biometrics access to about a dozen such centers. Once inside the center how hard is it really to do what you want? > They only accept SIP from clients with static IP addresses that we have an > existing business relationship with. They only accept SSH connections from > me. They only accept HTTP connections from me and my boss. That's about it. > I don't see where F2B adds much value for me. Well others keep their servers shut. While I'm sarcastic, I'm also trying to say its way to overdone. A good IDS/IPS will do, there is really no reason to this. Except in environments that require it, in my opinion national infrastructure etc. > > *) Lots of admins think they can't limit access to servers because they have > 'mobile' users. Your users probably don't need to access your servers from > every single place on the Internet. If your users don't come from China, > North Korea, Iran, etc, you can block entire regions with a few rules and > eliminate 80% of probes and attacks from reaching your servers in the first > place. Apologies in advance if you happen to live in some of these regions > -- feel free to `s/China, North Korea, Iran/United States, Canada, > England/g` > > -- > Thanks in advance, > ------------------------------------------------------------------------- > Steve Edwards sedwa...@sedwards.com Voice: +1-760-468-3867 PST > Newline Fax: +1-760-731-3000 > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
