ACL-confusion

I have gotten confused with the many posts regarding ACL
Could someone kindly tell me the Terminal code for removing the ACL on this file: (as revealed by Disk Utility)
ACL found but not expected on "Applications/Utilities/Disk Utility.app/Contents/Frameworks/DUSupport.framework/Versions/Current"
And what exact code would I use for removing the ACL from ALL the files in my Utilities folder?
Many thanks.

OK, tried what you suggested and I think it worked for my home directory, however when I run DR, I get a huge list of:
ACL found but not expected on "Library/Printers/Lexmark/Drivers/Lexmark 3300 Series Help.bundle/Contents/Resources/French.lproj/Lexmark3300SeriesHelp/PrinterSharin gSetUp.html".
2008-06-10 18:04:29 -0400:
ACL found but not expected on "Library/Printers/Lexmark/Drivers/Lexmark 3300 Series Help.bundle/Contents/Resources/French.lproj/Lexmark3300SeriesHelp/PrinterSelect iondlg.html".
2008-06-10 18:04:29 -0400:
ACL found but not expected on "Library/Printers/Lexmark/Drivers/Lexmark 3300 Series Help.bundle/Contents/Resources/French.lproj/Lexmark3300SeriesHelp/PrintDPOFSele ction.html".
2008-06-10 18:04:29 -0400:
ACL found but not expected on "Library/Printers/Lexmark/Drivers/Lexmark 3300 Series Help.bundle/Contents/Resources/French.lproj/Lexmark3300SeriesHelp/PrintDirectFr DigitalCam.html".
2008-06-10 18:04:29 -0400:
ACL found but not expected on "Library/Printers/Lexmark/Drivers/Lexmark 3300 Series Help.bundle/Contents/Resources/French.lproj/Lexmark3300SeriesHelp/PrintDialog.h tml".
2008-06-10 18:04:29 -0400:
ACL found but not expected on "Library/Printers/Lexmark/Drivers/Lexmark 3300 Series Help.bundle/Contents/Resources/French.lproj/Lexmark3300SeriesHelp/PrintCartridg es.html".
It goes on for over 35 minutes -- all referring to Library/Printers/*,
then it follows with:
[I did not include every line of Group differs on "Applications/System Preferences. . . ]
2008-06-10 18:05:22 -0400: Group differs on "Applications/System Preferences.app/Contents/Resources/pl.lproj/InfoPlist.strings", should be 0, group is 80.
2008-06-10 18:05:23 -0400: Group differs on "Applications/System Preferences.app/Contents/Resources/pl.lproj/Localizable.strings", should be 0, group is 80.
2008-06-10 18:05:23 -0400: Group differs on "Applications/System Preferences.app/Contents/Resources/pl.lproj/MainMenu.nib/keyedobjects.nib", should be 0, group is 80.
2008-06-10 18:05:23 -0400: Group differs on "Applications/System Preferences.app/Contents/Resources/pl.lproj/MainMenu.nib", should be 0, group is 80.
2008-06-10 18:05:23 -0400: Group differs on "Applications/System Preferences.app/Contents/Resources/pl.lproj/NSPrefPaneGroups.strings", should be 0, group is 80.
2008-06-10 18:05:23 -0400: Group differs on "Applications/System Preferences.app/Contents/Resources/pl.lproj", should be 0, group is 80.
2008-06-10 18:05:24 -0400: ACL missing on "Library".
2008-06-10 18:05:24 -0400: ACL found but not expected on "bin".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/ps".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/bash".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/sh".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/chmod".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/cp".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/dd".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/df".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/link".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/ln".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/ls".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/mkdir".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/mv".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/pax".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/rm".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/rmdir".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/unlink".
2008-06-10 18:05:25 -0400: ACL found but not expected on "usr/bin/cpio".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/launchctl".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/rcp".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/cat".
2008-06-10 18:05:25 -0400: ACL found but not expected on "bin/ed".
2008-06-10 18:05:25 -0400: ACL found but not expected on ".".
2008-06-10 18:05:26 -0400: Group differs on "private/etc/cups", should be 0, group is 26.
2008-06-10 18:05:27 -0400: Permissions differ on "Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool", should be -rwsr-xr-x , they are -rwsrwxr-x .
2008-06-10 18:05:27 -0400: Permissions differ on "Applications/Utilities/Keychain Access.app/Contents/Resources/kcproxy", should be -rwsr-xr-x , they are -rwsrwxr-x .
2008-06-10 18:05:30 -0400:
2008-06-10 18:05:30 -0400: Permissions repair complete
2008-06-10 18:05:30 -0400:
2008-06-10 18:05:30 -0400:
Can you tell me how to remedy this sutff? I understand about the "private/etc/cups" thing but what about all the ACL's on "bin/. . . "?
should those be there?
Can I log in as root user to change these??
Any assistance greatly appreciated.

Similar Messages

Cisco ACL confusion...

Hi All,
I have a couple of queries about the way ACLs work on Cisco Layer 3 switches... Namely a Cisco 6509 with IOS 12.2(18)
We have a number of VLANs running on the device and after creating a new 'Management' VLAN, we wanted to restrict access to this VLAN so only 2 out of our 20+ other VLANs could access the devices within.
Now, sounds fairly simple to me. BUT, we could only get it to work properly if we denied access form ALL 18 of ther other VLAN interfaces and not by placing a much smaller ACL at the Destination VLAN interface.
Does this make sense? Can anyone tell me if they should work the same as a PIX/Router ACL? Here is an example:
The Management VLAN is VLAN 8 with a network address of 172.17.1.0/24, the ACL is 180. Lets say we want to allow networks 172.23.80.0/24 and 172.19.0.0/16 to access the new VLAN, but NO others.
access-list 180 permit ip 172.23.80.0 0.0.0.255 172.17.1.0 0.0.0.255
access-list 180 permit ip 172.19.0.0 0.0.255.255 172.17.1.0 0.0.0.255
access-list deny ip any any
int vlan 8
ip access-group 180 in
Would this be on the right lines or am i missing something?
Many thanks

Jonathan
Think of it like this.
IN statement applies to traffic going into the interface rather than the vlan so in your example IN on vlan 8 means traffic going into the vlan 8 interface ie. traffic from vlan 8 servers.
OUT applies to traffic leaving the interface ie. traffic going out on vlan 8 interface - to the vlan 8 servers.
Hope this makes sense
Jon

Confused with inbound/outbound ACL

"Access list applied to inbound traffic filter packets before the routing decision is made. Access lists applied to outbound traffic filter packets after routing decision is made" What does it mean? How to choose when to use inbound or outbound? I remember that in some case there is no different either using inbound or out bound, right? Can someone give an example? I?m confused. Inbound and outbound are just the direction of the packet or what?

Inbound ACLs affect packets coming into the router from an interface.
Outbound ACLs affect packets leaving the router through an interface. They do not affect packets originating from the router, though.
Both directions are from the perspective of the router itself.
Paresh

ACL's confusion

hi,
after waiting for 9i and eventually getting 9iFS installed, i am
confused about the access rights for the system ACL's (private,
protected, published and public). when i create a user and
change the default ACL's to private during account creation, i
can from another machine access the users account, create child
directories and place files via the windows interface. i
understood that private for the folders and documents precludes
other users from accessing those folders and directories.
when i look at the properties of the system private ACL the
access control is set to published. huh?
tia
sean

A) R1(config)#access-list 10 permit 10.1.1.1
              #access-list 10 deny 11.0.0.1
   The above line create's a standard numbered ACL
   R1(config)#ip access-list standard 1 |
              #no 20                                 |----->these line treats the numbered acl as named ACL
             #20 permit 11.0.0.1              _|        but how a numbered ACL can be treated a Name
B) So is it true that
    if we use ip access-list then it always create named acl
    if we use access-list then it will always create numbere acl
But if we use
R2(config)#ip access-list standard ?
<1-99>       Standard IP access-list number
<1300-1999> Standard IP access-list number (expanded range)
WORD         Access-list name
it shows
"1-99 standard ip access-list number"
does it means that this will create numbered acl
C) can we say that these ACL are for different protocol as first one is for IP and second one is for TCP if not then why
     access-list 100 permit ip host 10.1.1.1 host 10.1.1.2
     access-list 101 permit tcp host 10.1.1.1 host 10.1.1.3 eq telnet

Help With ACL in SUNONE

i have two mail servers , First email server wants to authenticate users in ou=people tree whose affiliation attribute value says staff.
second email server wants to authenticate users in ou=people tree whose affiliation attribute value says vendor
I am thinking creating two special user accounts one for each mail server. then add acl to that account so it will let autheticate users based on thier role.
am i making sense if the question is confusing please let me know i will try to repharse it.
Thanks for your time.
appreciate any input.

Hi,
I think you had some doubts, but you are right it doesn't make any sense.
your need is to give your users access to the branch "ou=people", which means that you have to create an ACL on the ou itself, by creating two different groups with rights on the ou=people.
That also implyies that every time you create a new user, you have to add it to your group, or to to use dynamic group membership by filtering on the values staff or vendors.
Bye

Confused - obj.conf

I am attempting to configure Web Server 6.1 to support an application that uses HTTP 1.0 and expects a content-length header in the response. The response is generated from a php script (index.php). The php script does not generate the header itself.
Here is my modified obj.conf:
<Object name="default">
AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true"
AuthTrans fn="match-browser" browser="*" http-downgrade="1.0"
NameTrans fn="ntrans-j2ee" name="j2ee"
NameTrans fn=pfx2dir from=/mc-icons dir="/opt/SUNWwbsvr/ns-icons" name="es-internal"
NameTrans fn=document-root root="$docroot"
PathCheck fn=unix-uri-clean
PathCheck fn="check-acl" acl="default"
PathCheck fn=find-pathinfo
PathCheck fn=find-index index-names="index.php"
ObjectType fn=type-by-extension
ObjectType fn=force-type type=text/plain
Service fn="match-browser" browser="*" http-downgrade="1.0" UseOutputStreamSize="8192"
Service fn="php5_execute" type="magnus-internal/x-httpd-php"
Service method=(GET|HEAD) type=magnus-internal/imagemap fn=imagemap
Service method=(GET|HEAD) type=magnus-internal/directory fn=index-common
Service method=(GET|HEAD|POST) type=*~magnus-internal/* fn=send-file
Service method=TRACE fn=service-trace
Error fn="error-j2ee"
#AddLog fn=flex-log name="access"
AddLog fn=flex-log name="extended"
</Object>
<Object name="j2ee">
Service fn="service-j2ee" method="*"
</Object>
<Object name="cgi">
ObjectType fn=force-type type=magnus-internal/cgi
Service fn=send-cgi user="$user" group="$group" chroot="$chroot" dir="$dir" nice="$nice"
</Object>
<Object name="es-internal">
PathCheck fn="check-acl" acl="es-internal"
</Object>
<Object name="send-compressed">
PathCheck fn="find-compressed"
</Object>
<Object name="compress-on-demand">
Output fn="insert-filter" filter="http-compression"
</Object>
What is confusing is:
1. Why do I need the http-downgrade=1.0 twice - once in AuthTrans and once in Service?
2. How come this works at all since the server should stop at the first Service entry, i.e. the match-match browser one and not call the PHP.
3. Why does this only work for GET and not for POST ??????
Any help would be greatly appreciated.

You don't see the UseOutputStreamSize syntax error when you have the AuthTrans directive because only the first match-browser directive to match the browser will actually be executed. I think you should remove your Service fn="match-browser" directive altogether. Instead, you could use the following:<Object name="default">
AuthTrans fn="match-browser" browser="*" http-downgrade="1.0"
Service fn="php5_execute" type="magnus-internal/x-httpd-php" UseOutputStreamSize="8192"
</Object>Neither UseOutputStreamSize nor http-downgrade are specific to GET. Both work with POST. If you don't get a Content-length: header on POST responses, it may be because the content is more than 8192 bytes in length. Try changing UseOutputStreamSize="8192" to UseOutputStreamSize="65536".

Is it neccesary certificate&ACL data to use functions in R3 via the RFC?

Hi.
I create sap r3 471 ides version.
And try to connect via the iway(third party product to call function via the RFC).
I referenced some block, and they says if I want to call functions in sap r3 471 via the RFC, I should check create remote function enabled option.
But i'm confusing is functions in r3 can be called from third party via the RFC directly? and have no other configuration?
If there needs to more configuration, which configuration need I check?
Which role need I add, and how to add?
When I try to connect r3, it says ID and password not correct, but I can connect to R3 with SAP GUI 6.20 well.
And I use Tcode STRUSTSSO2, found certificate, ACL are blank.
If certificate and ACL are not neccesary,could you help me to solve this problem?
If the certificate and ACL are neccesary, which parameter need I configure to call functions in sap r3 4.71 ides via the RFC?
Thanks.
Edited by: sckim805 on Apr 4, 2010 9:12 PM

got answer from another block.

ACL on inter-VLAN router

I am trying to setup a home network for myslef for practice basically that has two VLANs. One will be a secure VLAN with servers, domain access, etc. The other will just be an internet access VLAN.
I have an internet gateway, but only one, that needs to be shared by both VLANs. Currently I have everything setup fine so that I can access the internet from either VLAN. The only problem is I think by opening a link between them to share the internet connection I am also opening s ecurity risk. I need an ACL to allow only internet traffic from the seocnd VLAN to be passed thorugh.
My problem has been that anything I have tried either allows nothing to pass, or everything to pass. I was trying to do just a permit from any host to any host on http, and deny everything else.
Thanks for any help.

I have another question for you:
you said that you need to access server on 192.168.1.0/24 , from which subnet? are you connected on the same vlan? or coming from the internet?
somewhere in this network you are doing NAT right? so to get in , you would need a static NAT or outside NAT.
So, if you are coming from internet I think you'd need to set and ACL to permit only the IP you have.
But I guess you're inside vlan 1 192.168.1.0/24, so basically you need to restric traffic from 192.168.2.0/24 to reach 192.168.1.0/24.
You need an ACL on the fa0.2 blocking traffic like this:
ip access-list extended sec-traffic-out
deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
permit any any
int fa0.2
ip access-group sec-traffic-out in
I guess what could be confusing you is that your INTERNET gateway is on 192.168.1.0/24, but outgoing internet traffic will have layer3 destination addresses on a different subnet , like 200.0.0.0/8, so, it wont be blocked by the ACL.
HTH,
if it does, please rate this post,
Vlad
BTW, I think you dont need :
ip default-gateway, as its used when you dont have routing configured (no ip routing).
also ip defaul-network have specific use, I'm not sure you'd need it here too.

Java.security.acl.NotOwnerException when Administration Port is set

I get the NOE, posted below, when I start some of my managed servers, while other managed servers
start fine. After some scrutiny I discover the differences is that in /console, I've set some of my
managed server's Administration Port to that of my admin server, and these are the ones that are
busted! Those that I left as default '0' start up just fine. Hence the question: "What the heck
is the use of this field???"
<Apr 3, 2001 3:12:02 PM PDT> <Info> <WebLogicServer> <IIOP subsystem enabled.>
<Apr 3, 2001 3:12:02 PM PDT> <Emergency> <Server> <Unable to initialize the server: 'Fatal
initialization exception
Throwable: java.lang.IllegalAccessError: java.security.acl.NotOwnerException
java.lang.IllegalAccessError: java.security.acl.NotOwnerException
at weblogic.security.acl.Realm.getRealm(Realm.java:91)
at weblogic.security.acl.Realm.getRealm(Realm.java:36)
at weblogic.security.acl.Realm.authenticate(Realm.java:183)
at weblogic.security.acl.Realm.getAuthenticatedName(Realm.java:233)
at weblogic.security.acl.internal.Security.authenticate(Security.java:116)
at
weblogic.jndi.WLInitialContextFactoryDelegate.pushUser(WLInitialContextFactoryDelegate.java:429)
at
weblogic.jndi.WLInitialContextFactoryDelegate.newContext(WLInitialContextFactoryDelegate.java:272)
at
weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java
:244)
at weblogic.jndi.Environment.getContext(Environment.java:135)
at weblogic.jndi.Environment.getInitialContext(Environment.java:118)
at weblogic.management.Admin.initializeRemoteAdminHome(Admin.java:894)
at weblogic.management.Admin.start(Admin.java:311)
at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:331)
at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:169)
at weblogic.Server.main(Server.java:35)
'>
The WebLogic Server did not start up properly.
Exception raised: java.lang.IllegalAccessError: java.security.acl.NotOwnerException
java.lang.IllegalAccessError: java.security.acl.NotOwnerException
at weblogic.security.acl.Realm.getRealm(Realm.java:91)
at weblogic.security.acl.Realm.getRealm(Realm.java:36)
at weblogic.security.acl.Realm.authenticate(Realm.java:183)
at weblogic.security.acl.Realm.getAuthenticatedName(Realm.java:233)
at weblogic.security.acl.internal.Security.authenticate(Security.java:116)
at
weblogic.jndi.WLInitialContextFactoryDelegate.pushUser(WLInitialContextFactoryDelegate.java:429)
at
weblogic.jndi.WLInitialContextFactoryDelegate.newContext(WLInitialContextFactoryDelegate.java:272)
at
weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java
:244)
at weblogic.jndi.Environment.getContext(Environment.java:135)
at weblogic.jndi.Environment.getInitialContext(Environment.java:118)
at weblogic.management.Admin.initializeRemoteAdminHome(Admin.java:894)
at weblogic.management.Admin.start(Admin.java:311)
at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:331)
at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:169)
at weblogic.Server.main(Server.java:35)
Reason: Fatal initialization exception
Gene Chuang
Join Kiko.com!

Ah, I see! The introduction of an "admin server" in 6.0 caused the confusion for me. The
Administration Port is NOT the port number of the admin server!
Gene
"Kumar Allamraju" <[email protected]> wrote in message news:[email protected]...
This is equivalent to weblogic.system.AdministrationPort in 451/510.
In 451/51 if you start WLS server with
java -Dweblogic.system.administrativePort=2000 weblogic.Server
and then executing
D:\releases\510>java weblogic.Admin admin://localhost:2000 VERSION
returns the WLS version.
WebLogic Build: 5.1.0 Service Pack 8 12/20/2000 16:34:54 #95137
Bottom line is, once you set admin port, all admin stuff can be done on admin protocol only.
It appears this is not happening/broken in 6.0 . There's already an engg issue filed on thisproblem.
>
Kumar
Gene Chuang wrote:
I get the NOE, posted below, when I start some of my managed servers, while other managed
servers
start fine. After some scrutiny I discover the differences is that in /console, I've set someof my
managed server's Administration Port to that of my admin server, and these are the ones that are
busted! Those that I left as default '0' start up just fine. Hence the question: "What theheck
is the use of this field???"
<Apr 3, 2001 3:12:02 PM PDT> <Info> <WebLogicServer> <IIOP subsystem enabled.>
<Apr 3, 2001 3:12:02 PM PDT> <Emergency> <Server> <Unable to initialize the server: 'Fatal
initialization exception
Throwable: java.lang.IllegalAccessError: java.security.acl.NotOwnerException
java.lang.IllegalAccessError: java.security.acl.NotOwnerException
at weblogic.security.acl.Realm.getRealm(Realm.java:91)
at weblogic.security.acl.Realm.getRealm(Realm.java:36)
at weblogic.security.acl.Realm.authenticate(Realm.java:183)
at weblogic.security.acl.Realm.getAuthenticatedName(Realm.java:233)
at weblogic.security.acl.internal.Security.authenticate(Security.java:116)
at
weblogic.jndi.WLInitialContextFactoryDelegate.pushUser(WLInitialContextFactoryDelegate.java:429)
at
weblogic.jndi.WLInitialContextFactoryDelegate.newContext(WLInitialContextFactoryDelegate.java:272)
at
weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java
:244)
at weblogic.jndi.Environment.getContext(Environment.java:135)
at weblogic.jndi.Environment.getInitialContext(Environment.java:118)
at weblogic.management.Admin.initializeRemoteAdminHome(Admin.java:894)
at weblogic.management.Admin.start(Admin.java:311)
at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:331)
at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:169)
at weblogic.Server.main(Server.java:35)
'>
The WebLogic Server did not start up properly.
Exception raised: java.lang.IllegalAccessError: java.security.acl.NotOwnerException
java.lang.IllegalAccessError: java.security.acl.NotOwnerException
at weblogic.security.acl.Realm.getRealm(Realm.java:91)
at weblogic.security.acl.Realm.getRealm(Realm.java:36)
at weblogic.security.acl.Realm.authenticate(Realm.java:183)
at weblogic.security.acl.Realm.getAuthenticatedName(Realm.java:233)
at weblogic.security.acl.internal.Security.authenticate(Security.java:116)
at
weblogic.jndi.WLInitialContextFactoryDelegate.pushUser(WLInitialContextFactoryDelegate.java:429)
at
weblogic.jndi.WLInitialContextFactoryDelegate.newContext(WLInitialContextFactoryDelegate.java:272)
at
weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java
:244)
at weblogic.jndi.Environment.getContext(Environment.java:135)
at weblogic.jndi.Environment.getInitialContext(Environment.java:118)
at weblogic.management.Admin.initializeRemoteAdminHome(Admin.java:894)
at weblogic.management.Admin.start(Admin.java:311)
at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:331)
at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:169)
at weblogic.Server.main(Server.java:35)
Reason: Fatal initialization exception
Gene Chuang
Join Kiko.com!

Understanding DMZ ACLs

I understand ACLs to work in this way on an ASA:
If the traffic DESTINATION is a host on the subnet where the ACL exists, it's considered INCOMING. For example, if I want to allow my hosts on the inside to access the internet, since traffic sourced by my host destined for the outside is an outbound flow (high -> low zone) there is no need for an ACL. However, the return is low -> high and does require an ACL. Since the destination is a host on the inside, I create an INBOUND rule on the INSIDE interface. Because the INSIDE interface is the highest security zone, the majority of the rules regarding the INSIDE interface are incoming. We could write outgoing rules if we want to block zombies from sending spam, etc. Now I'm putting in a DMZ, and I want my DMZ machine to access the DNS servers on the inside. So I wrote a rule that says 'permit object-group TCPUDP 192.168.50.0 255.255.255.0 object-group Internal_DNS_Servers eq domain'. This is an incoming rule from the DMZ to the INSIDE interface permitting a flow from a lower zone (DMZ is 50) to a higher zone (INSIDE is 100). This correlates with what I believe to be the appropriate usage of ACLs in that the DESTINATION is on the INSIDE interface, so I wrote the rule there to accept it. I also understand that I need to write a similar rule on the DMZ interface to allow the outgoing request towards the INSIDE interface because INSIDE is a higer security zone. Here's what I DON'T UNDERSTAND:
The firewall log says this:
4
Feb 01 2012
13:29:55
106023
192.168.50.2
51276
OSI-SUPPORT
53
Deny udp src DMZ-1:192.168.50.2/51276 dst Inside:OSI-SUPPORT/53 by access-group "DMZ-1_access_in" [0x0, 0x0]
Why would I need a rule that is DMZ-1_access_in (incoming, so the destination should be the DMZ) yet have the source be the DMZ and the destination be INSIDE? If the firewall is telling me that the ACL blocking the traffic is the inbound/incoming rule, I'd expect the source to be my DNS servers on the INSIDE and the destination to be the DMZ host. Also, why would such a rule be necessary when the return traffic is coming from a higher zone to a lower one? Maybe I'm thinking of this in separate steps like a request for information and a response, when really I need to be thinking flows? In any case, I'm confused.
Regards,
Scott

Hello Scott,
Lets first explaining the directions of an Access-group on an interface ( in,out)
INSIDE--------ASA--------Outside
On this scenario if a packet comming from the inside to the outside, if we want to restrict the traffic from the inside, we will need to apply the access list in witch direction?
Well we need to place ourselfs in the ASA inside interface, the packet will get IN the Inside interface and get OUT the outside interface. So we applied the access-group: in interface inside
Now lets do it from the outside to the inside, Again lets put ourselfs on the Outside interface of the ASA, we will need to open the interface to let the packets get IN from the outside to the inside, so again it would be. access-group in interface outside.
That being said, now lets talk about security levels and ACL's on the ASA.
From a Higher security level to a lower everything is allowed unless you want to restrict something.
From a lower security level to a higher you do need the ACL to allow the traffic.
On your case on the DMZ, you want to allow outbound traffic from the DMZ, okay so DMZ to inside.
So again put yourself into the ASA.
-When a user tries to connect to a inside host, the 1st packet will be received on the DMZ interface and that packet needs to get IN into that interface so the direction would be IN instead of outbound.
Regards,
Julio!!!!

Acl issue in L3 Switch SVI

HI
I hope might be a number of issues has reported like this, I am gettnig confused about the direction of an acl, when it is on a router's physical interface and when it is on a Layer Switch SVI interface, I think my understanidng about acl needs to get cleared, need your kind input please.
I have a L3 switch with 3 vlans
Vlan 1 - Routing-Vlan (Connecting to another network directly) - 172.16.1.254 /24 (connect to another router some where in in another network on 172.16.1.1/24)
Vlan 10 - Server-Vlan - 172.16.10.1/24
Vlan 11 - User-Vlan - 172.16.11.1/24
I want to allow only specific network to come inside to my network to access all the subnets, other all must be blocked.
I want all in my network to access any thing outside the network.
i tried to configure acl as below-
access-list 101 permit ip 172.16.100.0 0.0.0.255 172.16.10.0 0.0.0.255
int vlan 1
ip add 172.16.1.1 255.255.255.0
ip access-group 101 in
When i am trying from outisde (172.16.100.1) -
Ping 172.16.10.1 - Good (expected)
Ping 172.16.11.1 - NOT (expected)
When I am trying to ping from inside Server-Vlan (172.16.10.1)
Ping 172.16.100.1 - Good
The problem -
When i am trying to ping from inside User-Vlan (172.16.11.1) to go outside to 172.16.100.1 am not getting reply
what is wrong happening here in this scenario?
regards
Sunny

Hi Jon,
I was working on the ACL for the above issue. i have found the below thigs-
int vlan 1
des Routing vlan
ip 172.16.1.1 255.255.255.0
ip access-group 110 in
int vlan 10
des server vlan
ip 172.16.10.1 255.255.255.0
int vlan 11
des Users
ip add 172.16.11.1 255.255.255.0
ip access-group 100 in
acl applied on vlan 10 and and 11 are inbound in direction so as like we have mentioned before, the traffic coming from each vlan (172.16.10.x OR 172.16.11.x) can be filtered at the SVI itself. infact i need to put below statement in bold to ping its own gateway.
ip access-list 100 permit 172.16.11.0 0.0.0.255 172.16.10.0 0.0.0.255
ip access-list 100 permit 172.16.11.0 0.0.0.255 172.16.11.0 0.0.0.255
ip access-list 100 permit 172.16.11.0 0.0.0.255 172.16.100.0 0.0.0.255
ip access-list 100 permit 172.16.11.0 0.0.0.255 172.16.101.0 0.0.0.255
And for filtering the traffic coming from outside, i had to put the acl on interface vlan 1 and called in INBOUND direction.
access-list 110 permit ip 172.16.100.0. 0.0.0.255 172.16.10.0 .0.0.0.255
access-list 110 permit ip 172.16.100.0. 0.0.0.255 172.16.11.0 .0.0.0.255
access-list 110 permit ip 172.16.101.0. 0.0.0.255 172.16.10.0 .0.0.0.255
access-list 110 permit ip 172.16.101.0. 0.0.0.255 172.16.11.0 .0.0.0.255
what i understood,
for vlan 10 or 11 - if i call outbound means the traffic coming from outside and destined to inside of that vlan.
for vlan 10 or 11 - if i call inbound means the traffic coming from inside of that vlan and destined to outside.
But for Vlan 1, which is the routing vlan,connecting to the other network the behaviour is just reverse-
If i call inbound means the traffic coming in to that vlan initerface from Outside
If i call outbound means the traffic that going out through that interface.
so i ddint call any acl in outbound direction as of now.
Dear Jon, thanks for taking time to describing the scenario in detail before.
please check this and let me know that my conclusion is correct or is there anything left to be in the loop again...!!!
Thanks and Regards
Suuny

Which direction should ACL be applied

Hello there,
I'm adding ACLs to lock down the LAN environment and my core is a 4510+R. I want to block port 80, 443 and 8080 from coming INTO the network. My security guy tells me users use port 80, 443 and 8080 to get out and web services use other ports to come back in. I want to use an extended access-list the likes of:
ip access-list extended NO_HTTP
deny tcp any any eq 80
deny tcp any any eq 443
deny tcp any any eq 8080
permit ip any any
My confusion is: which direction on my SVI do I apply this ACL if I want users to be able to access web sites but block inbound traffic on 80, 443 and 8080? All information I've been able to read says to apply extended ACLs as close to the source as possible. With an SVI, that seems like a grey area?
Any kind of clarification on this would be most helpful and appreciative.
Thanks very much in advance,
Kiley

I think from the perspective of SVI you have to apply the access list OUT. OUT means that the traffic will be process by the access list after is get routed or exiting the interface in other words packets origin from the outside GOING OUT to your LAN.

ACL and sequence numbers

I had the first two lines in the access list and all was well, I then added the 3rd. From what I need to put the 3rd entry (deny host 10.1.30.51) after the second entry and before the permit any. Even though I created sequence numbers in order of the 3 entries (10,20,30) the sequence numbers didnt put them in order and they dont even show up in the show run. What went wrong? How is it possible to edit an acl without sequence numbers also?
Cause if I had:
10 deny x.x.x.x
20 deny x.x.x.x
30 permit any
Then I could add say 15 deny x.x.x.x, but now I cant and I dont even know what happened to the sequence numbers when I created them.
Thanks.
Standard IP access list 1
    deny host 10.1.30.50 (4 match(es))
    permit any (8 match(es))
    deny host 10.1.30.51
Router#

Hi Milan,
Sequence numbers are indeed not supported if you define a numbered access list. With both standard and extended numbered ACLs, however, it is possible to do a trick: if you refer to them as named ACLs (use their number as their name), you actually are able to use the sequence numbers.
For example:
R1(config)# do show run | i access-listaccess-list 1 deny   192.0.2.1access-list 1 permit anyaccess-list 100 deny   ip host 192.0.2.1 anyaccess-list 100 permit ip any anyR1(config)# do show ip access-lStandard IP access list 1    10 deny   192.0.2.1    20 permit anyExtended IP access list 100    10 deny ip host 192.0.2.1 any    20 permit ip any anyR1(config)# ip access-list standard 1R1(config-std-nacl)# 15 deny 192.0.2.15R1(config-std-nacl)# exitR1(config)# do show access-listStandard IP access list 1    10 deny   192.0.2.1    15 deny   192.0.2.15    20 permit anyExtended IP access list 100    10 deny ip host 192.0.2.1 any    20 permit ip any anyR1(config)# ip access-list extended 100R1(config-ext-nacl)# 15 deny ip host 192.0.2.15 anyR1(config-ext-nacl)# exitR1(config)# do show access-lStandard IP access list 1    10 deny   192.0.2.1    15 deny   192.0.2.15    20 permit anyExtended IP access list 100    10 deny ip host 192.0.2.1 any    15 deny ip host 192.0.2.15 any    20 permit ip any any
The router is even smart enough to disallow to refer to a named ACL whose name is a number of the opposite type than stated on the command line:
R1(config)# ip access-list standard 101% % Invalid access list name.R1(config)# ip access-list extended 2% % Invalid access list name.
What Collin may have in mind, though, is that host entries in standard ACLs are reorganized to a different order than entered:
R1(config)# ip access-list standard TestR1(config-std-nacl)# permit 10.0.0.1R1(config-std-nacl)# deny 10.0.0.2R1(config-std-nacl)# permit 10.0.0.3R1(config-std-nacl)# deny 10.0.0.4R1(config-std-nacl)# permit 10.0.0.5R1(config-std-nacl)# deny 10.0.0.6R1(config-std-nacl)# permit 10.0.0.7R1(config-std-nacl)# deny 10.0.0.8R1(config-std-nacl)# permit anyR1(config-std-nacl)#exitR1(config)# do show access-list TestStandard IP access list Test    80 deny   10.0.0.8    20 deny   10.0.0.2    30 permit 10.0.0.3    10 permit 10.0.0.1    60 deny   10.0.0.6    70 permit 10.0.0.7    40 deny   10.0.0.4    50 permit 10.0.0.5    90 permit anyR1(config)# do show run | section Testip access-list standard Test deny   10.0.0.8 deny   10.0.0.2 permit 10.0.0.3 permit 10.0.0.1 deny   10.0.0.6 permit 10.0.0.7 deny   10.0.0.4 permit 10.0.0.5 permit any
This reordering happens only with standard ACLs and is a result of indexing the host entries in the ACL into a hash table (the hash function being XOR of individual octets of the IP address in the host entry) for faster access. When printing out the ACL, first the host items are printed out in the order they are stored in the hashing table, and only then the remaining entries that use wildcards. Wildcard entries are not reordered.
The funny thing is that the ACL is actually even stored in the configuration in the reordered form, and thus evaluated in a reordered form, which can be confusing. However, you may have noticed that the router will prohibit you from entering a host ACL after entering a wildcard ACL that also matches the IP address in a wildcard entry:
R1(config)# ip access-list standard Test2R1(config-std-nacl)# permit 10.0.1.0 0.0.0.255R1(config-std-nacl)# deny 10.0.1.1% Access rule can't be configured at higher sequence num as it is part of the existing rule at sequence num 10R1(config-std-nacl)#
Why is this? Obviously, a host entry can either select the same action for a packet that would be taken by a more general wildcard entry (in which case it is not necessary for the host entry to be entered at all), or it can override the action that would be chosen by a more general wildcard entry. In this second case, it is necessary for this host entry to be placed in the ACL first, otherwise it would never be reached. Ordering of host entries themselves can be arbitrary, as they do not influence each other. This leads us to a general logic in standard ACLs - it is required to put all host entries first, and wildcard entries last. Now it is completely logical to visit all host entries first (indexed by a hash for rapid access), and then visit the wildcard entries.
Quite a long post... sorry for that. Hopefully, we've resolved some of the doubts.
Best regards,
Peter

ACL config question

Hello,
I am confused on how I would go about writing my ACL to only allow one IP to access an SNMP string and deny everyone else. Can anyone help me?

Hi Velezm111,
What I think you are asking is how do you utilize the ACL functionality option at the end of the community string to only allow one SNMP manager to gain access to the SNMP agent?
If that is the case first create a standard access list. (Remember this is an ACL within the range of 1-99)
enable
configure terminal
ip access-list standard 99
permit host (insert single ip)
At this point you have your ACL, now apply it to the community string
Snmp-server community (insert string) 99 (specify rw or ro)
Hope this helped

OS X Snow Leo Server, do ACL's have precedent over POSIX?

I'm having some small issues with a OS X 10.6.8 server, where desired behavoirs such as a write, but not delete access assigned to a Group, in ACL doesn't seem to work. Do ACLs have precendent over POSIX settings, or the other way around. I guess I'm trying to determine the evaluation order in which ACLs and POSIXs work?
Thanks - Lewis

You only have a few settings left to tweak to see what the blockage is, and it's obviously either the administration-change access that's lacking, or there might be an existing file that needs to be deleted when the new file is added.
Various folks have tried to implement these schemes using the file system and ACLs, and with varying success.
FWIW, using a document management system would be my recommendation, both for access control and for change tracking. Even when they work and when the protections are configured to the user's expectations, these shared-directory schemes don't usually end well in my experience; the shared directory doesn't scale.
If that's not it — the GUI gets confusing — please launch Terminal.app from Applications > Utilities and post the output from
ls -aled@
on the directory file, and post the output from
ls -ale@
on one of the test files in the directory.
The trailing + and @ characters at the end of the protection mask (that drwxr-xr-x+ or drwxr-xr-x@ stuff) in what was shown means there's more information here than what was listed by the ls command output shown. The ACL should be at least part of what's referenced there, obviously.

ACL-confusion

Similar Messages

Maybe you are looking for