Securing Your Unix Operating System

July 17, 2015 | Views: 4216

Begin Learning Cyber Security for FREE Now!

FREE REGISTRATIONAlready a Member Login Here

Hi Team,

I’m sharing my knowledge about UNIX OS.  Some important settings could protect your system. It’s also important to know your OS system well, including its security file settings.

 

Depending on your networking settings, you may be more open to attacks or vulnerabilities, such as:

  1. ICMP redirects
  2. Source-routed IP packets
  3. Smurf attacks and 
  4. SYN floods

 

1. ICMP redirects modify the kernel’s network routing table. Attackers can use ICMP redirect to direct information to routers that doesn’t exit, resulting in a denial-of-service attack.  They can also use ICMP redirects to launch man-in-middle attacks by directing information to themselves.

To disable the sending of ICMP redirects, set the send_redirects entry in the /etc/sysctl.conf file to ‘0’. And, to disable the receipt of ICMP redirects, set the accept_redirects entry in /etc/sysctl.conf‘ file to ‘0’.

 

2. When using source routing with an IP packet, you can specify the exact routers that the packet travels through on the way to its destination. An attacker can use the source routing option to bypass firewall and other networking security components.

To disable the receipt of IP packets with source routing, set the ‘accept_source_route’ entry in the ‘/etc/sysctl.conf file to 0.

 

3. Smurf attacks occur when your system is flooded with ICMP echo requests or Pings. If you disallow pings, your systems can’t be used for Smurf attacks. Yet, this may cause problems if you have legitimate reasons to use pings.

 

4. SYN floods occur when an attacker sends TCP SYN packets to indicate the start of a connection, but doesn’t complete the three way handshake to complete these connections. When the number of pending TCP connections exceeds the maximum that e kernel allows, the system is “flooded”

To mitigate SYN floods, set tcp_max_syn_backlog parameter of /etc/sysctl.conf’ file to a high number, such as 2048.

 

Kernel Configuration:

Depending on the kind of UNIX system you have, it may be possible to perform the following actions on network kernel configuration:

  1. Improving the randomization of TCP sequence numbers
  2. Reducing the timeout period for half open TCP connections
  3. Reducing the length of time the ARP cache keeps information
  4. Disabling certain ICMP message types that cause vulnerabilities

1.  Every newly created connection generates a random TCP sequence number. The less complex the randomization algorithm, the more vulnerable your system is to IP spoofing and other attacks.

2.  SYN flooding occurs when pending TCP connection occupy more space than your kernel can handle. One way of reducing the space that pending connections occupy is to reduce the time out period, after which your system discards connections that are half open.

The default on most UNIX systems is 3. Reducing this number to 1, reduces the risk of SYN floods without compromising your system. All UNIX systems support this functionality.

3.  ARP caches contained within UNIX system is needed to map IP address to Ethernet addresses. This information should only be made available for the minimum time of possible, because attacker can maliciously alter it to reroute traffic. This could result in a denial of services or man in middle attack.

 

Buffer Overflow:

A buffer overflow is the most common and serious threat UNIX OS.

Buffer overflows are the result of running executable code in unprotected memory, so you should safeguard the memory as best you can.

In certain OS’s, you can enforce stack protection. With stack protection, you can modify your kernel to ensure that code only executes from areas of memory that you have cordoned off and locked.

To enable stack protection in Solaris, you set noexec_user_stack parameter to ‘1’ and the no_exec_user_stack_log parameter to ‘1’.

 

Boot Process:

Attackers can break into UNIX systems by manipulating the boot process. Therefore, it’s important to restrict the number of people with shutdown rights.  Unfortunately, the default setting for some UNIX and LINUX systems allow nonroot users to shut down the entire system.

You can prevent users from shutting down the system from the login screen by changing appropriate files for your UNIX system.

ex: to disable the Shutdown button on GNOME login screen, you need to set ‘SystemMenu=False’ in the gdm.conf’ file.

And, to disable the shutdown button on the KDE login screen, you need to set ‘AllowShutdown=None’ in ‘kdmrc file’.

 

More on Kernels:

The kernel acts as an interface between the hardware and software on a system. Modifying kernel parameters allows you to determine how your system performs and how it’s secured against attacks.

Red Hat’s ‘/etc/security/limits.conf’ file allows you to limit the degree to which users can consume system resources.

And, its etc/sysctl.conf file allows you to tweak kernel settings to protect a system against attack.

 

Crons:

The cron daemon perform UNIX scheduling. Each user has a crontab file specifying what jobs are scheduled to run when.  The crontab and at command enable users to schedule jobs.  The ‘/etc/crontab.allow’ and ‘/etc/at.allow’ files state which users have permission to issue the crontab and at commands.

Users’ crontab files in Red Hat Linux are stored in ‘/var/spool/cron’.

For Solaris and HP-UX, they are kept in ‘var/spool/cron/crontabs’.

For BSD, they’re kept in ‘/var/cron/tabs’.

Proper management of cron scheduling involves:

1.  Logging cron jobs: To know what’s happening on your system, you need to audit scheduled jobs.

Red Hat cron daemon automatically sends a message to the syslog whenever a cron job executes. It’s /etc/syslog/conf file defaults to save these messages in the /var/cron/log files.

2.  Determining administrative access for the crontaband at commands

3.  Ensuring that the user who schedules jobs that run from cron owns the files used by those jobs.

 

A Final Note:

The passwords in most UNIX systems are encrypted and stored in the shadow file in /etc’ directory. This file can be read only by the superuser.

In FreeBSD systems, the encrypted passwords of users are stored in the ‘/etc/master.passwd’ file.

 

Thanks for your time,

Ragini

Share with Friends
FacebookTwitterLinkedInEmail
Use Cybytes and
Tip the Author!
Join
Share with Friends
FacebookTwitterLinkedInEmail
Ready to share your knowledge and expertise?
10 Comments
  1. Excellent & effective!

  2. Nice article, thanks for sharing

  3. thanx for the post 🙂 nice info 🙂

  4. i was wondering isnt this loose source routing an icmp redirect an old attack?
    and to be performed doesnt the rfc require we be on the same network?

    if so this makes sense if i can trick a network router on the same segment i have managed to abuse i could redirect a routers traffic to a differnet route and perform various attacks against it

Page 2 of 2«12
Comment on This

You must be logged in to post a comment.

Our Revolution

We believe Cyber Security training should be free, for everyone, FOREVER. Everyone, everywhere, deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is a free community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

Support Cybrary

Donate Here to Get This Month's Donor Badge

 

We recommend always using caution when following any link

Are you sure you want to continue?

Continue
Cancel