buchner.johannes writes:

“I was fed up with the general consensus that Linux is oh-so-secure and has no malware. After a week of work, I finished a package of malware for Unix/Linux. Its whole purpose is to help white-hat hackers point out that a Linux system can be turned into a botnet client by simply downloading BOINC and attaching it to a user account to help scientific projects. The malware does not exploit any security holes, only loose security configurations and mindless execution of unverified downloads. I tested it to be injected by a PHP script (even circumventing safe mode), so that the Web server runs it; I even got a proxy server that injects it into shell scripts and makefiles in tarballs on the fly, and adds onto Windows executables for execution in Wine. If executed by the user, the malware can persist itself in cron, bashrc and other files. The aim of the exercise was to provide a payload so security people can ‘pwn’ systems to show security holes, without doing harm (such as deleting files or disrupting normal operation). But now I am unsure of whether it is ethically OK to release this toolkit, which, by ripping out the BOINC payload and putting in something really evil, could be turned into proper Linux malware. On the one hand, the way it persists itself in autostart is really nasty, and that is not really a security hole that can be fixed. On the other hand, such a script can be written by anyone else too, and it would be useful to show people why you need SELinux on a server, and why verifying the source of downloads (checksums through trusted channels) is necessary. Technically, it is a nice piece, but should I release it? I don’t want to turn the Linux desktop into Windows, hence I’m slightly leaning towards not releasing it. What does your ethics say about releasing such grayware?”

This is a great thing for the community at large to see that Linux can be exploited with malware just like it’s rival operating systems.  However, I share the same concerns the developer does.  This indeed could result in a black-hat user injecting something malicious into the code and actually turning the example into real evil malware. I’m on the fence though, maybe this is what Linux users need to prove that we aren’t like typical Windows users who click any random link and download any random software from any random untrusted third-party site.  A user who goes by the name of silentcoder wrote: “Linux users (hardly ever) download and install software from the internet. We download and install packages from repositories. The average user simply cannot tell the difference between a useful piece of freeware and a bugridden-malware-spreading piece of add-ware.”

Paranoia aside, this definitely proves that Linux is just as susceptible to malware and viruses as any other operating system.  But, as I’ve always said, viruses and malware are usually a result of user error, no matter the operating system.

What do you all think, should this type of code be released as proof of concept even if it’s risking malicious manipulation?  Should we all just start using SELinux and be done with it?

Bookmark This Page:

Hide Sites

Here are a few:

1. Set up regular updates for your particular Linux distribution
2. Lock your system when you step away from it. To lock the Gnome graphical desktop, run the following command, part of the “gnome-screensaver” package:gnome-screensaver-command –lockFrom a text console, run this, part of the vlock package:vlock -aFor KDE, right click on the desktop and select “Lock Session”. In Ubuntu, press Ctrl-Alt-l (the letter “Ell”, configurable in System/Preferences/Keyboard shortcuts). All require the password of the logged-in user to continue work.
3. Do your day-to-day work with a non-root account. When you need to do root-level tasks, become root with “sudo” or “su” long enough to do the task (alternately, log in as root on a text console for this task). http://www.stearns.org/doc/sudo.current.html

Go check out the rest of the tips.

Bookmark This Page:

Hide Sites

• Nmap Security Scanner
  Nmap, which stands for “Network Mapper” is a free open source utility that allows you to explore and audit a network. From the website: “Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics.”
  For Nmap installation documents, go here.
  There is a very useful tutorial here on the numerous scan types Nmap allows.
  This PDF is a great print-out reference that includes all of the major Nmap options.
• Nessus Vulnerability Scanner
  Nessus is a vulnerability scanner that probes your network machines against an up-to-date security vulnerability database, alerting you of security holes, with detailed analysis on how to fix each hole. From the Nessus website: “Nessus is the world’s most popular vulnerability scanner used in over 75,000 organizations world-wide. Many of the world’s largest organizations are realizing significant cost savings by using Nessus to audit business-critical enterprise devices and applications.”
  See an example scan report here.
  For Nessus installation documents, go here.
  A nice technical guide to Nessus can be found here.
  The Nessus knowledge base is here.
• Clam AntiVirus
  ClamAV is a GPL anti virus toolkit. The main purpose of ClamAV is the integration with mail servers, but can also be used to scan files for viruses on the command line. It provides a flexible and scalable multi-threaded daemon, a command line scanner and a virus database that is kept up to date. The most popular use of ClamAV is on a mail server, tied in with a anti-spam application like Spam Assassin.
  For installation help, go here.
  The Clam AntiVirus wiki can be found here.
  This PDF document covers all you need to know about ClamAV.
• Snort
  Snort is one of the greatest weapons you can have in the fight against intrusions. Snort is mainly used in three different ways: as a packet sniffer, a packet logger, or as a complete intrusion detection system (IDS). From the website: “Snort is an open source network intrusion prevention system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more.”
  The official Snort users manual can be found here.
  For a very complete comprehensive list of documents, go here.
• Chkrootkit
  Chkrootkit is a tool designed to locally check for signs of a root kit on your Linux machine. “Root kits” are basically files that can hide on your machine after a break in that allow the attacker to gain access to your computer in the future.
  This PDF explains adding chkrootkit to your auditing arsenal.
• Tripwire
  Tripwire is a security and data integrity tool useful for monitoring and alerting on specific file change(s) on a range of systems. Basically, tripwire has the ability to alert you when files have been modified on your system.
  A comprehensive guide to implementing tripwire can be found here.
  This is a nice howto on setting up tripwire.
• Rootkit Hunter
  Rootkit Hunter is a great tool for analyzing and monitoring the security of your systems. Like Chkrootkit, this tool also checks for rootkits that may be hiding on your machine, as well as other tools on your system that may be potentially dangerous.
  A detailed guide on downloading and installing Rootkit Hunter can be found here.
• Kismet
  From the website: “Kismet is an 802.11 layer2 wireless network detector, sniffer, and intrusion detection system.” If you have a wireless network, or travel with a laptop, this security tool is a must have.
  This Kismet readme covers just about all you need to know.
  There is also a lot of useful information located within the Kismet forums.
  
• Shorewall
  Shorewall is a very powerful and flexible firewall that utilizes iptables and Netfilter. Very flexible configuration allows the firewall to be used in a wide variety of firewall/gateway/router and VPN environments.
  The Shorewall Installation document can be found here.
  Here is a quick start guide to using Shorewall.
  Shorewall Features can be found here.
• Ethereal (Now called Wireshark)
  Wireshark is a very popular network protocol anyalizer that has a varaiety of security features including a packet browser, live capture and offline analysis and more. Basically, Wireshark captures packets going across the network and displays them to you with as much detail possible. From the users guide: “You could think of a network packet analyzer as a measuring device used to examine what’s going on inside a network cable, just like a voltmeter is used by an electrician to examine what’s going on inside an electric cable (but at a higher level, of course).”
  Here is the Wireshark users guide.
  The Wireshark wiki is here.

Now that you’ve gotten a glimpse at ten of the best Linux security tools, it is up to you to install them and put them to use in your network environment.

Bookmark This Page:

Hide Sites

David Kierznowski has uncovered an exploit in the popular WordPress blogging software that everyone should be aware of. Popular security website Security Focus has the issue documented, and it is suggested that you upgrade your template.php file as soon as possible to avoid becoming a victim.

The WordPress team has issued an updated release, version 2.0.6 that contains a fix.

Simply put, to fix the wordpress exploit, visit the wordpress site and edit line 114 in your template.php file.

Bookmark This Page:

Hide Sites

Safepasswd is a website dedicated to helping you choose a safe and secure password. The secure passwords are automatically generated for you, allowing you the following options: easy to remember, letters only, numbers only, letters and numbers, all characters, and hex. This is a great tool for both administrators and standard computer users, as it practices the need to create stronger passwords.

Bookmark This Page:

Hide Sites

SecurityFocus’ Mikhael Felker has written part two of his analysis of the security mechanisms, risks, attacks, and defenses of the two most commonly used password management systems: those found in Internet Explorer and Firefox. Felker outlines the following areas of discussion:

• Password storage mechanisms: The means of safeguarding usernames and passwords on the local file system through encryption (addressed in part 1).
• Attacks on Password Managers: The methods of subverting or bypassing safeguards (partially address in part 1; continued now in part 2)
• False sense of security: Users employing password managers without any awareness of the risk factors.
• Usability: Features that enhance or deter the usability of security features.
• Mitigation and Countermeasures: Actions that can be taken by users and corporations to reduce the risk.

This article is a great read. Storing passwords in web browsers is common amongst users, and it is important to understand the risks involved. So get to reading.

Password Management Concerns with IE and Firefox, Part One

Password Management Concerns with IE and Firefox, Part Two

Bookmark This Page:

Hide Sites

First, lets take a look at a default SSH Config file: sshd_config:

# $OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 dtucker Exp $
# This is the sshd server system-wide configuration file.
# See sshd_config(5) for more information.
# The strategy used for options in the default sshd_config
# shipped with OpenSSH is to specify options
# with their default value where possible, but leave them
# commented. Uncommented options change a default value.
#
#Port 22
#Protocol 2,1
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don’t trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don’t read the user’s ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to ‘yes’ to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of “PermitRootLogin without-password”.
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to ‘no’.
#UsePAM no
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
# no default banner path
#Banner /some/path
# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# AllowTcpForwarding no
# ForceCommand cvs server

As we can see, by default most of the configuration options are commented out, meaning that SSH is taking the default values. To maximize SSH security, we are going to modify the following lines:

#Port 22

#Protocol 2,1

#PermitRootLogin yes

#PermitEmptyPasswords no

#MaxAuthTries 6

#AllowUsers

The six lines pulled out from the sshd_config are the lines that I feel are the most important and basic modifications that should be made to the configuration. Here is what they should be changed to (remember to uncomment them):

Port 60 (pick any port, 60 is just an example)

Running the SSH daemon on a port other than the default port of 22 will minimize your servers vulnerability of being scanned automatically by botnets that search and automate login and password attempts on SSH servers. Keep in mind that after you change the port number on your SSH server, you will need to specify the port whenever you are connecting to the server.

Protocol 2

The SSH protocol 1 is very outdated and nobody should be running it. Protocol 1 had some security issues, so it is pretty mindless to even allow it in your configuration.

PermitRootLogin no

Logging into your SSH server as the root user should not be necessary. The best practice is to log in as a normal user and in the event of needing root privileges you can use the su command to switch to the root user.

PermitEmptyPasswords no

You do not want to allow user accounts that have empty passwords to log into your Linux server via SSH.

MaxAuthTries 3

Setting the MaxAuthTries to a low number will minimize the risk of your SSH server being attacked in a brute force type of way. Automated attacks will disconnect after a third password failure. Though they may reconnect, it can slow the process down and will definitely minimize the potential breach by way of brute force password attempts.

AllowUsers adamk tom sam john jane mark

Setting AllowUsers in the configuration file greatly reduces the risk of automated brute force attacks. If you specify that only certain users are allowed to log into the machine via SSH then you have less to worry about in that aspect. List out all of the user names that are allowed to connect to the SSH server and separate them with spaces.

Conclusion:

We’ve looked at six different configuration modifications that will improve our Secure Shell (SSH) server.

1. Running SSH daemon on a different port.
2. Allowing only users running protocol 2 to connect to the server
3. Denying root logins over SSH
4. Denying users with empty passwords to connect
5. Permitting a limited number of authorization retries.
6. Allowing only certain specified users to log in.

With these settings in place, and our SSH server restarted in order to take these configuration changes into effect, we are one step closer to a safer and more secure server.

Bookmark This Page:

Hide Sites

1. Secure Shell (SSH)
2. File Transfer (FTP)

Preventing access to the SSH server:

The best and most secure practice of running an SSH server is to tighten the hatches as much as possible. In this example, I will show you how to edit your sshd_config file and allow only certain users (except “joe”) to access the system via SSH. Now, lets say that you want to prevent the user “joe” from logging into SSH, but you still want him to be able to access the machine via FTP. Here is what you would do:

• Open /etc/ssh/sshd_config in your favorite text editor.
  • vim /etc/ssh/sshd
• Add a line that says AllowUsers
  • AllowUsers adamk tim sean jacob dave
    
  • Note that joe is not included here.
  • Save the sshd_config file.
  • Restart your sshd daemon.

Another (quick) way to do this in one simple command is:

• • echo “AllowUsers adamk tim sean jacob dave” >> /etc/sshd/sshd_config

This modification to /etc/sshd/sshd_config will allow Joe to access your system via FTP only.

Preventing access to the FTP server:

Now lets look at how to prevent the user “joe” from logging into your server via FTP. Here is what you would do:

• Open /etc/ftpusers in your favorite text editor.
  • vim /etc/ftpusers

• Add “joe” to the bottom of the file.
  • Save the file.
  • Joe will now be unable to login via FTP to your machine.

Completely disable a users access:

To completely disable the user “joe” from accessing the system here is what you would do:

• Open /etc/passwd in your favorite text editor.
  • vim /etc/passwd

• Locate the line that starts with “joe”.
  • joe:x:1000:100:Joe,,,:/home/joe:/bin/bash

• Change the “x” to a “*”
  • joe:*:1000:100:Joe,,,:/home/joe:/bin/bash

• Save the file.
• Joe is now locked out of the machine.

Another (quick) way to lock a users access is:

• passwd -l joe

Conclusion:

It is important to be able to quickly lock a user out of your system at any given time. Knowing these three different ways of preventing access to FTP and SSH for a certain user is crucial to your system administration knowledge and I hope that you use this knowledge to better secure your system.

Bookmark This Page:

Hide Sites

Password Your BIOS:

Just about every BIOS these days has an option to set a password in order to boot the system. You will need to reboot your computer and boot into your BIOS, then find the option related to passwords. Setting a password on your BIOS will ensure that anyone booting your machine will not be able to load your operating system without supplying the proper password upon initial boot of the machine. Setting a password on your BIOS will also prevent someone from throwing in a bootable CD-ROM or floppy disk and loading something like a live CD or password cracker.

Password Your Boot Manager:

Another measure of security to take is to password your boot manager, if you have one. A boot manager is usually loaded after the BIOS and is present on systems that have a dual-boot setup. Such systems like those running Linux and Windows, or more than one operating system. Without the adequate security precautions and passwords in place, someone with physical access to your machine will have the ability to boot your kernel into single user mode, or with root privileges with a few extra parameters at the boot manager prompt. So with that said, I will explain how to password LILO and GRUB, as they are the two most popular boot managers to date.

Passwording LILO:

There are two different ways you can tell LILO to prompt for a password.

1. Always
2. If someone tries to pass special kernel parameters at boot

If you want LILO to always prompt for a password before loading your kernel image, you will want to make the following changes to your /etc/lilo.conf configuration file:

Under the global options area, add:

password=passwordhere
mandatory
Obviously, replace passwordhere with something more suitable.

Save the /etc/lilo.conf configuration file and execute LILO in order to reinstall the configuration changes:

/sbin/lilo

If you want LILO to only prompt for a password if someone tries to pass kernel parameters at the boot prompt, add the following lines instead:

password=passwordhere
restricted

Again, be sure to replace passwordhere with something more suitable.

Save the /etc/lilo.conf configuration file and execute LILO in order to reinstall the configuration changes:

/sbin/lilo

Passwording GRUB:

If you use GRUB instead of LILO, here is what you’ll want to do in order to set a password.

As the root user, run:

grub-md5-crypt
Password:
Retype Password:
$1$bCOp17$HFxXT4G56tOIc9Xq2s/CE.

You will be prompted twice for a password. Then you will receive a long output of characters, which is your hash. Take that output and copy/paste it into your grub.conf (usually located in /boot/grub/) like so:

password –md5 $1$bCOp17$HFxXT4G56tOIc9Xq2s/CE.

A lot of people may think that taking precautions for physical security is a bit dramatic and should be done by the paranoid only. I disagree. Practicing good security is essential to ensuring your computers are safe no matter what the case may be. Do you lock your doors when you go to sleep? If you find the answer to be pretty logical, then chances are you’ll agree that a BIOS password along with a boot loader password is essential for protecting your machines from physical attacks.

Bookmark This Page:

Hide Sites

The distribution used in this document is Slackware 11.0 on a custom 2.6.18.1 kernel. While it is possible and sometimes needed to install Nessusd on a ‘server’ and NessusClient on a ‘workstation’, in this document, we go over installing Nessusd and NessusClient both on the same machine.

Installing Nessus 2.2.9:

For the most part, you will want to refer to the Nessus installation documents provided on the Nessus website. However, the easiest way to get Nessus installed is to download the installer that is suitable for all Unix systems. Visit the Nessus website and download the file. Once downloaded, execute it by typing:

root@foo:~# sh nessus-installer-2.2.9.sh

After completing the installation, you will want to create a certificate as well as add a nessusd user.

adam@foo:~$ nessus-mkcert

follow on screen instructions

adam@foo:~$ nessus-adduser

follow on screen instructions

Now all we need to do is start the nessus daemon.

adam@foo:~# nessusd -D

Installing the Nessus GUI Client:

Since I find it easier to use the Nessus Client, we will go over that installation as well. First, go to Downloads area on the Nessus website and select the NessusClient 1.0.1 (a GUI for Nessusd). After downloading, install it by executing:

adam@foo:~/source/NessusClient-1.0.1$ ./configure && make

adam@foo:~/source/NessusClient-1.0.1$ su
Password:
root@foo:~/source/NessusClient-1.0.1$ make install

Now execute NessusClient

adam@foo:~$ /usr/local/bin/NessusClient

Now you should see a pretty GUI.

Scanning a Host for Vulnerabilities:

For the purposes of this document, we will run a simple scan on our localhost with all the default configuration settings. Feel free to tinker with the settings to produce maximum results on your scans.

In order to scan a host for vulnerabilities, we must tell NessusClient that we want to create a new task and a new scope. Click Task > New and give your task a name of localscan.

We then need to tell NessusClient to connect to our nessus server daemon, which in this case will be localhost. Click on File > Connect, your screen should look something like this:

Once all settings are correct, click OK and NessusClient will connect to the nessus daemon. During connect, you should see a window telling you that Nessus is loading all the plugins.

Next, in the Options menu, navigate to the Target Selection area and make sure localhost is added. You can add more hosts by separating them with a comma. Click to enlarge.

Now all we need to do is tell the NessusClient to execute the scan by clicking on Scope > Execute. This will bring up a window that shows the status of the scan.

Once the scan is complete, Nessus will generate a report file that lists everything found during the scan along with the severity of each issue. Read through each item found and follow any solution instructions given.

Thats all! I would recommend reading through the documentation on the http://www.nessus.org/documentation/ website and adjusting the settings to fit your needs further.

Good luck and happy auditing!

Bookmark This Page:

Hide Sites