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] [thread-next>] [day] [month] [year] [list]
Message-ID: <000701c5ab34$adf1c800$c864a8c0@dopehead>
Date: Sat Aug 27 19:18:23 2005
From: jan at boyakasha.dk (Jan Nielsen)
Subject: RE: Example firewall script 

I think the rules explained here are not intended to be actual rules in
a firewall, but more of a way to explain what is secure and what is not,
correct me if im wrong. Oh and btw, acl's ARE used in CBAC (cisco ios
fw) they are just a tad more intelligently created than in a regular
acl.


Jan

-----Original Message-----
From: ericscher@....com [mailto:ericscher@....com] 
Sent: 27. august 2005 18:42
To: full-disclosure@...ts.grok.org.uk
Subject: [Full-disclosure] RE: Example firewall script 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++

=================================
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/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ