I. Install and Configure OpenSSH
OpenSSH is a replacement for telnet and ftp that eliminates eavesdropping,
connection hijacking, and encrypts all communication between hosts. One of the
most indepensible free security tools in existence.
• Install the OpenSSH and OpenSSL Packages:
openssh-<current-version>.rpm
openssh-server-<current-version>.rpm
openssh-clients-<current-version>.rpm
openssl-<current-version>.rpm
• Generate Public/Private Key Pair:
OpenSSH uses public key cryptography to provide secure authorization.
Generating the public key, which is shared with remote systems, and the private
key which is kept on the local system, is done first to configure OpenSSH.
orion$ ssh-keygen
Generating RSA keys: ...ooooooO....ooooooO
Key generation complete.
Enter file in which to save the key (/home/dave/.ssh/identity):
Created directory '/home/dave/.ssh'.
Enter passphrase (empty for no passphrase): <passphrase>
Enter same passphrase again: <passphrase>
Your identification has been saved in /home/dave/.ssh/identity.
Your public key has been saved in /home/dave/.ssh/identity.pub.
The key fingerprint is:
ac:42:11:c8:0d:b6:7e:b4:06:6a:a3:a7:e8:2c:b0:12 dave@orion
• Copy Public Key to Remote Host:
host2$ mkdir -m 700 ~dave/.ssh
host2$ cp /mnt/floppy/identity.pub ~dave/.ssh/authorized_keys
• Log in to Remote Host:
The SSH client (/usr/bin/ssh) is a drop-in replacement for rlogin and rsh. It
can be used to securely login to a remote host:
orion$ ssh host2
Enter passphrase for RSA key 'dave@orion': <passphrase>
Last login: Sat Aug 15 17:13:01 2000 from orion
No mail.
host2$
• Copy Files to Remote Host:
The OpenSSH package also includes scp, a secure and improved replacement for
rcp. This allows you to securely copy files over a network.
orion$ scp /tmp/file.tar.gz host2:/tmp
Enter passphrase for RSA key 'dave@orion:
file.tar.gz 100% |***************************| 98304 00:00
It is also possible to encapsulate ordinarily insecure protocols such as IMAP and
POP within SSH to prevent transmitting clear text passwords to your mail server.
Additionally, the rsync incremental file transfer utility can use SSH to securely
synchronize two hosts or backup data to a log server securely. SSH can even be
used to securely connect two subnets across the Internet, effectively creating a
virtual private network. Disable remote root logins and emtpy password ability.
II. Apache Security
• Limit Apache to listen only on local interface by configuring
/etc/httpd/conf/httpd.conf to read:
Listen 127.0.0.1:80
• Use the following to disable access to the entire filesystem by default, unless
explicitly permitted. This will disable printing of indexes if no index.html
exists, server-side includes, and following symbolic links. Disabling symlinks
may impact performance for large sites.
<Directory />
Options None
AllowOverride None
Order deny,allow
Deny from all
</Directory>
• Use the following to control access to the server from limited
addresses in /etc/httpd/conf/access.conf to read:
<Directory /home/httpd/html>
# Deny all accesses by default
Order deny,allow
# Allow access to local machine
Allow from 127.0.0.1
# Allow access to entire local network
Allow from 192.168.1.
# Allow access to single remote host
Allow from 192.168.5.3
# Deny from everyone else
Deny from all
</Directory>
• Use the following to require password authentication when attempting to
access a specific directory in /etc/httpd/conf/access.conf:
<Directory /home/httpd/html/protected>
Order Deny,Allow
Deny from All
Allow from 192.168.1.11
AuthName “Private Information”
AuthType Basic
AuthUserFile /etc/httpd/conf/private-users
AuthGroupFile /etc/httpd/conf/private-groups
require group <group-name>
</Directory>
Create the private-groups file using the following format:
group-name: user1 user2 user...
Create password entries for each user in the above list:
# htpasswd -cm /etc/httpd/conf/private-users user1
New password: <password>
Re-type new password: <password>
Adding password for user user1
Be sure to restart apache and test it. This will result in the enabling of double
reverse lookups to verify the identity of the remote host. Remove the -c
option to htpasswd after the first user has been added. Be sure the password
file you create is not located within the DocumentRoot to prevent it from
being downloaded.
III. Configuring TCP Wrappers
Frequently used to monitor and control access to services listed in
/etc/inetd.conf. The in.ftpd service might be wrapped using:
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -L -i -o
Before the in.telnetd daemon is spawned, tcpd first determines if the
source is a permitted host. Connection attempts are sent to syslogd. All
services should be disabled by default in /etc/hosts.deny using the
following:
ALL: ALL
To send an email to the admin and report failed connection attempt:
ALL: ALL: /bin/mail \
-s “%s connection attempt from %c” admin@mydom.com
Enable specific services in /etc/hosts.allow using the service name
followed by the host:
sshd: magneto.mydom.com, juggernaut.mydom.com
in.ftpd: 192.168.1.
Trailing period indicates entire network should be permitted. Use tcpdchk to
verify your access files. A syslog entry will be created for failed attempts.
Access control is performed in the following order:
• Access will be granted when a daemon/client pair matches an entry in
the /etc/hosts.allow file.
• Otherwise, access will be denied when a daemon/client pair matches
an entry in the /etc/hosts.deny file.
• Otherwise, access will be granted.
A non-existing access control file is treated as if it were an empty file. Thus,
access control will be turned off if no access control files are present!
IV. DNS Security
• Zone transfers should only be permitted by master name servers to update the zone
(domain) information in their slave servers. Failure to do so may result in IP numbers and
hostnames being revealed to unauthorized users. Restrict queries to only public domains.
Suitable for name servers with both public and private zones.
// Allow transfer only to our slave name server. Allow queries
// only by hosts in the 192.168.1.0 network.
zone “mydomain.com” {
type master;
file “master/db.mydomain.com”;
allow-transfer { 192.168.1.6; };
allow-query { 192.168.1.0/24; };
};
• Deny and log queries for our version number except from the local host. The ability to
determine the bind version enables an attacker to find the corresponding exploit for that
version.
// Disable the ability to determine the version of BIND running
zone “bind” chaos {
type master;
file “master/bind”;
allow-query { localhost; };
};
The ./master/bind file should then contain:
$TTL 1d
@ CHAOS SOA localhost. root.localhost. (
1 ; serial
3H ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
NS localhost.
• Control which interfaces named listens on. Restricting the interfaces on which named
runs can limit the exposure to only the necessary networks.
listen-on { 192.168.1.1; };
• Use Access Control Lists to classify groups of hosts with differing degrees of trust. The
“internal” ACL label might be used to describe internal hosts that are permitted a greater
degree of access to the information than other hosts might be. Before it can be used it
must be defined:
acl “internal” {
{ 192.168.1.0/24; 192.168.2.11; };
};
It can then be used in “zone” statements or the main “options” statement:
zone “inside.mynet.com” {
type master;
file “master/inside.mynet.com”;
allow-query { “internal”; };
};
• Configure BIND to run as a normal user. Once BIND has been started, it has the ability
to relinquish its privileges, and run as a user with limited abilities instead of root.
# useradd -M -r -d /var/named -s /bin/false named
# groupadd -r named
This account should be used for nothing other than running the name server. Ensure the
zone files are readable by the named user. It is then necessary to modify the default
named init script, typically found in /etc/rc.d/init.d/named on Red Hat or
/etc/init.d/named on Debian:
/usr/sbin/named -u named -g named
It is also possible to run named in a “chroot jail” which helps to restrict the damage that
can be done should named be subverted.
+OpenSSH +DNS Technologies LLC +Apache Software Foundation +Linux +The Linux Foundation +Red Hat +Redhat +Linux Security Group
No comments:
Post a Comment