|
Home > Archive > Unix administration > January 2004 > How to tighten UNIX security
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to tighten UNIX security
|
|
| Stephen 2004-01-23, 4:28 pm |
| Hi there
I am looking at the best methods or products that can be used to
restrict access to UNIX machines. Does anyone have any recommendations
that you might be able to supply me.
i.e. programs that create limited life passwords
etc
Stephen
| |
| Akop Pogosian 2004-01-23, 4:28 pm |
| Stephen <stephen.day@eps-hq.com> wrote:quote:
> Hi there
quote:
> I am looking at the best methods or products that can be used to
> restrict access to UNIX machines. Does anyone have any recommendations
> that you might be able to supply me.
quote:
> i.e. programs that create limited life passwords
If you're looking for general information on Unix security, consider
picking up the latest edition of O'Reilly's "Practical Unix and
Internet Security" book. As for limited life passwords, there exist
built-in and/or third party tools for doing it under different OSes.
OPIE implements one-time passwords. You can find it on google. There
might be similar commercial products but I haven't heard of any
myself. Also, many unix systems implement password aging, so you might
want to investigate whether your system's default password aging
support is good enough for your environment.
-akop
| |
| Michael Heiming 2004-01-23, 4:28 pm |
| Stephen <stephen.day@eps-hq.com> wrote:quote:
> Hi there
quote:
> I am looking at the best methods or products that can be used to
> restrict access to UNIX machines. Does anyone have any recommendations
> that you might be able to supply me.
quote:
> i.e. programs that create limited life passwords
Depends on which *nix you are using, most have password aging
build-in, you perhaps just need to enable it, check the docs
of your OS.
As a rule of thumb, shut down any unneeded services, use ssh/scp
instead of telnet/ftp and other insecure r* services.
Use tcpwrapper if applicable.
Keep your system updated with the latest vendor patches.
Get a book about unix security, O'Reilly books tend to be quite
good.
--
Michael Heiming
Remove +SIGNS and www. if you expect an answer, sorry for
inconvenience, but I get tons of SPAM
| |
| Akop Pogosian 2004-01-23, 4:28 pm |
| Stephen <stephen.day@eps-hq.com> wrote:quote:
> Hi there
quote:
> I am looking at the best methods or products that can be used to
> restrict access to UNIX machines. Does anyone have any recommendations
> that you might be able to supply me.
quote:
> i.e. programs that create limited life passwords
If you're looking for general information on Unix security, consider
picking up the latest edition of O'Reilly's "Practical Unix and
Internet Security" book. As for limited life passwords, there exist
built-in and/or third party tools for doing it under different OSes.
OPIE implements one-time passwords. You can find it on google. There
might be similar commercial products but I haven't heard of any
myself. Also, many unix systems implement password aging, so you might
want to investigate whether your system's default password aging
support is good enough for your environment.
-akop
| |
| Michael Heiming 2004-01-23, 4:28 pm |
| Stephen <stephen.day@eps-hq.com> wrote:quote:
> Hi there
quote:
> I am looking at the best methods or products that can be used to
> restrict access to UNIX machines. Does anyone have any recommendations
> that you might be able to supply me.
quote:
> i.e. programs that create limited life passwords
Depends on which *nix you are using, most have password aging
build-in, you perhaps just need to enable it, check the docs
of your OS.
As a rule of thumb, shut down any unneeded services, use ssh/scp
instead of telnet/ftp and other insecure r* services.
Use tcpwrapper if applicable.
Keep your system updated with the latest vendor patches.
Get a book about unix security, O'Reilly books tend to be quite
good.
--
Michael Heiming
Remove +SIGNS and www. if you expect an answer, sorry for
inconvenience, but I get tons of SPAM
| |
|
| You also can you a number of tools to scan your computers and the network to
test how secure they are. This is called penetration testing or pen testing
for short.
I've used tools like Nessus, nmap, nikto, whcc a bunch more, there is a lot
out there.
Try downloading a tool called Operator, http://www.ussysadmin.com/operator.
This bootable CD contains tons of security auditing tools and it all runs
from the CD, no installation requried.
Good luck dude
Bud
"Stephen" <stephen.day@eps-hq.com> wrote in message
news:a4e5eece.0307110118.3ca69793@posting.google.com...quote:
> Hi there
>
> I am looking at the best methods or products that can be used to
> restrict access to UNIX machines. Does anyone have any recommendations
> that you might be able to supply me.
>
> i.e. programs that create limited life passwords
>
>
> etc
>
> Stephen
| |
|
| You also can you a number of tools to scan your computers and the network to
test how secure they are. This is called penetration testing or pen testing
for short.
I've used tools like Nessus, nmap, nikto, whcc a bunch more, there is a lot
out there.
Try downloading a tool called Operator, http://www.ussysadmin.com/operator.
This bootable CD contains tons of security auditing tools and it all runs
from the CD, no installation requried.
Good luck dude
Bud
"Stephen" <stephen.day@eps-hq.com> wrote in message
news:a4e5eece.0307110118.3ca69793@posting.google.com...quote:
> Hi there
>
> I am looking at the best methods or products that can be used to
> restrict access to UNIX machines. Does anyone have any recommendations
> that you might be able to supply me.
>
> i.e. programs that create limited life passwords
>
>
> etc
>
> Stephen
| |
| Jeffrey Silverman 2004-01-23, 4:29 pm |
| On Fri, 11 Jul 2003 02:18:53 -0700, Stephen wrote:
quote:
> Hi there
>
> I am looking at the best methods or products that can be used to restrict
> access to UNIX machines. Does anyone have any recommendations that you
> might be able to supply me.
>
> i.e. programs that create limited life passwords
>
>
> etc
>
> Stephen
This is a link to the "Best Practices" guidlines for my university (where
I work). They may be specific to JHU in some places but overall they are
good general practices for setting up secure systems.
http://nts.jhmi.edu/es/infosec/
Links are down the page under "Best Practices Documents"
later...
--
Jeffrey D. Silverman | jeffrey AT jhu DOT edu
Johns Hopkins university | Baltimore, MD
Website | http://www.wse.jhu.edu/newtnotes/
| |
| Jeffrey Silverman 2004-01-23, 4:29 pm |
| On Fri, 11 Jul 2003 02:18:53 -0700, Stephen wrote:
quote:
> Hi there
>
> I am looking at the best methods or products that can be used to restrict
> access to UNIX machines. Does anyone have any recommendations that you
> might be able to supply me.
>
> i.e. programs that create limited life passwords
>
>
> etc
>
> Stephen
This is a link to the "Best Practices" guidlines for my university (where
I work). They may be specific to JHU in some places but overall they are
good general practices for setting up secure systems.
http://nts.jhmi.edu/es/infosec/
Links are down the page under "Best Practices Documents"
later...
--
Jeffrey D. Silverman | jeffrey AT jhu DOT edu
Johns Hopkins university | Baltimore, MD
Website | http://www.wse.jhu.edu/newtnotes/
| |
| Jim Hollenback 2004-01-23, 4:29 pm |
| Stephen (stephen.day@eps-hq.com) wrote:
: Hi there
: I am looking at the best methods or products that can be used to
: restrict access to UNIX machines. Does anyone have any recommendations
: that you might be able to supply me.
: i.e. programs that create limited life passwords
If all your after is password aging, then man 4 passwrd would be of interest.
For more robust access controls then you might be interested in the trusted
system option that can be setup with SAM. See some of the other man pages
list in the SEE ALSO section.
--
Jim Hollenback
jholly@cup.hp.com
my opinion.
| |
| Jim Hollenback 2004-01-23, 4:29 pm |
| Stephen (stephen.day@eps-hq.com) wrote:
: Hi there
: I am looking at the best methods or products that can be used to
: restrict access to UNIX machines. Does anyone have any recommendations
: that you might be able to supply me.
: i.e. programs that create limited life passwords
If all your after is password aging, then man 4 passwrd would be of interest.
For more robust access controls then you might be interested in the trusted
system option that can be setup with SAM. See some of the other man pages
list in the SEE ALSO section.
--
Jim Hollenback
jholly@cup.hp.com
my opinion.
| |
| Jeffrey Silverman 2004-01-23, 4:29 pm |
| On Thu, 17 Jul 2003 13:46:26 +0000, Chris F.A. Johnson wrote:
quote:
> On Thu, 17 Jul 2003 at 12:55 GMT, Jeffrey Silverman wrote:
>
> Sorry!
>
> The web page you are looking for has been designated for use by computers
> within the Johns Hopkins campuses only.
hmm..
I was afraid that might happen
sorry about that!
--
Jeffrey D. Silverman | jeffrey AT jhu DOT edu
Johns Hopkins university | Baltimore, MD
Website | http://www.wse.jhu.edu/newtnotes/
| |
| Jeffrey Silverman 2004-01-23, 4:29 pm |
| On Thu, 17 Jul 2003 13:46:26 +0000, Chris F.A. Johnson wrote:
quote:
> On Thu, 17 Jul 2003 at 12:55 GMT, Jeffrey Silverman wrote:
>
> Sorry!
>
> The web page you are looking for has been designated for use by computers
> within the Johns Hopkins campuses only.
hmm..
I was afraid that might happen
sorry about that!
--
Jeffrey D. Silverman | jeffrey AT jhu DOT edu
Johns Hopkins university | Baltimore, MD
Website | http://www.wse.jhu.edu/newtnotes/
| |
| James T. Dennis 2004-01-23, 4:29 pm |
| Stephen <stephen.day@eps-hq.com> wrote:quote:
> Hi there
quote:
> I am looking at the best methods or products that can be used to
> restrict access to UNIX machines. Does anyone have any recommendations
> that you might be able to supply me.
quote:
> i.e. programs that create limited life passwords
Most versions of UNIX (and distributions of Linux) support password
aging. In the case of Linux it's through the Shadow suite and PAM
(pluggable authentication modules). I think FreeBSD's PAM is a port
from the Linux code base. HP-UX 11.0 apparently integrated a port from
the Sun implementation.
PAM (supported by Linux and Solaris, at least --- though the implementations
are somewhat different) provides and API for administrator configurable
authentication. You can think of PAM as being a sort of modular "language"
in roughly the same sense that packet filtering rules are.
A user attempting to authenticate against a PAM linked service is
subjected to an arbitrary number of tests and directives. They fall
into categories such as: auth, account, session and password.
(This is the most confusing part of PAM, auth is used to prompt for
passwords, challenge for authentication responses, etc; "password"
type modules are for updating and manipulating the auth token --
forcing the user to change their password or checking and warning about
weak passwords, etc, account is for limiting and maintaining account
access in ways beyond authentication --- time of day/week, allowed
terminal or connection source address, etc.)
So, with PAM each service has a list of rules associated with it.
In *old* versions of Linux PAM there was a single /etc/pam.conf file
which had the service names as a prefix for each line. In more
recent versions there's an /etc/pam.d/ directory with a control file
for each service (with /etc/pam.d/other being a default for PAM
services lacking their own conf file. I suspect you could still use
the old pam.conf file if you wanted.
A typical PAM config file:
auth requisite pam_securetty.so
auth requisite pam_nologin.so
auth required pam_env.so
auth required pam_unix.so nullok
account required pam_unix.so
session required pam_unix.so
session optional pam_lastlog.so
session optional pam_motd.so
session optional pam_mail.so standard noenv
password required pam_unix.so nullok obscure min=4
(default for /etc/pam.d/login on a Debian Sarge system)
The first line implements the check for /etc/securetty --- root
can't directly login to "insecure" terminals. The next checks for
an /etc/nologin file. The next will set up a users environment
with the contents of /etc/environment (in a shell independent manner)
The next three lines, and the last line all refer to pam_unix.so;
thus all of them implement the normal UNIX account, authorization,
and session semantics --- reading account info from using getpwent()
using the MD5 password hash from /etc/shadow, and spawning a user's
shell based on the last field of the account info.
As for as I know it's all done by getpwent(), which automatically
merges /etc/shadow password hashes if the process can read /etc/shadow
at this point --- allowing for SGID shadow to work. This is important
because it means that various other NSS passwd, shadow, and group
backends like NIS, NIS+, even LDAP, etc. will automatically work with
pam_unix.so.
The next three modules display the last login info (including the
number of failed login attempts since the last login), the message of
the day, and the status of your mail.
As you can see, PAM breaks the process of "normal" login into
a number of other steps. It can apply similar handling to su, sudo,
the passwd command, ssh (if ssh is linked to it), rsh/rlogin,
or any other service or program that's linked against it's libraries
and written to its APIs.
The Linux version of PAM is documented primarily at:
http://www.kernel.org/pub/linux/lib...Linux-PAM-html/
You can also limit access to services based on various networking
criteria; source IP address being the primary one. That is most
commonly done with Wietse Venema's TCP Wrappers and or by linking
against his "libwrap" libraries. This xinetd is normally linked
against libwrap; as is the Linux version of portmapper.
As for other "products" and methods for limiting access to your UNIX
machine; most of them depend on your version of UNIX. Since authentication
and authorization is done in userspace under UNIX, in general programs
and implement any policy the programmer wants given access to root or
to SUID helper utilities or root-run daemons. This is a bane and a blessing
since very few programs are robust enough to be trusted with root; set
a large number of programs need to access "root" powers under UNIX.
quote:
> etc
> Stephen
--
Jim Dennis,
Starshine: Signed, Sealed, Delivered
| |
| James T. Dennis 2004-01-23, 4:29 pm |
| Stephen <stephen.day@eps-hq.com> wrote:quote:
> Hi there
quote:
> I am looking at the best methods or products that can be used to
> restrict access to UNIX machines. Does anyone have any recommendations
> that you might be able to supply me.
quote:
> i.e. programs that create limited life passwords
Most versions of UNIX (and distributions of Linux) support password
aging. In the case of Linux it's through the Shadow suite and PAM
(pluggable authentication modules). I think FreeBSD's PAM is a port
from the Linux code base. HP-UX 11.0 apparently integrated a port from
the Sun implementation.
PAM (supported by Linux and Solaris, at least --- though the implementations
are somewhat different) provides and API for administrator configurable
authentication. You can think of PAM as being a sort of modular "language"
in roughly the same sense that packet filtering rules are.
A user attempting to authenticate against a PAM linked service is
subjected to an arbitrary number of tests and directives. They fall
into categories such as: auth, account, session and password.
(This is the most confusing part of PAM, auth is used to prompt for
passwords, challenge for authentication responses, etc; "password"
type modules are for updating and manipulating the auth token --
forcing the user to change their password or checking and warning about
weak passwords, etc, account is for limiting and maintaining account
access in ways beyond authentication --- time of day/week, allowed
terminal or connection source address, etc.)
So, with PAM each service has a list of rules associated with it.
In *old* versions of Linux PAM there was a single /etc/pam.conf file
which had the service names as a prefix for each line. In more
recent versions there's an /etc/pam.d/ directory with a control file
for each service (with /etc/pam.d/other being a default for PAM
services lacking their own conf file. I suspect you could still use
the old pam.conf file if you wanted.
A typical PAM config file:
auth requisite pam_securetty.so
auth requisite pam_nologin.so
auth required pam_env.so
auth required pam_unix.so nullok
account required pam_unix.so
session required pam_unix.so
session optional pam_lastlog.so
session optional pam_motd.so
session optional pam_mail.so standard noenv
password required pam_unix.so nullok obscure min=4
(default for /etc/pam.d/login on a Debian Sarge system)
The first line implements the check for /etc/securetty --- root
can't directly login to "insecure" terminals. The next checks for
an /etc/nologin file. The next will set up a users environment
with the contents of /etc/environment (in a shell independent manner)
The next three lines, and the last line all refer to pam_unix.so;
thus all of them implement the normal UNIX account, authorization,
and session semantics --- reading account info from using getpwent()
using the MD5 password hash from /etc/shadow, and spawning a user's
shell based on the last field of the account info.
As for as I know it's all done by getpwent(), which automatically
merges /etc/shadow password hashes if the process can read /etc/shadow
at this point --- allowing for SGID shadow to work. This is important
because it means that various other NSS passwd, shadow, and group
backends like NIS, NIS+, even LDAP, etc. will automatically work with
pam_unix.so.
The next three modules display the last login info (including the
number of failed login attempts since the last login), the message of
the day, and the status of your mail.
As you can see, PAM breaks the process of "normal" login into
a number of other steps. It can apply similar handling to su, sudo,
the passwd command, ssh (if ssh is linked to it), rsh/rlogin,
or any other service or program that's linked against it's libraries
and written to its APIs.
The Linux version of PAM is documented primarily at:
http://www.kernel.org/pub/linux/lib...Linux-PAM-html/
You can also limit access to services based on various networking
criteria; source IP address being the primary one. That is most
commonly done with Wietse Venema's TCP Wrappers and or by linking
against his "libwrap" libraries. This xinetd is normally linked
against libwrap; as is the Linux version of portmapper.
As for other "products" and methods for limiting access to your UNIX
machine; most of them depend on your version of UNIX. Since authentication
and authorization is done in userspace under UNIX, in general programs
and implement any policy the programmer wants given access to root or
to SUID helper utilities or root-run daemons. This is a bane and a blessing
since very few programs are robust enough to be trusted with root; set
a large number of programs need to access "root" powers under UNIX.
quote:
> etc
> Stephen
--
Jim Dennis,
Starshine: Signed, Sealed, Delivered
| |
| Kelly Paletta 2004-01-23, 4:29 pm |
| jholly@cup.hp.com (Jim Hollenback) wrote in message news:<3f16cd7b$1@usenet01.boi.hp.com>...quote:
> Stephen (stephen.day@eps-hq.com) wrote:
> : Hi there
>
> : I am looking at the best methods or products that can be used to
> : restrict access to UNIX machines. Does anyone have any recommendations
> : that you might be able to supply me.
>
> : i.e. programs that create limited life passwords
>
> If all your after is password aging, then man 4 passwrd would be of interest.
> For more robust access controls then you might be interested in the trusted
> system option that can be setup with SAM. See some of the other man pages
> list in the SEE ALSO section.
Forgive the commercial plug...
Open Systems Management develops two tools that might be of use to
you:
COSuser (www.cosuser.com) provides secure identity management. This
includes role-based access control, enforcement of password rules,
password aging, detailed audit trails of all user management activity
and (as they say on TV) much, much more.
COSduty (www.cosduty.com) is a workflow manager that also includes the
ability to securely delegate permissions. COSduty allows low level
staff to perform specific tasks as root without actually knowing root
password--like sudo but with audit trails and several other nifty
features.
Visit the URLs listed above or www.osmcorp.com for white papers,
product briefs and other details.
I now return you to previously scheduled programming already in
progress...
Kelly Paletta
Account Manager
Open Systems Management
kelly.paletta@osminc.com
| |
| Kelly Paletta 2004-01-23, 4:29 pm |
| jholly@cup.hp.com (Jim Hollenback) wrote in message news:<3f16cd7b$1@usenet01.boi.hp.com>...quote:
> Stephen (stephen.day@eps-hq.com) wrote:
> : Hi there
>
> : I am looking at the best methods or products that can be used to
> : restrict access to UNIX machines. Does anyone have any recommendations
> : that you might be able to supply me.
>
> : i.e. programs that create limited life passwords
>
> If all your after is password aging, then man 4 passwrd would be of interest.
> For more robust access controls then you might be interested in the trusted
> system option that can be setup with SAM. See some of the other man pages
> list in the SEE ALSO section.
Forgive the commercial plug...
Open Systems Management develops two tools that might be of use to
you:
COSuser (www.cosuser.com) provides secure identity management. This
includes role-based access control, enforcement of password rules,
password aging, detailed audit trails of all user management activity
and (as they say on TV) much, much more.
COSduty (www.cosduty.com) is a workflow manager that also includes the
ability to securely delegate permissions. COSduty allows low level
staff to perform specific tasks as root without actually knowing root
password--like sudo but with audit trails and several other nifty
features.
Visit the URLs listed above or www.osmcorp.com for white papers,
product briefs and other details.
I now return you to previously scheduled programming already in
progress...
Kelly Paletta
Account Manager
Open Systems Management
kelly.paletta@osminc.com
| |
| Stephen 2004-01-23, 4:29 pm |
| Thanks for that Jeffrey, shame the link is not open to the world. Is
there any way that the files could be posted to me or this new groups.
cheers
"Jeffrey Silverman" <jeffrey@jhu.edu> wrote in message news:<pan.2003.07.17.17.53.27.698797@jhu.edu>...quote:
> On Thu, 17 Jul 2003 13:46:26 +0000, Chris F.A. Johnson wrote:
>
>
> hmm..
>
> I was afraid that might happen
>
> sorry about that!
| |
| Stephen 2004-01-23, 4:29 pm |
| Thanks for that Jeffrey, shame the link is not open to the world. Is
there any way that the files could be posted to me or this new groups.
cheers
"Jeffrey Silverman" <jeffrey@jhu.edu> wrote in message news:<pan.2003.07.17.17.53.27.698797@jhu.edu>...quote:
> On Thu, 17 Jul 2003 13:46:26 +0000, Chris F.A. Johnson wrote:
>
>
> hmm..
>
> I was afraid that might happen
>
> sorry about that!
| |
| Jeffrey Silverman 2004-01-23, 4:29 pm |
| On Tue, 22 Jul 2003 06:41:31 -0700, Stephen wrote:
[QUOTE][color=darkred]
> Thanks for that Jeffrey, shame the link is not open to the world. Is there
> any way that the files could be posted to me or this new groups.
>
> cheers
>
> "Jeffrey Silverman" <jeffrey@jhu.edu> wrote in message
> news:<pan.2003.07.17.17.53.27.698797@jhu.edu>...
I'll have to ask my "powers that be"...
If yes, I'll post 'em on my website.
--
Jeffrey D. Silverman | jeffrey AT jhu DOT edu
Johns Hopkins university | Baltimore, MD
Website | http://www.wse.jhu.edu/newtnotes/
| |
| Jeffrey Silverman 2004-01-23, 4:29 pm |
| On Tue, 22 Jul 2003 06:41:31 -0700, Stephen wrote:
[QUOTE][color=darkred]
> Thanks for that Jeffrey, shame the link is not open to the world. Is there
> any way that the files could be posted to me or this new groups.
>
> cheers
>
> "Jeffrey Silverman" <jeffrey@jhu.edu> wrote in message
> news:<pan.2003.07.17.17.53.27.698797@jhu.edu>...
I'll have to ask my "powers that be"...
If yes, I'll post 'em on my website.
--
Jeffrey D. Silverman | jeffrey AT jhu DOT edu
Johns Hopkins university | Baltimore, MD
Website | http://www.wse.jhu.edu/newtnotes/
|
|
|
|
|