Tag: secure

By Gabriel Py Ng

Test Logical security of Unix servers.

unix securityThis area covers the technical security assessment of Unix, Linux servers (commands are similar but some are different. Please check with the respective man pages).

Stage 1 scan using Nessus and check for vulnerabilities and Nmap for ports. Highlight the ports and refer to IANA for details. Print report.

Scan using Nessus (ensure latest updates are done).

Stage 2 more etc/passwd and /etc/shadow > to password.txt and shadow.txt in home directory. Check the security of these files, check IDs and /etc/group.

1. This is like the basic security measure that any server MUST take. i.e. IDs and Groups.

2. What to check. More /etc/passwd and /etc/shadow.

3. Look out for normal IDs – are all these active and belongs to users that have resigned ?

4. Lookout for system IDs – active, are they required – they may be powerful

5. Test ID, Developer IDs, Root equivalent IDs – active ? Why ?

6. Intruders often use finger or ruser to discover account names and then try simple passwords. Please let your users know that complex passwords are a must. Simple passwords just make the hacker’s job easier.

7. If intruders can get a password file, they usually move or copy it to another machine and run password guessing programs on it. These programs involve large dictionary searches and run quickly even on slow machines. Most systems that do not put any controls on the types of passwords used probably have at least one password that can be easily guessed.

8. It is a good practice to change all your passwords. For extremely critical servers, passwords should be change everytime root equivalent, developer IDs are used. If this is not practical, perhaps 3 months or 6 months interval.

9. Intruders exploit system default passwords that have not been changed since installation,including accounts with vendor-supplied default passwords. Be sure to change all default passwords when the software is installed. There are software upgrades that can change account passwords to a new default at the background. Review and change passwords after updates are done.

More /etc/passwd > /home/Gabriel/password.csv

More /etc/shadow > /home/Gabriel/shadow.csv

Stage 3 Check world writable files and directories. This is also a must. Imagine your most critical business files are accessible to everybody. Find them and take the necessary steps to control their rights.

find / -type f -perm -22 -exec ls -l > /home/Gabriel/worldfiles.csv ;

find / -type d -perm -22 -exec ls -l > /home/Gabriel/worlddirectory.csv ;

Stage 4 Search for SUID and GUID files

* SUID and GUID can allow normal users to become root equivalent when these programs are owned by Root.

* To mitigate this risk, it will be prudent that these files are not world readable as power users may find ways to run these programs. Or remove them if not necessary

* SUID and GUID are normally found in /bin, /etc, /usr/bin, /usr/ucb, /usr/etc, pay attention if they are found in other directories.

* Look for SUID files (especially SUID root files) everywhere on your system. Intruders often leave SUID copies of /bin/sh around to allow them root access at a later time. The UNIX find program can be used to search for setuid files.

Find / -user root -perm -4000 -exec ls -l > /home/Gabriel_ng/rootsuid.csv ;

Find SUID and GUID on root directory.

Find / -xdev -perm -004000 -exec ls-l {} > /home/Gabriel_ng/suid.csv ;

Find / -xdev -perm -002000 -exec ls-l {} > /home/Gabriel_ng/guid.csv ;

Stage 5 Check for network files – /etc/hosts.equiv, .rhosts, /etc/hosts.allow, hosts.deny

* Important factor in network security is controlling network access. The /etc/hosts.equiv, .rhosts and /etc/passwd control whether access is given to rlogin, rcp, and rsh. The /etc/hosts.equiv contain a list of hosts that can be trusted or considered equivalent to that machine. Some systems uses /etc/hosts.allow and /etc/hosts.deny rather than a single /etc/hosts.equiv. The .rhosts files holds a list of hosts that are permitted access to a specific user.

* Because .rhosts files allow access to the system without using a password it is recommended that users do not create them in their home directories.

Check for /etc/hosts.equiv, .rhosts , /etc/hosts.deny and /etc/hosts.allow

Find /home -name .rhosts -print

Stage 6 Check system monitoring – logs.

Check /etc/sudoers – ability for users to run commands as “root” with sudoers.

More /etc/sudoers > /home/Gabriel/sudoers.csv

Other includes /var/adm/acct, /var/adm/wtmp, var/adm/btmp, var/adm/syslog/syslog.log

Check /var/adm/sulog

1. SU 10/19 14:15 + tty q3 root-test1 – list the date and time, + indicate successful and – failure. If there is repeat failure could be indication that someone is trying to break in using su.

Stage 7 By piping all files in csv or text files, it will be easier to analyze the details and work with the relevant parties to tighten the security.

Gabriel Ng is the author of [http://www.comsectutorial.com] This site is setup to provide information, recommendation on hacking prevention, controls to minimise security threats from viruses, trojans, spywares, hacking based real life experience while conducting security assessment and penetration tests. This video touches a bit on unix security.

[http://www.comsectutorial.com/server-vulnerabilities.html] Enjoy!

Tags: , , , , , , , , , , , ,

Six Steps to a More Secure Linux Server
By Christopher Pace

I’ve worked as a remote Linux System Administrator for quite a while, and one thing that I’ve noticed is that many “administrators” out there don’t know how to configure or secure a server properly. This article is a quick reference on some of the more important (and easy) security or configuration tweaks that any administrator should do for their server. These six steps can dramatically increase the security and stability of any Linux server. The best part about these tips, is that they are all quick and easy to do as well, with each step taking less than 15 minutes!

1.) Security Updates Not Installed
Nearly every server that I work on is not running the latest (and most secure) software. Yes, Linux is a great Operating System- but all software has security problems. Enabling the installation of automatic updates via a cron script or similar is the easiest and most foolproof way to ensure that your server isn’t compromised. There really isn’t any excuse not to install the latest security updates- older packages are saved in the package archives in case there is a stability or compatibility issue, and the updated packages are logged as they are updated.

180px-KN-Servers22.) Disable root login via SSH, and password authentication
Admittedly, I’ve been guilty of this myself sometimes. Let’s face it, everyone likes being able to quickly and easily log into their servers, and change settings. However, if you’re using password authentication, what’s to keep someone else from logging into your server? In addition, you should not use password authentication on your Linux server, to prevent others from logging into your Linux server. Instead, enable RSA signed authorization keys. This is more secure, since an attacker will not be able to guess or brute force a login session with your server.

3.) Disable or filter extra services
This is the second biggest issue that I see working with new client’s servers. Often, the system administrator who setup their Linux server did not perform a necessary final step- filter incoming connections that aren’t necessary. I’ve seen everything from the daytime service running, to MySQL listening for connections on a remote IP. If a Linux administrator is not familiar with iptables, there are several tutorials out there that will show someone how to create even a basic firewall ruleset. In addition, disabling unnecessary services is a basic step in server optimization as well- why run extra services that tie up resources if they aren’t needed?

4.) Test accounts or guest accounts still active
Another glaring security issue (and an often exploited one) is that a client will still have test user accounts running (often with extremely easy passwords, such as test) once a software solution is deployed to a production server. I don’t need to go into the security ramifications with this one- make sure that you get rid of those guest or test accounts!

5.) Advertising banners left on
We all love advertising, don’t we? However, advertising to the world that the version of Apache or Sendmail that you run on your Linux server is 3 years old is not the type of attention that you want. Simply disabling the server banners will help hide your server from the basic script-dependent attackers. Besides, why help the bad guys determine what software your server is running?

6.) PHP errors or application errors
334px-Tux.svgI’m pretty confident that we have all seen an error or two displayed on a website. Some errors that are displayed are not a security issue at all, for instance Javascript errors. However, some errors are security issues (PHP is particularly bad with this), because they disclose sensitive information. The easiest way around this is to disable displaying errors in PHP (or your web applications). Otherwise, an attacker may be given information about your website’s database details, or file locations.

These issues are the top 6 security issues that I see on a daily basis in my work. You can all check your server or servers for these quick issues (these tips take almost no time at all), and dramatically increase the security of your server. However, if you have any problems implementing these security steps, please feel free to contact me.

Christopher J. Pace is a freelance Linux consultant who has worked with Linux since 2001. He provides remote Linux consulting services for Linux servers.

Tags: , , , , ,
Back to top