Results 1 to 3 of 3

Thread: Linux Security Measures [part 1]

  1. #1
    Join Date
    Sep 2001

    Linux Security Measures [part 1]

    Linux Security Measures
    Part 1

    Written By: Nitro

    Email: noixtirdoe@aaahawk.com

    2 July 2002

    This is my first tutorial, and I decided to do it on something that I am currently
    learning: linux security. Now the techniques/practices I use are not the only ones,
    however, they are pretty common. The techniques/practices I use are also ones I
    read about in various tutorials, so I will be incorporating some of the pieces from
    the other tuts. You can look at my bibliography at the end of my tutorial to see
    my resources.

    | Contents:
    | 1. Shutting down services
    | 2. Commenting-out startup scripts
    | 3. Deleting default usernames
    | 4. Permissions
    | 5. SUID/SGID programs
    | 6. Logs
    | 7. IPV4 settings (brief overview)
    | 8. Closing
    | 9. Bibliography

    1. Shutting down services

    First off, to find out what services we have running on our computer, we use the 'grep'
    command. Example:

    $ grep -v "^#" /etc/inetd.conf

    By using the '-v' option of grep, we tell it to look for all lines that DO NOT match
    "^#" in the file /etc/inetd.conf.

    So in effect, grep outputs all of the lines in the inetd.conf file that are not commented
    out, thus we get all the services running on our computer.


    If you are just going to be a home user that surfs the internet, you probably don't want
    all if any of these services running. So what do we do to get rid of the services we don't
    want? Easy. You want to open /etc/inetd.conf in your text editor of choice (i.e., vi),
    and put comments (#) on the lines where the services you don't want are. Example:

    $ vi /etc/inetd.conf


    See the "#" symbols in front of the services? You just commented them out, so now they
    won't run.

    Type (without quotes):


    to write (save) and quit vi. Now we need to restart inetd so our new settings take

    $ ps -x # find /usr/bin/inetd's PID


    332 ? s 0:00 /usr/sbin/inetd

    Ah, inetd's PID is 332. So how do we restart it? Check this out:

    $ kill -HUP 332 # restarts /usr/sbin/inetd

    There we go. Take a look at your services that are running now:

    $ ps -x # see if the services we shutdown are still running...

    Nope. They're not running anymore. That's a good thing.

    2. Commenting-out startup scripts

    In Linux, there is a directory called '/etc/rc.d' that holds the files that tells your
    system what to run at boot time. All you have to do is comment-out the scripts you don't
    need (just like we did for our Internet services).

    3. Deleting default usernames

    You really want to get rid of any default usernames that come with Linux. The only ones
    you really need are 'root' (obviously) and your own usernames (and the usernames you
    create). To delete usernames, do this (as root):

    root# userdel -r <username>

    This brings me to another security point. You are going to need to manage which users
    you want to be able to 'su' up to root. My suggestion is to change the group that
    /bin/su runs under (which is default 'root'). Second, you are going to want to change
    the mode of /bin/su to something a little more secure; say something like an SUID root
    file, root has read, write, and execute permissions, group 'wheel' has read and
    execute permissions, while other users not in group 'wheel' have no access whatsoever.
    How do we do that you ask? Like this:

    root# /bin/chgrp wheel /bin/su
    root# /bin/chmod 4750 /bin/su

    Now 'su' will only be permitted to users in the group 'wheel' (and root of course).
    So how do you change what groups users belong to? Well, you would use the
    'usermod' program. However, you must add ALL the groups <user> belongs to first, then
    you can add other groups. You have to remember to include all groups the user belongs
    to, or he/she will only belong to one group. Here is the command you can use to modify
    a user account:

    root# usermod -G users,wheel,<other_groups> <username>

    Also with this command, you must remember not to leave any whitespace in between groups
    and commas. And that is how you can add users to different groups. Check out
    'man usermod' for more information regarding this.

    4. Permissions

    File permissions are the heart and soul of Linux security. You don't want an unauthorized
    user gaining access to a root file and modifying it, deleting it, or even backdooring your
    binaries. You have to lock these down big time; one slip up and you might have a lot of
    trouble on your hands. One thing you should change file permissions on are all of your
    world-writable files/directories. You should really only have world-writable directories
    and files in some rare conditions (i.e., your 'tmp' directories and 'tmp' files).

    So how do we find world-writable files? Try this:

    $ find / -perm -0002 -type f -ls

    To find world-writable directories:

    $ find / -perm -0002 -type d -ls

    The 'find' command searches the root directory for files with world-writable permissions
    (-perm -0002), searches for -type f (files), and on the second line searches for
    -type d (directories), then the '-ls' tells find to output the results in the form of
    'ls -dils'.

    So let's say we found two world-writable files in the directory /home/nitro. They
    are called 'linuxsecurity.txt' and 'testscript.txt'. (I am assuming /home/nitro
    is our present directory).

    -rw-rw-rw 1 nitro users 4096 Jul 2 10:34 linuxsecurity.txt
    -rw-rw-rw 1 nitro users 4096 Jul 2 11:29 testscript.txt

    As they are now, anybody in the group 'users' and anybody else who is not in group 'users'
    can read and write to those files.

    NOTE: if you don't know about permissions and how they are set up, I strongly recommend
    that you 'man chmod' to learn more.

    So, what permissions should we give to these files? I think we'll give the owner read
    and write permissions, and everybody else has no access.

    $ chmod 0600 linuxsecurity.txt testscript.txt

    Do an 'ls -l' to see your new permissions:

    $ ls -l
    -rw------- 1 nitro users 4096 Jul 2 10:34 linuxsecurity.txt
    -rw------- 1 nitro users 4096 Jul 2 13:56 testscript.txt

    Now those files can only be read from and written to by the owner (in
    this case, 'nitro'). You should go through your Linux OS and look at all the file
    permissions and make modifications if you feel it's necessary.

    5. SUID/SGID programs

    I will start out by explaining what SUID (setuid) programs are. In short, they are
    programs that run as a different user. So let's say user 'nitro' executes
    /usr/sbin/traceroute; since traceroute is SUID root, nitro essentially is the root
    user for as long as the program is running. Now having traceroute SUID root isn't
    that big of a security risk, but I might make it 'chmod 4750' and change the group
    to 'wheel' so only members of 'wheel' can execute the program as SUID root.

    The main risk with letting anybody use SUID root programs is that you might get a
    malicious user on your computer who has an exploit to overflow a buffer in a
    SUID root program.

    This is a little beyond the scope of this paper, however, I am talking about security
    and SUID root programs; so what happens if a user runs a buffer overflow exploit on a
    SUID root program? Well, the buffer will overflow with information and once that
    happens, the malicious user can send commands via his/her exploit through the SUID root
    program. The malicious user now has root access to your computer.

    Going back to 'traceroute', I don't know of any times that someone wrote an exploit that
    gained root access through it. So I'm pretty confident that you can keep traceroute
    SUID root and not have very many problems, if any.

    SGID programs are the same as SUID programs, just that instead of having different user
    permissions while running the program, you have different group permissions.

    What we need to do is find all SUID and SGID programs and if need be, alter them.

    root# find / -type f -perm +6000 -ls

    'find' looks in the root directory for all normal files with permissions of '6000'.
    Permissions of '6000' means to look for SUID/SGID files (hopefully you read 'man chmod'
    by now). '6000', in "human format" would be ---s--s--, however, since we told the
    computer to find '-perm +6000', we are looking for any and all files with SUID/SGID set,
    no matter if they are '-rwsrwsrwx' or '---s--s---'; we are looking for all files in
    between those sets of permissions. Refer to 'man find' for more information.

    Now that we have a list of SUID/SGID files, we can go through and 'chmod -s' all files
    we don't think need to run as root.

    Some files you can leave as SUID root are:

    traceroute, ping, su, passwd, screen

    6. Logs

    By default, there are only two logs in Linux: 'syslog' and 'messages'. I am going to
    show you how to make your own logs so you can log what you want.

    Logs are made from two daemons: 'klogd' and 'syslogd'. 'klogd' intercepts and logs
    linux kernel messages, and 'syslogd' logs all system messages. To configure your logs,
    you must edit /etc/syslog.conf; this file tells 'syslogd' what to log and where to put

    Do a 'man syslog.conf' to learn more about the log configuration. Here is an example
    of my own /etc/syslog.conf file:

    # all info and notices
    *.=info;*.=notice /usr/adm/messages

    # all debug messages
    *.=debug /usr/adm/debug

    # all error messages
    *.=err /usr/adm/syslog

    # all alert messages sent directly to me
    *.=alert root,nitro

    # all emergency messages sent directly to me
    *.=emerg root,nitro

    # connections and logins
    authpriv.*;auth.* /admin/nitro/auth.log
    authpriv.*;auth.* /var/log/secure

    # mail messages
    mail.info;mail.notice /var/log/maillog

    # daemon messages
    daemon.info;daemon.notice /var/log/daemon.log

    # send all logs to sys.log
    *.* /admin/nitro/sys.log

    I think it's pretty self-explanatory, I made my own logs to log what I wanted.
    So now we have to make sure our logs are secure and can't be altered by anyone except
    root. You should 'chmod 0660' or 'chmod 0600' all your logs so only root can write to
    them. Then you should 'chattr +a' all of them so your logs can only be appended to.
    Read 'man chattr' for more information. You also want to make your /etc/syslog.conf
    file super-secure so no one can alter or even look at it to find out where your logs are.
    I would suggest a 'chmod 0000' and a 'chattr +a' for /etc/syslog.conf; you can always
    'chmod 0600' and 'chattr -a' when you (root) need to alter syslog.conf.

    7. IPV4 settings

    You can find the ipv4 settings in the /proc/sys/net/ipv4 directory. These files control
    various things that have to do with the internet (ICMP, IP, TCP). I am going to list
    some of the most common ones and tell you how to make them act the way you want. This
    list isn't complete, but the ones I don't mention you can look up and learn about on
    your own.

    ICMP settings

    If this option is set to '1' (on), it tells the kernel to ignore icmp echo requests.
    If it is set to '0' (off), then it allows icmp echo requests. To enable this option,
    type in your shell (as root):

    root# echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

    This command writes a '1' to the icmp_echo_ignore_all file. To disable (to allow icmp echo
    requests), type:

    root# echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_all

    If set to '1' (on), your computer will ignore icmp echo broadcasts. If you have this
    set to '0', your computer may be used to receive icmp packets set to broadcast, and then
    send them (like a router) to their destination. This could be abused by a malicious remote
    user to use your computer as a gateway for sending DoS attacks through.

    A value of zero disables replying to packets that are trying to reach destinations
    unreachable. Any positive number sets the maximum package rate in hundredths of seconds.
    You should keep this disabled unless you are using this computer as a router.

    icmp_echoreply_rate, icmp_paramprob_rate, and icmp_timeexceed_rate have the same
    parameters as icmp_destunreach_rate.

    IP settings

    This file is set to '1' if your computer received its IP configuration by RARP, BOOTP,
    DHCP, or similar. Otherwise it's set to '0'.

    Time to Live for IPV4 interfaces. Set to max number of hops a packet may travel.

    root# echo "30" > /proc/sys/net/ipv4/ip_default_ttl

    Enable dynamic IP addresses. Useful for dialup, but can be used with any connection
    (as far as I know). '1' enables, '0' disables.

    Enable or disable the forwarding of packets between interfaces. Use this (enabled) if
    your system is properly firewalled and is being used as a router/gateway between your
    internal network and the Internet (or other network). For normal users, this should
    be disabled (set to '0').

    Range of ports used by TCP and UDP to choose a local port. Default range of ports is
    1024-4999 (as all ports 0-1023 are reserved). To change:

    root# echo "5000-10000" > /proc/sys/net/ipv4/ip_local_port_range

    The range can be any numbers you want except the reserved ones.

    Global switch to turn path MTU discovery off. '1' for no path MTU discovery, '0' to allow
    path MTU discovery.

    Enable/disable debugging of IP masquerading.

    ipfrag_high_thresh and ipfrag_low_thresh:
    Maximum memory used to reassemble IP fragments. When ipfrag_high_thresh bytes of memory
    is allocated, the fragment handler will toss packets until ipfrag_low_thresh is reached.

    Time in seconds to keep an IP fragment in memory. Example:

    root# echo "30" > /proc/sys/net/ipv4/ipfrag_time

    TCP settings

    tcp_retrans_collapse: On retransmit, try to send larger packets to work around bugs in
    certain TCP stacks. Set to '0' to disable, '1' to enable.

    Number of 'keep alive' probes TCP sends out (when enabled) before it determines the
    connection was lost.

    How often TCP sends out 'keep alive' messages (when enabled). Default is two hours.

    Select acknowledgements. Used to convey extended acknowledgement information from the
    receiver to the sender over an established TCP connection. See RFC 2018 for more

    Defines how often an answer to a TCP connection request is retransmitted before giving up.

    Defines how often a TCP packet is retransmitted before giving up.

    Enable timestamps. See RFC 1323 section 3.2 for more information.

    Enable the strict RFC 793 interpretation of the TCP urgent pointer field. Enabling this
    option may lead to interoperability problems. It is disabled by default.

    Send out 'syncookies' when the SYN backlog queue of a socket overflows. This prevents
    SYN flood attacks when enabled. It is disable by default, so make sure you:

    root# echo "1" > /proc/sys/net/ipv4/tcp_syncookies

    to turn it on.

    See RFC 1323 for more information.

    The amount of time in seconds it takes to receive a final FIN packet before the socket is
    closed. Although it is a violation of the TCP specification, I doubt anyone will complain
    because, when enabled, this option can prevent DoS attacks.

    Indicates how many keep alive probes are sent per slow timer run. Do not set it too high
    or your probes will be sent in quick bursts.

    Length of the per-socket backlog queue. When syncookies are enabled, the packets are still
    answered and the maximum queue is ignored.

    8. Closing

    This is the end of my first tutorial on linux security; I hope that I can continue making
    other parts to this tutorial, so if you have any feedback, questions, problems, requests
    for what should be on my next tutorial, etc, just email me (noixtirdoe@aaahawk.com)

    I hope you have learned alot, or if you are already an expert in linux security, I would
    love to read your tuts as well

    9. Bibliography

    a. Bronc Buster's tutorial on linux security. It can be found at:

    b. IPV4 security.

    c. there are probably other places I got information from, just can't remember.


    the attachment is a copy of the tutorial...I put it here cuz the formatting is bad when I posted to AO lol

  2. #2
    Senior Member
    Join Date
    Jul 2002


    Good one. The attached text file has better formatting, though.
    Try using the Courier font next time you post, it will look like the file.

    Always listen to experts. They\'ll tell you what can\'t be done and why. Then go and do it. -- Robert Heinlein
    I\'m basically a very lazy person who likes to get credit for things other people actually do. -- Linus Torvalds

  3. #3
    Junior Member
    Join Date
    Jun 2002
    why not using lyx. what do you think of it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts