The document discusses various methods for hardening Linux security, including securing physical and remote access, addressing top vulnerabilities like weak passwords and open ports, implementing security policies, setting BIOS passwords, password protecting GRUB, choosing strong passwords, securing the root account, disabling console programs, using TCP wrappers, protecting against SYN floods, configuring SSH securely, hardening sysctl.conf settings, leveraging open source tools like Mod_Dosevasive, Fail2ban, Shorewall, and implementing security at the policy level with Shorewall.

1. Linux Hardening

2. Roadmap
Securing from physical access.
Securing from remote access
Power of open-source
???????????????

3. Top Vulnerabilities
 Default installations of operating system
and applications
 Accounts with no password or weak
password
 Non-existent or incomplete backup
 A large number of open ports
 Not filtering packets for correct incoming
and outgoing addresses
 Non-existent or incomplete logging
 Vulnerable CGI programs

4. Security as a Policy
It is important to point out that you cannot implement security if you
have not decided what needs to be protected, and from whom.
 How do you classify confidential or sensitive information?
Does the system contain confidential or sensitive information?
 Exactly whom do you want to guard against?
Do remote users really need access to your system?
Do passwords or encryption provide enough protection?
 Do you need access to the Internet?
How much access do you want to allow to your system from the
Internet?
 What action will you take if you discover a breach in your
security?

5. BIOS
 It is recommended that you set a Boot password to
disallow booting from disk drives , mass storages
and set passwords on BIOS features.
 This will block undesired people from trying to boot
your Linux system with a special boot disk and will
protect you from people trying to
change BIOS feature like allowing boot from usb
drive or booting the server without prompt password.

6. Password Protecting GRUB
 To do this, first choose a strong password, open a
shell, log in as root, and then type the following
command:
/sbin/grub-md5-crypt
After the password is generated copy the text and add it
to following file.
/boot/grub/grub.conf
Add an entry in the file
“password --md5 <password-hash>”

7. Choose a right Password
 Also, a password checking mechanism should be present to reject
a weak password when first choosing a password or changing an
old one
 Edit the login.defs file vi /etc/login.defs and change the line that
read:
” PASS_MIN_LEN 5 >>>>> PASS_MIN_LEN 8”
 The login.defs is the configuration file for the login program. You
should review or make changes to this file for your particular
system. This is where you set other security policy settings like
password expiration defaults or minimum acceptable password
length.

8. The root account
 The root account is the most privileged account on a Unix
system
 For security reasons, never log in on your server
as root unless it is absolutely an instance that necessitates
root access
“TMOUT=7200”
The value we enter for the variable TMOUT= is in second and
represent 2 hours (60 * 60 = 3600 * 2 = 7200 seconds). It is
important to note that if you decide to put the above line in
your /etc/profile file, then the automatic logout after two hours
of inactivity will apply for all users on the system
 Edit the file :
“/etc/profile”

9. Disable console program
access
“/etc/security/console.apps”

10. TCP_WRAPPERS
 By default Red Hat Linux allows all service
requests. Using TCP_WRAPPERS makes
securing your servers against outside intrusion is
a lot simpler and painless then you would expect
 TCP_WRAPPERS is controlled from two files
and the search stops at the first match.
“/etc/hosts.allow”
“/etc/hosts.deny”

11. SYN denial of service
attacks
 SYN cookie is a technique used to resist SYN flood attacks
and we call it as SynAttackProtect.
 In order to initiate a TCP connection, the client sends a TCP
SYN packet to the server. In response, the server sends a
TCP SYN+ACK packet back to the client
“echo 1 > /proc/sys/net/ipv4/tcp_syncookie”
/etc/rc.d/rc.local – not have to type it again the next time you
reboot your system.
Add
/etc/sysctl.conf
# Enable TCP SYN Cookie Protection

12. SYN flood attack

13. SSH

14. Default Config Files and SSH Port
/etc/ssh/sshd_config - OpenSSH server configuration file.
/etc/ssh/ssh_config - OpenSSH client configuration file.
~/.ssh/ - Users ssh configuration directory.
~/.ssh/authorized_keys - Lists the public keys (RSA or DSA) that
can be used to log into the user’s account
/etc/nologin - If this file exists, sshd refuses to let anyone except
root log in.
/etc/hosts.allow and /etc/hosts.deny : Access controls lists that
should be enforced by tcp-wrappers are defined here.

15. Only Use SSH Protocol 2
SSH protocol version 1 (SSH-1) has man-in-the-
middle attacks problems and security vulnerabilities.
Limit Users' SSH Access
 Only allow <user1> and <user2> user to use the system via SSH,
add the following to sshd_config:
“PermitRootLogin no ”
” AllowUsers <user1>”
 Alternatively, you can allow all users to login via SSH but deny
only a few users, with the following line:
“DenyUsers <user2>”

16. Change SSH Port and Limit IP Binding
 By default SSH listen to all available interfaces and IP address on the
system. Limit ssh port binding and change ssh port (by default brute
forcing scripts only try to connects to port # 22). To bind to
192.168.1.5 and 202.54.1.5 IPs and to port 300, add or correct the
following line:
Port 300
ListenAddress 192.168.1.5
ListenAddress 202.54.1.5
 Disable Empty Passwords
 You need to explicitly disallow remote login from accounts
with empty passwords, update sshd_config with the following
line:
“PermitEmptyPasswords no”

17. sysctl.conf

18. sysctl is an interface that allows you to make changes to a
running Linux kernel. With /etc/sysctl.conf you can
configure various Linux networking and system settings
such as:
 Limit network-transmitted configuration for IPv4
 Limit network-transmitted configuration for IPv6
 Turn on execshield protection
 Prevent against the common 'syn flood attack‘
 Turn on source IP address verification
 Prevents a cracker from using a spoofing attack against
the IP address of the server.
 Logs several types of suspicious packets, such as
spoofed packets, source-routed packets, and redirects.

19.  # Avoid a smurf attack
net.ipv4.icmp_echo_ignore_broadcasts = 1
 # Turn on protection for bad icmp error messages
net.ipv4.icmp_ignore_bogus_error_responses = 1
 # Turn on syncookies for SYN flood attack protection
net.ipv4.tcp_syncookies = 1
 # Turn on and log spoofed, source routed, and redirect
packets
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
 # No source routed packets here
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

20.  # Turn on execshild
kernel.exec-shield = 1
kernel.randomize_va_space = 1
 # Tune IPv6
net.ipv6.conf.default.router_solicitations = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.dad_transmits = 0
net.ipv6.conf.default.max_addresses = 1

21. Power of Open source
Mod_Dosevasive in Apache
Fail2ban
Shorewall
 Observium

22. Mod_Dosevasive in Apache
 Mod_Dosevasive is an evasive maneuvers module for
Apache whose purpose is to react to HTTP DoS and/or
Brute Force attacks.
 An additional capability of the module is that it is also
able to execute system commands when DoS attacks are
identified. This provides an interface to send attacking
IP addresses to other security applications such as local
host-based firewalls to block the offending IP address.
 Mod_Dosevasive performs well in both single-server
attacks, as well as distributed attacks; however, as with
any DoS attack, the real concern is network bandwidth
and processor/ RAM usage.

23. The IP address of the client is checked in the temporary blacklist of the hash
table. If the IP address is listed, then the client is denied access with a 403
Forbidden.
LoadModule dosevasive20_module
modules/mod_dosevasive20.so
-------------------------------------------------------
| IfModule mod_dosevasive20.c |
| DOSHashTableSize 3097 |
| DOSPageCount 2 |
| DOSSiteCount 50 |
| DOSPageInterval 1 |
| DOSSiteInterval 1 |
| DOSBlockingPeriod 10 |
| -/IfModule |
------------------------------------------------------------------------

24. fail2ban
 Fail2ban scans log files (e.g. /var/log/apache/error_log) and
bans IPs that show the malicious signs -- too many password
failures, seeking for exploits, etc.
 Generally Fail2Ban is then used to update firewall rules to reject
the IP addresses for a specified amount of time, although any
arbitrary other action (e.g. sending an email) could also be
configured. Out of the box Fail2Ban comes with filters for
various services (apache, courier, ssh, etc).
 Fail2Ban is able to reduce the rate of incorrect authentications
attempts however it cannot eliminate the risk that weak
authentication presents.

25. bantime = 3600
ignoreip = 127.0.0.1/8
maxretry = 3
# A host is banned if it has generated "maxretry" during the
last "findtime"
findtime = 600 # seconds
[ssh-iptables]
enabled = true
Filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=root,
sender=fail2ban@example.com, sendername="Fail2Ban"]
logpath = /var/log/secure
maxretry = 5

26. Shorewall
 Shorewall (more appropriately the Shoreline Firewall)
is an open source firewall tool for Linux that builds
upon the Netfilter(iptables/ipchains) system built into
the Linux kernel, making it easier to manage more
complex configuration schemes by providing a higher
level of abstraction for describing rules using text
files.stromwall

27. Shorewall uses the concept of zones. You need to
define the network using a set of zones as follows
for the two network-interface configuration
#NAME DESCRIPTION
fw The firewall itself
wan The Internet
lan Your Local Network

28.  routefilter - Turn on kernel route filtering for this interface i.e.
turn on anti-spoofing measurements.
 blacklist - Check packets arriving on this interface against the
/etc/shorewall/blacklist file. The blacklist file is used to perform
static blacklisting. You can blacklist by source address (IP or
MAC), or by application.
 tcpflags - Packets arriving on this interface are checked for certain
illegal combinations of TCP flags such as x mas or null or invalid
packets. Packets found to have such a combination of flags are
dropped (see the settings of TCP_FLAGS_DISPOSITION option
in shorewall.conf) after having been logged in /var/log/messages
file (see the setting ofTCP_FLAGS_LOG_LEVEL in
shorewall.conf).
 logmartians - Turn on kernel martian logging (logging of packets
with impossible source addresses). It is strongly suggested that if
you set routefilter on an interface that you also set logmartians.
 nosmurfs - Filter packets for smurfs (packets with a broadcast
address as the source) i.e. turn on anti-smurf protection.

29. “etc/shorewall/policy”
 You express your default policy for connections from one zone
to another zone in the/etc/shorewall/policy. file. The basic
choices for policy are:
ACCEPT - Accept the connection.
DROP - Ignore the connection request.
REJECT - Return an appropriate error to the
connection request.
 Connection request logging may be specified as part of a policy
and it is conventional (and highly recommended) to log DROP
and REJECT policies.

31. Thank You
A secure Linux server depends on how the administrator configures it to be.