full-disclosure - RE: Example firewall script

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu Sep  1 17:24:27 2005
From: dufresne at winternet.com (Ron DuFresne)
Subject: RE: Example firewall script 




http://www.ranum.com/security/computer_security/papers/a1-firewall/




Thanks,

Ron DuFresne



On Sat, 27 Aug 2005, ericscher@....com wrote:

>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> =================================
> ORIGINAL MESSAGE:
> -----------------
> Date: Sat, 27 Aug 2005
> From: "Exibar"
> Subject: Example firewall script
>
> >The absolute worse Firewal rule
> >you can have:
> >
> > Allow ANY ANY
> >
> >The best:
> >
> >  Deny ANY ANY
> =================================
>
> REPLY:
> -------
>
> Actually, that's not true.
> I would agree that as a general rule of thumb
> you should have a deny statement at the end
> of every ACL. In fact, Cisco places an implicit
> DENY ANY ANY at the end of their ACL's
> automatically.
>
> However, Access Control Lists are not firewalls.
> Yes, we use them as firewalls, but that's not what
> they are.
>
> ACL's ARE TRAFFIC SHAPING DEVICES.
>
> As traffic shaping devices, they can be used for
> security, but they are also used for management
> purposes. For instance; many Autonomous Systems
> are multi-homed. There are decisions to be made
> about how traffic will flow in and out of the AS.
> You also have to decide if you wish to be a
> transit AS or not.
>
> ACLs are the tool that you use to control your
> traffic.
>
> While an ACL being used as a security device
> should have a deny statement at the end, proper
> construction of the ACL is more about following
> the proper construction rules.
>
> This is actually a huge subject, far too big
> for an individual e-mail to a list.
>
> But there are some basic rules to keep in mind:
>
> ACL's analyze traffic from top to bottom, so
> keep your most specific entries at the top,
> with more general entries near the bottom;
> and do your "permits" before your "denys".
> That means you deal with hosts first, then
> subnets, then  networks, and at each level
> you have your permit statements  before your
> deny statements. The reason for this is because
> once a packet matches a line, it's dealt with
> right then and there. You don't want to have
> a packet thrown away just before a line that
> would have permitted it.
>
> There are also issues of what KIND of ACL to
> use and where  to place them; Inbound or Outbound.
>
> In terms of the original question, the only
> difference between a "good" line item or a
> "bad" line item is whether or not the syntax
> is correct.
>
> The only difference between a "good" ACL
> and a "bad" ACL is  whether or not it's
> structure is properly designed and whether
> or not it's placed in the proper location.
>
>
> This subject REALLY calls for a book, not
> an e-mail response. I've said very little
> in this post and look at all the room
> it took up.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

-- 
"Sometimes you get the blues because your baby leaves you. Sometimes you get'em
'cause she comes back." --B.B. King
        ***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.