Results 1 to 5 of 5

Thread: Hardening Redhat..some tips

  1. #1
    Junior Member
    Join Date
    Mar 2002
    Posts
    23

    Hardening Redhat..some tips

    Found this in my notes,(not sure of the original source), but I thought I'd share for those who are working with Linux/Redhat. Concepts should apply for pretty much all versions.

    -Aryoche.


    Make your Linux System less vulnerable

    Here are some guidelines to make linux more stable against hacker attacks.

    Stopping services

    Despite choosing minimal software during installation. Many services will have to be manually disabled with chkconfig

    Active services can be examined with:

    $ chkconfig --list

    For firewall and DMZ systems you may switch off basically everything, except SSH

    $ chkconfig httpd off
    $ chkconfig apmd off
    $ chkconfig atd off
    $ chkconfig xfs off
    $ chkconfig pcmcia off
    $ chkconfig lpd off
    $ chkconfig nfs off
    $ chkconfig gpm off
    $ chkconfig linuxconf off
    $ chkconfig identd off
    $ chkconfig portmap off
    $ chkconfig rhnsdoff
    $ chkconfig sendmail off
    $ chkconfig xinetd off

    The list of open tcp/udp ports is now VERY small (in fact only SSH is listening):

    # netstat -a

    Active Internet connections (servers and established)
    Proto Recv-Q Send-Q Local Address Foreign Address State
    tcp 0 0 *:ssh *:* LISTEN
    raw 0 0 *:icmp *:* 7
    raw 0 0 *:tcp *:* 7

    Configuration notes

    The "init level" should be set to 3 (command line login), rather than 5 (graphical login). If a GUI is needed, it can always be started manually with startx.

    To login via the 'serial port A' on x86 Hardware, which is useful for troubleshooting, installations and getting to know the command line. Add the following to /etc/inittab.
    con:23:respawn:/sbin/getty ttyS0 VC

    To allow root to login via this serial port, add ttyS0 to /etc/securetty

    echo "ttyS0" >> /etc/securetty

    Environment

    Environment such as /.cshrc /.profile /.bashrc /etc/profile /etc/bashrc: set aliases, variables (such as VISUAL, EDITOR and PATH don't include ".") for your favourite shell. Set umask to 077, or 027.
    Disk mounting

    To reduce the risk of trojan horses and unauthorised modifications, in
    /etc/vfstab, mount /var and other data disks with "nosuid".

    Configure /etc/hosts with a list of critical machines
    (which you don't want resolved via DNS).

    DNS client (avoid if not needed): add domain name & DNS servers to /etc/resolv.conf. Add a DNS entry for "hosts" in /etc/nsswitch.conf (and remove nis and nisplus entries).
    Keyboard security

    If your hosts are in secured rooms, it might be desirable to disable certain key functions such as the following. To disable hotkey interactive startup, set PROMPT=no in /etc/sysconfig/init.
    On x86: To allow ctrl-alt-delete to shutdown the system, an entry in /etc/inittab like the following is used:
    # Trap CTRL-ALT-DELETE
    ca::ctrlaltdel:/sbin/shutdown -t3 -r now

    Comment it out and reboot or "killall -HUP init" to activate the change.

    Use default routes: add the IP address of the router to /etc/sysconfig/network.

    In /etc/inetd.conf, all services should be disabled: reopen very specific services only if absolutely needed, and adapt /etc/hosts.allow and /etc/hosts.deny.

    If a sensitive host is to be administered by several people, consider
    using a tool such as sudo.
    User Access

    If user accounts will be allowed on the system, consider restricting access to:
    cron: via /etc/cron.allow and cron.deny
    at: via /etc/al.allow and at.deny
    ftp: Disallowed users are listed in /etc/ftpusers
    SSH: See /etc/ssh/sshd_config (look for AllowUsers DenyUsers entries) and /etc/hosta.allow
    General inetd services: /etc/hosts.allow and hosts.deny
    File system groups: /etc/groups and use file and directly permissions accordingly.
    Setup Syslog

    Setup a syslog server to receive messages from all clients.
    So, to configure syslog to send all messages to the syslog server,
    and keep a local copy too:
    1. Add an entry to /etc/hosts for the "loghost"

    192.168.136.3 loghost loghost.akadia.ch

    2. Add the follwoing as the first line of /etc/syslog.conf
    (important: the two fields are separated by a TAB):

    *.* @loghost

    3. Restart syslog: either reboot, or kill -1 SYSLOG_PID

    Filesystems, directories and files

    Mount filesystems (in /etc/fstab) not containing systems programs nosuid, such as /var.

    What SUID files are on the system? The find command can be used to list all
    SUID or SGID files:
    find / -perm -u+s -type f -ls
    find / -perm -g+s -type f -ls

    Why both touching them? Because they are often a source of weaknesses, and if problems are found in the future, we won't be exposed and we won't have to rush and install patches.

    rlogin/rsh/rcp are not needed, since we use SSH. Lets restrict access
    to root & remove SUID
    chmod 700 /usr/bin/rcp /usr/bin/rlogin /usr/bin/rsh

    We only allow root to use cron, at and bring network interfaces up or down:
    chmod 700 /usr/bin/crontab /usr/bin/at /usr/sbin/usernetctl

    Users don't need to be able to mount any devices (non-root users can't
    use floppies of CDs after this):
    chmod ug-s /bin/umount /bin/mount

    On sensitive systems, only root needs access to account management
    and network debugging
    chmod ug-s /usr/bin/chage /usr/bin/gpasswd
    chmod ug-s /usr/bin/chsh /usr/bin/chfn
    chmod ug-s /usr/sbin/traceroute /bin/ping

    If no SUID perl scripts are needed, we can remove the SUID bit from perl itself:
    chmod ug-s /usr/bin/suidperl /usr/bin/sperl*

    Login banners

    Delete any indications of the system version from /etc/issue and put in a warning about unauthorised use of the system.
    mv /etc/issue /etc/issue.orig

    The other warning banner /etc/motd is emty on RH7, but the same applies.
    Integrity checking

    Tripwire
    There are both free and commercial versions. Red Hat x86 is the only Linux for which the Commercial version is officially available (and included for free in RH7). The free version can be tricky to get working correctly and has a few bugs. Source code is provided. The commercial version is a bit pricey (for non Linux users), reports are too verbose (you may need filter scripts), more configuration examples should be provided. It is more stable than the free version, also runs on UNIX and NT and offers enhanced security by cryptographic signing of policy and configuration files. Support (even when paid for) is not great.

    PGP
    Can also be used, by signing files to be protected (creating lots of signature files), then writing a script to check the validity of signatures. This will not catch permission, link, inode or modify date changes though.

    MD5 signatures could also be used in a similar way, but the list of MD5 signatures should not be stored on the system being monitored, unless it is PGP signed or encrypted.

    Automatically rotating your Log Files

    Uncontrolled growing of log files may fill up important filesystems like /var. One, not documented features under Linux is logrotate, which belongs to the standard RedHat Linux distribution.

    Logrotate is designed to ease administration of systems that generate large numbers of log files. It allows automatic rotation, compression, removal, and mailing of log files. Each log file may be handled daily, weekly, monthly, or when it grows too large. Normally, logrotate is run as a daily cron job. It will not modify a log multiple times in one day unless the criterium for that log is based on the log’s size and logrotate is being run multiple times each day, or unless the -f or -force option is used.

    Any number of config files may be given on the command line. Later config files may override the options given in earlier files, so the order in which the logrotate config files are listed in is important. Normally, a single config file which includes any other config files which are needed should be used.

    Configuration File

    The configuration file for logrotate can be found in /etc/logrotate.conf

    # rotate log files daily
    daily

    # keep 1 day of backlogs
    rotate 1

    # send errors to
    errors martin.zahn@akadia.com

    # create new (empty) log files after rotating old ones
    create

    # uncomment this if you want your log files compressed
    compress

    # RPM packages drop log rotation information into this directory
    include /etc/logrotate.d

    # no packages own lastlog or wtmp -- we'll rotate them here
    /var/log/wtmp {
    monthly
    create 0664 root utmp
    rotate 1
    }

    Included Files from /etc/logrotate.d (e.g. apache)

    /var/log/httpd/akadia.log {
    missingok
    postrotate
    /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null`
    2> /dev/null || true
    endscript
    }

    /var/log/httpd/error.log {
    missingok
    postrotate
    /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null`
    2> /dev/null || true
    endscript
    }

    For more information type the following commands:

    # man logrotate
    # man logrotate | col -b > logrotate.txt
    # man -t logrotate > logrotate.ps

  2. #2
    Good post and just what I was looking for after a fresh install of RH 7.1...After setting up the basic firewall I was at a loss on how to "secure up."

    On a side note.....whilst trying to launch IRC as root it gave me the following warning-

    "Running IRC as root is stupid."


    LOL.......A not to subtle hint!

  3. #3
    Senior Member Ouroboros's Avatar
    Join Date
    Nov 2001
    Location
    Superior, WI USA
    Posts
    636
    SourceForge anyone?... http://www.linux-sec.net/Harden/server.gwif.html ...
    RedHat is nice this way...

    Ouroboros
    "entia non sunt multiplicanda praeter necessitatem"

    "entities should not be multiplied beyond necessity."

    -Occam's Razor


  4. #4
    Is redhat better than mandrake. I have been experiencing many problems with mandrake. Like shutdown errors and software (especially apache) not installing/working right.

  5. #5
    Junior Member
    Join Date
    Mar 2002
    Posts
    3
    As far as hardening is concerned check out
    http://www.bastille-linux.org/ I have not used this tool but it has
    gotten good reviews in the press as a tool to harden rh and mandrake.

    As far as mandrake vs. rh -- I have used RH for quite a while and it has its quirks too, (strange lock ups)
    but most problems are **usually** config problems.
    If it was easy...everyone would do 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
  •