Unix System Security - PowerPoint PPT Presentation

About This Presentation
Title:

Unix System Security

Description:

UNIX system security can be divided into three main areas of concern. ... Hence, all sensitive information should be stored in locked cabinets. ... – PowerPoint PPT presentation

Number of Views:105
Avg rating:3.0/5.0
Slides: 29
Provided by: ici5
Category:

less

Transcript and Presenter's Notes

Title: Unix System Security


1
Unix System Security
  • UNIX system security can be divided into three
    main areas of concern. Two of these areas,
    account security and network security, are
    primarily concerned with keeping unauthorized
    users from gaining access to the system. The
    third area, file system security, is concerned
    with preventing unauthorized access, either by
    legitimate users or crackers, to the data stored
    in the system.

2
Physical Security
  • Often the subject of internal security is
    overlooked. However, often it is fairly easy for
    someone to get access to systems they are not
    supposed to have access by simply walking up to a
    valid users desk. This can be the cleaning staff
    or a disgruntled (ex)employee making a visit.
    This is the easiest type of security to implement
    and should definitely be included in any security
    plan.

3
  • Console security
  • Machines and consoles need to be secure. A person
    can simply turn off a computer if one has access
    to it. If they have access to the console, they
    can often interrupt the boot process to get
    access to the root prompt. If this doesn't work,
    they can keep guessing the root password in hopes
    of compromising the system. For these reasons
    (and more), the computers and associated consoles
    should be kept in a secure room. A limited number
    of people should have access to this room, of
    course with a limited number of keys. Some places
    actually have security guards let people into the
    computer rooms for guaranteed secure access.
  • If your data is sensitive, be certain to verify
    that there are no alternative methods for getting
    into the room. This includes hidden spare keys in
    an unsecured place, gaps in the raised floors
    that go past the locked access point, and space
    above the ceilings.

4
  • Locking Program for Console
  • trap 1 2 3
  • banner terminal
  • banner locked
  • read key
  • while true
  • do
  • echo Enter your password \c
  • stty -echo
  • read pw
  • stty sane
  • if pw icisa
  • then
  • break
  • else
  • echo Wrong password. You are an
    Unauthorised user.
  • fi
  • done

5
  • Data Security
  • Companies that value their data need a detailed
    backup recovery scheme. This includes on site
    backups for least amount of down time, a copy of
    this data off site in case of computer room
    disasters, as well as contingency plans in place.
    Unfortunately, an easy way to get access to a
    companies data is to gain access to backup tapes
    and sensitive printouts. Hence, all sensitive
    information should be stored in locked cabinets.
    Backup tapes sent off site should be in locked
    containers. Old sensitive printouts and tapes
    should be destroyed.
  • To protect against computer damage from power
    outages, be certain to have your computers on a
    UPS. This provides consistent power, protects
    against outages, as well as protects the computer
    from power spikes. Ideally, there should be a
    backup generator for production systems. For
    non-production systems, there should be a
    automatic way to shutdown the computer if the
    power has switched to the UPS for more than 1/2
    the time the UPS is rated to supply.

6
Unix Network Security
  • Once you put a computer on a network, you allow
    many more people potential access to the machine.
    Without networks, often a machine is not useful.
    The key to network security is to allow only
    those functions that the users actually need.
    Make those services as secure as possible. By
    disabling non-used functions, you have much less
    monitoring/securing.

7
  • Telnet Security
  • Convince your users to use SSH (secure shell).
    SSH provides encrypted traffic to prevent
    snooping. If you MUST use telnet, at least close
    down which IPs you accept telnet from and turn
    off root login.
  • FTP Security
  • As with other services, if you do not need this
    functionality, turn it off. You can turn off
    incoming FTP or simply certain users. If you need
    full FTP functionality, be certain to enable
    logging and monitor syslog. If possible, use
    secure ftp (comes with ssh). Standard FTP is
    known to be a security hazard as it sends
    passwords in clear text.

8
  • Since you only want valid users using FTP, make
    sure you have /etc/ftpusers include all system
    accounts (uucp, bin, daemon, sys, adm, lp, root,
    ...). If there are other users who do not need
    FTP, also place them in this file. Only allow the
    users that actually need them. Give them the
    least amount of access possible. Do not allow
    writable directories unless absolutely necessary.
    If writable directories are needed, sometimes
    write only directories can be utilized.
  • Modem Security
  • Having modems hooked up to one central point
    makes security easier. All modems should have
    additional dial-up password for additional
    security. To do this, setup /etc/d_passwd (see
    d_passwd man page). Once you are finished, verify
    that passwords are not guessable by using CRACK.
    As usual, use one password per user. Be certain
    to disable the account when the user no longer
    needs access. All dial-up modems should log users
    out upon disconnect (hupcl in /etc/gettydefs)

9
Unix Account Security
  • If your accounts are not secure, then your other
    steps won't help much. There is general password
    security as well as special steps to take for
    each type of account.
  • Password Security
  • You want to make sure all accounts have a
    non-guessable password. To ensure that the
    passwords are not guessable, use crack on a
    regular basis. In addition, be certain that
    passwords are changed from time to time. Ideally,
    use one time passwords such as skey. Accounts
    should be disabled when there are several bad
    logins in a row.

10
  • Be certain that passwords are not written down.
    Often people will use their license plate numbers
    or children's names. Unfortunately, these are
    easy to guess passwords. Also, they will use
    passwords from their favorite hobby. Have your
    password dictionary include checking these
    passwords.
  • Having no .netrc files strengthens security.

11
Passwords
  • The password is the most vital part of UNIX
    account security. If a cracker can discover a
    user's password, he can then log in to the system
    and operate with all the capabilities of that
    user. If the password obtained is that of the
    super-user, the problem is more serious the
    cracker will have read and write access to every
    file on the system. For this reason, choosing
    secure passwords is extremely important. Unix
    passwords should be longer (i.e. more than 6
    characters at least) However, if the user
    insists'' that a shorter password be used (by
    entering it three times), the program will allow
    it. No checks for obviously insecure passwords
    (see below) are performed. Thus, it is incumbent
    upon the system administrator to ensure that the
    passwords in use on the system are secure.

12
Selecting Passwords
  • Be certain that passwords are not written down.
    Often people will use their license plate numbers
    or children's names. Unfortunately, these are
    easy to guess passwords. Also, they will use
    passwords from their favorite hobby. Have your
    password dictionary include checking these
    passwords.
  • Having no .netrc files strengthens security. The
    object when choosing a password is to make it as
    difficult as possible for a cracker to make
    educated guesses about what you've chosen. This
    leaves him no alternative but a brute-force
    search, trying every possible combination of
    letters, numbers, and punctuation. A search of
    this sort, even conducted on a machine that could
    try one million passwords per second (most
    machines can try less than one hundred per
    second), would require, on the average, over one
    hundred years to complete. With this as our goal,
    and by using the information in the preceding
    text, a set of guidelines for password selection
    can be constructed

13
  • Don't use your login name in any form (as-is,
    reversed, capitalized, doubled, etc.).
  • Don't use your first or last name in any form.
  • Don't use your spouse's or child's name.
  • Don't use other information easily obtained about
    you. This includes license plate numbers,
    telephone numbers, social security numbers, the
    brand of your automobile, the name of the street
    you live on, etc.
  • Don't use a password of all digits, or all the
    same letter. This significantly decreases the
    search time for a cracker.
  • Don't use a word contained in (English or foreign
    language) dictionaries, spelling lists, or other
    lists of words.

14
  • Don't use a password shorter than six characters.
  • Use a password that is easy to remember, so you
    don't have to write it down.
  • Use a password that you can type quickly, without
    having to look at the keyboard. This makes it
    harder for someone to steal your password by
    watching over your shoulder.

15
Password Policies
  • Although asking users to select secure passwords
    will help improve security, by itself it is not
    enough. It is also important to form a set of
    password policies that all users must obey, in
    order to keep the passwords secure. First and
    foremost, it is important to impress on users the
    need to keep their passwords in their minds only.
    Pass- words should never be written down on desk
    blotters, calendars, and the like. Further,
    storing passwords in files on the computer must
    be prohibited. In either case, by writing the
    pass- word down on a piece of paper or storing it
    in a file, the security of the user's account is
    totally dependent on the security of the paper or
    file, which is usually less than the security
    offered by the password encryption software.

16
  • A second important policy is that users must
    never give out their passwords to others. Many
    times, a user feels that it is easier to give
    someone else his password in order to copy a
    file, rather than to set up the permissions on
    the file so that it can be copied. Unfortunately,
    by giving out the password to another person, the
    user is placing his trust in this other person
    not to distribute the password further, write it
    down, and so on. Finally, it is important to
    establish a policy that users must change their
    passwords from time to time, say twice a year.
    This is difficult to enforce on UNIX, since in
    most implementations, a password-expiration
    scheme is not available. However, there are ways
    to implement this policy, either by using
    third-party software or by sending a memo to the
    users requesting that they change their
    passwords. This set of policies should be printed
    and distributed to all current users of the
    system. It should also be given to all new users
    when they receive their accounts. The policy
    usually carries more weight if you can get it
    signed by the most impressive'' person in your
    organization (e.g., the president of the
    company).

17
Checking Password Security
  • The procedures and policies described in the
    previous sections, when properly implemented,
    will greatly reduce the chances of a cracker
    breaking into your system via a stolen account.
    However, as with all security measures, you as
    the system administrator must periodically check
    to be sure that the policies and procedures are
    being adhered to. One of the unfortunate truisms
    of password security is that, left to their own
    ways, some people will still use cute doggie
    names as passwords'' . The best way to check the
    security of the passwords on your system is to
    use a password-cracking program much like a real
    cracker would use. If you succeed in cracking any
    passwords, those passwords should be changed
    immediately.

18
Accounts Without Passwords
  • Some sites have installed accounts with names
    such as who,'' date,'' lpq,'' and so on
    that execute simple commands. These accounts are
    intended to allow users to execute these commands
    without having to log in to the machine.
    Typically these accounts have no password
    associated with them, and can thus be used by
    anyone. Many of the accounts are given a user id
    of zero, so that they execute with super-user
    permissions. The problem with these accounts is
    that they open potential security holes. By not
    having passwords on them, and by having
    super-user permissions, these accounts
    practically invite crackers to try to penetrate
    them. Usually, if the cracker can gain access to
    the system, penetrating these accounts is simple,
    because each account executes a different
    command. If the cracker can replace any one of
    these commands with one of his own, he can then
    use the unprotected account to execute his
    program with super-user permissions. Simply put,
    accounts without passwords should not be allowed
    on any UNIX system.

19
Root Accounts
  • It is easiest to track changes and security
    violations when very few people who have root
    access, The root password needs to be a strong
    non-guessable password. In addition, change the
    root password every 3 months whenever someone
    leaves company. Always logout of root shells
    never leave root shells unattended.
  • The only place where root should be able to log
    onto directly should be the console (as specified
    in /etc/security). Only root should have UID 0.
  • Check root dot files for security holes. Aliases
    should have full pathnames. Root should NEVER
    have "." in path. The root dot files should ONLY
    have 700 permissions. The minimal umask for root
    is 022 (rwxr-xr-x). It is better to have a umask
    of 077 (rwx------) but often this isn't
    practical.
  • To avoid trojan horse programs, always use full
    pathnames. Also, never allow non-root write
    access to ANY directories in root's path. If
    possible, do not create root's tmp files in
    publicly writable directories.

20
Guest Accounts
  • As with any account, only create guest accounts
    for the time it s needed. Remove the account when
    its purpose is completed. Use non-standard
    account names for guest accounts. Do not use
    "guest". Instead use account names such as
    "fixomni" or "oratmp".
  • Guest accounts should have a strong password and
    a restricted shell. If reasonable, give guest
    accounts a strong umask such as 077.

21
User Accounts
  • User accounts should not be shared. Remove user
    accounts upon termination. Disable login for well
    known accounts that do not need direct login
    access (bin,daemon,sys,uucp,lp,adm).
  • User accounts should have a strong password and
    in some cases, a restricted shell. If reasonable,
    give guest accounts a strong umask such as 077.

22
File System Security
  • File system security is about making sure your
    users can only do what you want them to be able
    to do. This means that you want system programs
    to be secure and users to only be able to write
    where you want them to be able to do so.
  • NFS Security
  • Only run NFS as needed, apply latest patches.
    When creating your /etc/exports file, be certain
    to use limited access flags when possible such as
    read only or no suid. By using fully qualified
    hostnames, you are guaranteed that only the host
    you want to be able to access the file system can
    access it.

23
  • Device Security
  • Device files /dev/null, /dev/tty /dev/console
    should be world writeable but NEVER executable.
    Most other device files should be unreadable and
    unwriteable by regular users.
  • Script Security
  • Never write setuid/setgid shell scripts (can
    break out). Instead, write a compiled program in
    a language like "C". Scripts should ALWAYS have
    full pathnames.
  • Program Security
  • Always get your programs from a known source.
    Verify that it hasn't been hampered with via
    checksum. If you are compiling your own program,
    make sure you know that the compiler hasn't been
    tampered with as well.

24
  • General Security Measures
  • Create minimal writable filesystems (esp. system
    files/directories!). Generally, users should only
    be able to write in their own directories, and
    /tmp. In addition, there will be directories for
    a specific group to write in. This way you
    control how each user can access specific areas
    of the system.
  • Make sure that important files are only
    accessible by authorized personnel. Use
    setuid/setgid only where necessary.

25
Unix Security Testing
  • Security is an ongoing process. However, once the
    software is installed and initial checks
    completed, it can be a simple maintenance task of
    installing latest patches, verifying user
    accounts, running security software (and their
    extensions) and monitoring logs.
  • Always have latest security OS patches installed
  • Subscribe to security mailing lists. Read
    security newsgroups. Keep up to date on the
    latest security procedures.

26
  • Test your system
  • Test w/ SATAN (network security), COPS (Various
    system checks), TIGER (ways for root to be
    compromised), and CRACK (password checker).
    Install Tripwire to detects changes to files).
  • Monitor log files
  • Check btmp, wtmp, syslog, sulog etc. regularly.
    Set up automatic email or paging to warn system
    administrators of any suspicious behavior. Also
    check your snort logs.

27
  • Thankyou

28
Presentation prepared byMr. Dharampal,Data
Processor Mr.Srinivas sastry,Section
Officero/o the Accountant General(AE)I,M.P.
Write a Comment
User Comments (0)
About PowerShow.com