Posts Tagged ‘Access Control Lists’

Adding incoming and outgoing access rules on a Cisco ASA

Saturday, March 17th, 2012

To understand incoming and outgoing rules there are a couple of things to know before you can define your rules. Let’s start with an understanding of traffic flow on an ASA. All incoming rules are meant to define traffic that come inbound to the ASA’s interface. Outgoing is for all traffic that is going outbound of an ASA’s interface. It does not matter which interface it is since this is a matter data flow and each active interface on an ASA will have it’s own unique address.

To try an explain this further let’s say we have and internal interface with an IP address of 10.0.0.1 that is for your local area network to connect to. You can add a permit or deny rule to this interface specifying whether incoming or outgoing  traffic will be permitted or not. This allows you to control what computers can communicate past that interface or not. Essentially you would define most of your rules for the local area network on the internal interface, governing which systems/devices could access the internet, certain protocols, or not.

Now if you know about the basic configuration of an ASA you know that you have to set the security level of the Internal and External ports. So by default these devices allow traffic from a higher security interface to a lower security interface. NAT/PAT will need to be configured depending on if you want to define port traffic for specified protocols.

For this article I will just mention that their are several types of Access Control Lists (ACL) that you can create on an ASA. These types are Standard, Extended, Ethertype, webtype, and IPV6. For this example we will use Extended because most likely that is what most everyone will use the most. With extended ACL not only can you specify IP addresses in the access control list, but you can specify port traffic to match the protocol that might be required.

Lets look at the the examples below:

You will see we are in the configuration terminal mode

ASA(config)# access-list acl extended permit tcp any host 192.0.43.10 eq 80

-So the first part “access-list acl” means the access list will be named “acl”.
-Next you have a choice between type of access list. We are using Extended for this example.
-The next portion is the permit or deny option and we have permit selected for this statement.
-On the next selection that say’s “any” this refers to inside traffic (simply meaning that any internal traffic is allowed). If you dont use any you can specify specific devices by using “host and the IP address like that last part of this ACL statement.
-The next part of this refers to specifying a specific host address of 192.0.43.10 equals port 80.

So this example tells us that our access control list named ACL will allow any inside traffic out the host address of 192.0.43.10 that is internet traffic.

Later you will notice that your statement will look like this on the ASA

ASA(config)access-list acl extended permit tcp any host 192.0.43.10 www
Notice how “eq 80″ default http traffic changed automatically to www) This is common on Cisco ASA devices).

The Impact of Directory Services on Xsan

Monday, January 23rd, 2012

When you’re dealing with file ownership and permissions, context is very important. Xsan volumes, from the point of view of an Xsan client, are local storage. There’s no daemon acting as gatekeeper or mediator, so when files are created or modified, the clients will use the standard mechanisms for assigning ownership and access rights, as they would with any local drive. In the absence of a shared authentication context, local user accounts will end up owning the files, and their permissions will be according to the default umask.

Mac OS X keeps track of such things by numerical User ID, and all Mac OS X systems start assigning local UIDs beginning with 501. It shouldn’be be too difficult to see how this can end badly. Users will potentially be able to overwrite files owned by other users, or access files they shouldn’t be able to, or not be able to access files that they should.

A directory service, therefore, is a key component in a proper deployment of Xsan. A directory service provides a shared context that will keep User ID collisions from happening. Also, users and groups can be managed centrally, and not on each workstation. This is especially important in large Xsan environments. Also, it will be possible to leverage Access Control Lists, and not POSIX permissions, to manage access to files and folders. POSIX permissions aren’t flexible enough to effectively manage the requirements of most Xsan environments.

It doesn’t matter whether you’re using Open Directory, Active Directory, or a Golden Triangle. You can even integrate Xsan with Novell’s eDirectory. Any of these will provide a much smoother and easy to manage Xsan.

ACLs and NFS

Thursday, January 14th, 2010

The permissions that a user obtains for NFS shares will boil down to effective permissions. NFS doesn’t support ACLs, but it does honor them for Mac OS X NFS clients when bound to the directory.: if a user is granted read/write via an ACL, they WILL have read/write access via NFS. However, there are a few things to note here.

First and foremost, granular ACL’s won’t translate completely. Secondly, although you might have effective write privileges via ACL’s, if you don’t have write privileges via POSIX, it will *look* like you don’t have privileges when you do an `ls` on the mounted NFS volume, however, if you try to read or write a file, it will work without issue. Poorly written software might inspect the POSIX permissions and determine that you don’t have access when you really do. Most software will attempt to read/write an asset and will report errors when encountered (as it should).  Lastly, ACL inheritance IS honored over NFS as well, so any files/dirs your users will create will have the appropriate ACL’s assigned on the backend, though displayed POSIX permissions once again won’t be especially accurate.

Leopard Server: Using Directory to Update LDAP Entries

Saturday, October 27th, 2007

If you’re migrating to Leopard and Leopard Server then you’ve likely noticed the welcome addition of a new program in /Applications/Utilities called Directory. Directory allows users bound into an Open Directory environment to update LDAP records provided they have access to do so. Using LDAP ACLs it’s possible to give users access to update their own directory information using an LDAP directory browser such as Directory.

When you open Directory you should see a listing of all of the directory information that has been created. From here you can create Shared Contacts, Groups, Locations and Resources. Each of these can be connected to a calendar. Groups can have multiple members and get a Mailing List, Calendar or Blog connected to them.

Resource types include Automobiles, Conference Phones, Copiers, Digital Cameras, Notebooks, Printers, Projection Screens, Projectors, Scanners and Video Cameras. Resources can be reserved in an iCal Server Calendar and can have a delegate. Delegates are users that are able to manage particular resources.

The fact that there are a lot of objects in the LDAP database that can be managed means that it’s important to have a tool for configuring who can manage them. Workgroup Manager has basic permissioning built it but it isn’t as granular as a lot of organizations will need. To get more granular it might be required to dip into the command line and configure LDAP using the configuration files. To get started with this, see the article from a couple of days ago about LDAP ACLs.