|
If you are more interested in how to break in as opposed to defense, you might prefer my page on Linux root console break-ins, how to break in and how to defend against that.
Many of these work on both Linux and OpenBSD. Some are only relevant on Linux. Suggestions here are divided into:
There are no guarantees for what's here. Remember that security and convenience are usually inversely proportional. Good luck...
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME sshd 6502 root 3u IPv4 64002 TCP *:ssh (LISTEN) sshd 6502 root 3u IPv6 64003 TCP *:ssh (LISTEN)
#!/bin/sh # Flush any existing rules and set the default policies iptables -F iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT # Accept anything from myself iptables -A INPUT -s 127.0.0.1/32 --jump ACCEPT # Allow myself to be a non-passive FTP client iptables -A INPUT -p tcp --dport ftp-data --jump ACCEPT # Do not allow a local user to connect to a remote Telnet # server and thus give away login and password information: iptables -A OUTPUT -p tcp --dport telnet --jump REJECT # Accept SSH connections from 128.46.0.0/16 and 44.48.40.12 iptables -A INPUT -s 128.46.0.0/16 -p tcp --dport ssh --jump ACCEPT iptables -A INPUT -s 44.48.40.12/32 -p tcp --dport ssh --jump ACCEPT # Accept HTTP connections from 128.46.144.0/24 iptables -A INPUT -s 128.46.144.0/16 -p tcp --dport http --jump ACCEPT iptables -A INPUT -s 128.46.144.0/16 -p tcp --dport https --jump ACCEPT # If it's not one of the above allowed cases, block connection # attempts to privileged TCP and UDP ports. # # Send the client an ICMP Destination Unreachable (Port Unreachable) # packet to be polite and allow its application to quickly shut # down. iptables -A INPUT -p tcp --dport 1:1023 --jump REJECT iptables -A INPUT -p udp --dport 1:1023 --jump REJECT # If you want to allow this machine to be a client, # uncomment the following command: # iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Otherwise, drop inbound TCP packets with ICMP messages iptables -A INPUT -p tcp --jump REJECT # Report what happened echo 'Firewall rules installed:' iptables -L3 — Experiment with running that script directly and testing.
As above, but change the next-to-last block of code to the following (DROP vs REJECT):
# If it's not one of the above allowed cases, block connection # attempts to privileged TCP and UDP ports. # # Send the client an ICMP Destination Unreachable (Port Unreachable) # packet to be polite and allow its application to quickly shut # down. iptables -A INPUT -p tcp --dport 1:1023 --jump REJECT iptables -A INPUT -p udp --dport 1:1023 --jump REJECT # If it's not one of the above allowed cases, block connection # attempts to privileged TCP and UDP ports. # # Silently drop unwanted packets to waste the attacker's time. iptables -A INPUT -p tcp --dport 1:1023 --jump DROP iptables -A INPUT -p udp --dport 1:1023 --jump DROP
I have more about setting up and using SSH on a dedicated page.
Put the following directives in /etc/ssh/sshd_config to configure the SSH server. Note that many of the SSH defaults are secure, so include the following but comment out any other directives currently used.
|
# Only the more secure SSH2 protocol Protocol 2 X11Forwarding yes Subsystem sftp /usr/libexec/sftp-server |
|
# Only the more secure SSH2 protocol Protocol 2 # Although read "man ssh_config" first... ForwardX11 yes |
Put the following directives in /etc/ssh/sshd_config. Note that many of the SSH defaults are secure, so include the following but comment out any other directives currently used in your SSH daemon configuration:
|
# Only the more secure SSH2 protocol Protocol 2 # List users allowed to connect via SSH # Also see "AllowGroups", "DenyUsers", # and "DenyGroups" in "man sshd_config". AllowUsers joe jane .... # Only the strongest ciphers Ciphers blowfish-cbc,aes256-cbc,aes256-ctr # Only accept authentication via cryptographic # challenge-response (remote client must have # cryptographic keys) PasswordAuthentication no # Do not allow root login -- first login # as ordinary user, then su to root PermitRootLogin no Subsystem sftp /usr/libexec/sftp-server |
|
# Only the more secure SSH2 protocol Protocol 2 |
Add the line "version ..." to the file /etc/named.conf, within the "options{...};" block:
|
other directives appear here... options { other options appear here... version "VERSION NOT PROVIDED"; } ; other directives appear here... |
Otherwise a would-be attacker could figure
out your BIND version with this command:
$ dig @yourserver version.bind chaos txt
With some Linux distributions moving from traditional SVR4 Init to Upstart, this explanation gets complicated. See the dedicated page on how this exploit works and how to prevent it. The very short version is:
On a traditional init based system
(e.g., RHEL/CentOS 5, Mandriva):
Add the following line to the file
/etc/inittab right after the
line referencing /etc/rc.d/rc.sysinit
| ss:S:respawn:/sbin/sulogin |
On an upstart based system
(e.g., RHEL/CentOS 6, Fedora):
Change a line in the file file
/etc/sysconfig/init to read:
| SINGLE=/sbin/sulogin |
On Ubuntu: This has already been done for you!
Reconfigure the BIOS to disable booting from media and set a BIOS password, as discussed on the Linux break-in and defense page.
Consider alarming the system case, as discussed on the Linux break-in and defense page.
Make /tmp a RAM-based filesystem. RAM is much faster than a disk, and any data stored there is truly temporary and is lost at shutdown.
Do the above, but prevent an attacker from
doing many things by making /tmp
less useful to them.
Make the /etc/fstab entry say:
Linux:
none /tmp tmpfs rw,noexec,nosuid,nodev,size=100000000 0 0
OpenBSD:
swap /tmp mfs rw,noexec,nosuid,nodev,-s=128000 0 0
Do all the above, and also use the noexec, nosuid, and nodev options on other partitions as appropriate — maybe something like this:
| /var | nosuid,nodev,noexec |
| /home | nosuid,nodev |
| /usr | nodev |
Best practice for the root account is:
Do the following. Be very careful, this is where you can lock yourself out and only be able to break in with rescue media.
Disallow direct root login on the console
Prevent root network authentication
Prevent unencrypted transmission of the root password
Limit the set of people able to attempt to become root (uneeded on OpenBSD)
At this point you could write the root password on the monitor, and ordinary users still would be unable to become root — not that this is a good idea, but root privileges now require knowledge of a privileged account's password plus knowledge of the root password.
Linux distributions have typically enforced password quality through the pam_cracklib.so PAM module. However, this only provides limited control — the newer pam_passwdqc.so module is much better.
The pam_passwdqc.so module
groups characters into four classes:
Lower-case letters
Upper-case letters
Digits
Everything else
Some things are too obvious to the password
creator and the password guesser, and are
not given any credit:
Starting the password with an upper-case letter
Adding a digit to the end of the password
So, these are all single-character-class
passwords:
dog Dog dog7 Dog7
The module also considers pass phrases (unless
you tell it not to), the following would be
a three-word pass phrase with 11 characters,
using 3 character classes (lower-case,
the upper case B, and the blank spaces):
The Big Dog
Make sure that the file
/etc/pam.d/system-auth contains
the following line:
password required /lib/security/pam_passwdqc.so min=12,10,10,8,6
Users will now be required to make their new
passwords at least this long:
12 characters, if using just one character class
10 characters, if using just two character classes
10 characters, if it is a pass phrase
8 characters, if it uses three character classes
6 characters, if it uses all four character classes
These rules will also apply to root
since you did not loosen up security by
saying the rules only applied to users,
with the added parameter:
enforce=users
See
the pam_passwdqc.so web page
for more details.
No, simply use:
password required /lib/security/pam_passwdqc.so
The defaults are:
No single-character-class passwords allowed
Two-character-class passwords must contain at least 24 characters
Pass phrases must contain at least 12 characters
Three-character-class passwords must contain at least 8 characters
Three-character-class passwords must contain at least 7 characters
You know, if you really want to take
full advantage of the security offered by the
128-bit MD5 cryptographic hash used to
authenticate the login pass phrase, you should
consider the fact that English text contains
about 1.2 bits of entropy per character,
and 128/1.2 = 106.66666:
password required /lib/security/pam_passwdqc.so min=disabled,107,107,100,80
Yeah, good luck convincing anyone that this
is a good idea...
|
|
|
|||||||||
|
|||||||||
|
| © Bob Cromwell Feb 2012. Created with /bin/vi and ImageMagick, hosted on OpenBSD with Apache. Root password available here, privacy policy here. |
