Security

Ask something
Discussion Locked

Bolster UNIX security with ACLs

0 helpful
4 replies

by debate

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

What suggestions do you have for bolstering UNIX security? What experience do you have with using access control lists on UNIX systems? Share your comments about enhancing UNIX system security, as discussed in the May 10 Internet Security Focus e-newsletter.

If you haven't subscribed to our free Internet Security Focus e-newsletter, sign up today!
http://nl.com.com/acct_mgmt.jsp?brand=techrepublic

4 replies

by jdii1215

Indeed, ACLs can be used to block certain things very well, and set up basic rules that can limit a box or boxes from accessing crtical things.

However, IPV4 can be anonymized, spoofed, and many folks use hardware firewalling also.

With Linux as router, or BSD, ACLs are valuable, you can build a router that you can dynamically admin to make a gateway that limits LAN access at the gate.There (IE in that scenario), ACLs make hyper-good sense. So does filling the concommitent need to log ACL actions that are applied, in such an application, partly because with many ACLs you might have rules that are residuals and need to be altered.

Build ACLs based on what the ACLed thing is protecting-- and in most cases that is to protect the protected boxes from system compromizes,takeovers,and unwanted data mining. Use ACLs on a basis of who needs to know, and what IP their legitimate access box or ID can use. Actually, for end node protection of non-server apps and boxes, default install automatic build of basic ACLs on a Linux install of Mandrake 9 or 10, SuSE 9.0 and up, FreeBSD 5.2 and up, you will get port based rules in place that give you a good starting point. Use ACLs to supplement this, not replace this. Block with ACLs mostly at gate, and if you have a hyper diverse needs network as far as info needs, then consider security boxes at the major WAN\LAn gateways to LANs by workgroup (segments) and build a WAN\Lan structure into your growth plans.

Use a mix of all the tolls you can get to block viruses, Anti-spam of trainable and untrainable kind is best first bang-for-buck along with gated segments because even today 90% of the viruses come in through email. And, if you can, get your ISP or bandwidth provision folks to preprocess your email with good AV at mail servers that have AV with at least daily updating of defs and heuristics. That will cut your local needs, and since some folk's spam is wanted by others, for individual workstations, trainable Bayesian plus user dynamic customizable anti-spam is also appropriate on workstations as part of an anti-compromising defense.

Use segments as defense zones, layer them, use ACLS mostly at the gateway, and use port rules as much as possible to minimize admin load and admin employee costs related to ACL maintainance. POrovide feedback and loggin means to troubleshoot and find new things that are hitting, and consider IDS also.

With IPV6 implamented this will become something that can be more fiunely tuned,.and in an all-IPV6 world ACLs will play a more important role in gates, but we are not there yet.

Look at how IPV6 by its nature includes MAC info as part of its structure when considering this, please. IPV4 does not. IPV6 allows for so much segmenting that it might be better to more4 granularly segment and anti-spam more and ACL less once you have folks that understand IPV6 in detail.

by stress junkie

I'm an old DEC VMS war horse currently running
Solaris and Linux systems. I can tell you that I've seen
some places where the previous system administrator
had used ACLs as the primary access control. These
were often a disaster interfering with end users' ability
to perform their work. In some cases I just 'ripped out'
all of the ACLs on data disks and reimplemented access
control through the user:group:world permissions. You
can do a lot with groups, and VMS did not allow an
account to be a member of more than one group,
although it had identifiers that were like Unix
secondary user groups.

Solaris and Linux, and probably other Unixes, allow a
user account to belong to many groups. This can be
used very effectively. This kind of access control is
much quicker and easier to audit than checking ACLs
when troubleshooting some access problem.

Then there's a lot that can be done with the traditional
Unix permission settings on system files and
directories. For instance Unix typically allows anyone to
list the root directory. There's no need for that. I
change the ownership/protection to root:root
rwxr-w--x. I do the same on all of the top level
directories except /tmp and /home. I keep the default
setting on /tmp but I change the owner/permission
on /home to root:users rwx--x---. All of the /etc/
*.conf files get root:root rwxr-x---. Why let ordinary
users read configuration files? You can do this sort of
thing all over the file system and greatly restrict what
the typical user can see.

by gshollingsworth

I have dealt with ACL (or ACL-like) permissions since Netware 2.x.

I have seen plenty of instances where admins had attempted to assign access with such granularity and using individual account entries with no or almost no groups. That type of use doesn't scale well and is horrible when access must be adjusted.

The most useful model is allowing multiple group memberships. Also only assign group permission ACLs except for home directories where individual account permissions are sensible.

Which is more efficient in the following:
3 directories - HR, Payroll, Employee list.
2 groups - hr and payroll.
only hr has access to HR,
only payroll has access to Payroll,
both hr and payroll have access to Employee list.

Using user:group:world would require creating another group (employee list) with members of both hr and payroll. Or allowing groups as members of groups, which can cause other problems.

Using ACLs you can allow access to Employee list by both hr and payroll groups.

Ongoing maintenance of access is accomplished by group membership. Auditing of access can be summarized clearly by groups. You would not have to determine that a third group is and should be made up of the members of other groups. You would also not miss removing an account from both the hr and employee list group when a person is moved from hr to marketing.

by lsorensen

Many of your articles have been disappointing, such as this one, becuase they mention a few buzz words but never get into any details. Articles such as this one would much more beneficial if they actually told how to do things rather than that you should do things.

This discussion is closed to new replies.