Shellshock: How to protect your Unix, Linux and Mac servers

Summary: The Unix/Linux Bash security hole can be deadly to your servers. Here's what you need to worry about, how to see if you can be attacked, and what to do if your shields are down.

The only thing you have to fear with Shellshock, the Unix/Linux Bash security hole, is fear itself. Yes, Shellshock can serve as a highway for worms and malware to hit your Unix, Linux, and Mac servers, but you can defend against it.

If you don't patch and defend yourself against Shellshock today, you may have lost control of your servers by tomorrow.

However, Shellshock is not as bad as HeartBleed. Not yet, anyway.

While it's true that the Bash shell is the default command interpreter on most Unix and Linux systems and all Macs — the majority of Web servers — for an attacker to get to your system, there has to be a way for him or her to actually get to the shell remotely. So, if you're running a PC without ssh,rlogin, or another remote desktop program, you're probably safe enough.

A more serious problem is faced by devices that use embedded Linux — such as routers, switches, and appliances. If you're running an older, no longer supported model, it may be close to impossible to patch it and will likely be vulnerable to attacks. If that's the case, you should replace as soon as possible.

The real and present danger is for servers. According to the National Institute of Standards (NIST),Shellshock scores a perfect 10 for potential impact and exploitability. Red Hat reports that the most common attack vectors are:

• httpd (Your Web server): CGI [Common-Gateway Interface] scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.
  
• Secure Shell (SSH): It is not uncommon to restrict remote commands that a user can run via SSH, such as rsync or git. In these instances, this issue can be used to execute any command, not just the restricted command.
  
• dhclient: The Dynamic Host Configuration Protocol Client (dhclient) is used to automatically obtain network configuration information via DHCP. This client uses various environment variables and runs Bash to configure the network interface. Connecting to a malicious DHCP server could allow an attacker to run arbitrary code on the client machine.
  
• CUPS (Linux, Unix and Mac OS X's print server): It is believed that CUPS is affected by this issue. Various user-supplied values are stored in environment variables when cups filters are executed.
  
• sudo: Commands run via sudo are not affected by this issue. Sudo specifically looks for environment variables that are also functions. It could still be possible for the running command to set an environment variable that could cause a Bash child process to execute arbitrary code.
  
• Firefox: We do not believe Firefox can be forced to set an environment variable in a manner that would allow Bash to run arbitrary commands. It is still advisable to upgrade Bash as it is common to install various plug-ins and extensions that could allow this behavior.
  
• Postfix: The Postfix [mail] server will replace various characters with a ?. While the Postfix server does call Bash in a variety of ways, we do not believe an arbitrary environment variable can be set by the server. It is however possible that a filter could set environment variables.

So much for Red Hat's thoughts. Of these, the Web servers and SSH are the ones that worry me the most. The DHCP client is also troublesome, especially if, as it the case with small businesses, your external router doubles as your Internet gateway and DHCP server.

Of these, Web server attacks seem to be the most common by far. As Florian Weimer, a Red Hat security engineer, wrote: "HTTP requests to CGI scripts have been identified as the major attack vector." Attacks are being made against systems running both Linux and Mac OS X.

Jaime Blasco, labs director at AlienVault, a security management services company, ran a honeypot looking for attackers and found "several machines trying to exploit the Bash vulnerability. The majority of them are only probing to check if systems are vulnerable. On the other hand, we found two worms that are actively exploiting the vulnerability and installing a piece of malware on the system."

Other security researchers have found that the malware is the usual sort. They typically try to plant distributed denial of service (DDoS) IRC bots and attempt to guess system logins and passwords using a list of poor passwords such as 'root', 'admin', 'user', 'login', and '123456.'

So, how do you know if your servers can be attacked? First, you need to check to see if you're running a vulnerable version of Bash. To do that, run the following command from a Bash shell:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you get the result:

vulnerable this is a test

Bad news, your version of Bash can be hacked. If you see:

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test

You're good. Well, to be more exact, you're as protected as you can be at the moment.

While all major Linux distributors have released patches that stop most attacks — Apple has not released a patch yet — it has been discovered that "patches shipped for this issue are incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions." While it's unclear if these attacks can be used to hack into a system, it is clear that they can be used to crash them, thanks to a null-pointer exception.

Patches to fill-in the last of the Shellshock security hole are being worked on now. In the meantime, you should update your servers as soon as possible with the available patches and keep an eye open for the next, fuller ones.

In the meantime, if, as is likely, you're running the Apache Web server, there are some Mod_Security rules that can stop attempts to exploit Shellshock. These rules, created by Red Hat, are:

Request Header values:
SecRule REQUEST_HEADERS "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

SERVER_PROTOCOL values:
SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST names:
SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST values:
SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

File names for uploads:
SecRule FILES_NAMES "^\(\) {" "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

It is vital that you patch your servers as soon as possible, even with the current, incomplete ones, and to set up defenses around your Web servers. If you don't, you could come to work tomorrow to find your computers completely compromised. So get out there and start patching!

Modify the number of ttys in CentOS 6

First, log in as root

1 – modify /etc/sysconfig/init
vi /etc/sysconfig/initand modify the following line:
ACTIVE_CONSOLES=/dev/tty[1-6]
to
ACTIVE_CONSOLES=/dev/tty[1-12]

2 – modify /etc/init/start-ttys.conf
copy the current start-ttys.conf configuration
cp /etc/init/start-ttys.conf /etc/init/start-ttys.override
This new override file will be automatically taken into account by Centos instead of the original one
vi /etc/init/start-ttys.override
and modify the following line
env ACTIVE_CONSOLES=/dev/tty[1-6]
by
env ACTIVE_CONSOLES=/dev/tty[1-12]

This modification will be handled at the next start.

How to Create a Playlist on Your iPhone

Of course you can make playlists in iTunes and sync them with your iPhone, but you can also create playlists on your iPhone when you’re out and about. Here’s how:

1. Tap the Music icon.
2. At the bottom of the screen, tap the Playlists icon.
   If you’ve replaced Playlists with another icon as described previously, tap More, and then tap Playlists.
3. Tap the second item in the list, Add Playlist.
4. Type a name for your new playlist, and then tap Save.
   An alphabetical list of all songs on your iPhone appears. Note the little + that appears to the right of each song.
5. Tap the + next to a song name to add the song to your playlist.
   To add all these songs to your playlist, tap the + next to the first item in the list: Add All Songs.
6. In the upper-right corner, tap the Done button.

If you create a playlist on your iPhone and then sync with your computer, that playlist remains on the iPhone and will also appear in iTunes on your computer.

The playlists remain until you delete them in iTunes or on your iPhone. To remove a playlist in iTunes, select the playlist’s name in the source list and then press Delete or Backspace; to remove a playlist on your iPhone, swipe from left to right across the playlist and then tap the red Delete button.

You can also edit playlists on your iPhone. To do so, tap the Playlists icon at the bottom of the screen (or tap More and then tap Playlists), and then tap the playlist you want to edit. Three buttons appear near the top of the screen — Edit, Clear, and Delete — with the songs in the playlist listed below them.

Tap Clear to remove all the songs from this playlist; tap Delete to delete this playlist from your iPhone. Or tap Edit to do any (or all) of the following:

• To move a song up or down in the playlist: A little icon with three gray bars appears to the right of each song. Drag the icon up to move the song higher in the list or drag down to move the song lower in the list.
• To add more songs to the playlist: Tap the + button in the upper-left corner.
• To delete a song from the playlist: Tap the – sign to the left of the song name. Note that deleting a song from the playlist doesn’t remove the song from your iPhone.

When you finish editing, tap the Done button near the top of the screen. And that’s all there is to creating and managing playlists on your iPhone.

Sending e-mail using shell scripts

Most script programmers already know how easy it is to send e-mail from within shell scripts. A simple invocation of the mail program with the recipient for a command line argument will send all data read from standard input:

$ mail root < /tmp/db_reorg.log $ echo "Coming home for dinner!" | mail sylvia@home.com

The "mail" command accepts additional command line parameters, e.g.

-s subject	Use subject for the e-mail title
-c address	Send copy of the mail to the specified address
-b address	Send blind carbon copy to specified address

Some common usage examples:

Send a log file to the system administrator: # mail -s "Reorganization completed" root < db_reorg.log Send mail to "mark" with copy to "john": $ echo "John's coming with us" | mail -c john -s "Join us watching Star Wars" mark

Portability Note that not all mail commands have an "-s" option to specify a mail subject. Sometimes an extended version of the mail command is available with the name "mailx", e.g./usr/ucb/mailx, or "Mail" (with a capital "M").

But how can we "attach" a file to a mail? We know that newer mail readers like Mozilla, Netscape Messenger or Microsoft Exchange have a way of displaying file attachments, e.g. images, ZIP files or audio files. How can we send some mail text (e.g. "See this picture of me surfing!") together with a binary file (e.g. "surfing.jpeg")?

The next chapter describes the traditional approach using "uuencode".

---

File attachments with "uuencode"

Sending binary files does not work well for the Internet. We could send a binary file "surfing.jpeg" using this command:

mail -s "picture of me surfing" sylvia@home.com < surfing.jpeg

but chances are high that the image will be unusable the time it arrives at the recipient.

During mail delivery the mail is relayed from one mail delivery agent to the next, until it finally arrives at the recipient. Each delivery agent may transform the mail message, e.g. by stripping the 8th bit of each character, removing NUL bytes (ASCII code 0), converting the end-of-line character LF ("line-feed", ASCII code 12) to a local representation (e.g. CR LF), or removing trailing space or TAB characters from each line.

Since only some characters are sure to arrive unmodified, the traditional solution is to encode the mail from binary format to a text format that is safe to transmit. The program used for this is called "uuencode" ("UNIX to UNIX encoding"), the program to decode the data is called "uudecode".

The simplest way to send a file as a mail attachment is shown by the following example:

$ uuencode surfing.jpeg surfing.jpeg | mail sylvia@home.com

That's all! If Sylvia uses a current mail reader like Mozilla, Netscape Messenger or Microsoft Exchange, she will see a mail containing just one file attachment: the file "surfing.jpeg". In the command above we had to specify the file name two times: the first name denotes the input file to be encoded, and the second name is the file name the recipient will see.

This way we can include normal text, too:

$ (cat mailtext; uuencode surfing.jpeg surfing.jpeg) | mail sylvia@home.com

Note: The file name "surfing.jpeg" again appears twice on the uuencode command line: the first time to specify the input file name, the second time for the remote extraction file name.

The first "cat" will prepend the contents of the file "mailtext" to the "uuencode"ed data of the image "surfing.jpeg". Both commands are executed within a sub shell, to combine the output of both commands to one output stream redirected to the "mail" command.

This method of sending file attachments works fairly well, but still has some shortcomings:

• Many user agents cannot directly decode this kind of file attachments, e.g. "Eudora". Some mail agents explicitly require the decoding of the mail using the program "uudecode"
• The "uuencode" encoding is not standardized. Text encoded on one system may not be decoded correctly by the recipient's system

      [the content of the mail message was saved to
      the file "mail.uue"]
      $ uudecode mail.uue
      The file "surfing.jpeg" was written to the current directory

The next method does not have this disadvantages. It works with most (newer) mail user agents and uses the "Multipurpose Internet Mail Extensions" (MIME).

---

File attachments with MIME

The MIME Standard ("Multipurpose Internet Mail Extensions") defines an impressive list of new features for e-mail messages, e.g.

• arbitrary file attachments, e.g. images, audio files
• more than one file attachment per mail
• multi-part messages

Other features are non-ASCII character sets for message bodies and message headers.

But how can shell programmers use these features effectively?

At first there has to be a command-line driven program to send MIME mails. There are some MIME packages available free of charge, the most common being

• mutt written by Michael Elkins (http://www.mutt.org)
• MetaMail by Nathaniel S.Borenstein (ftp://ftp.research.telcordia.com/pub/nsb/)
• mpack by John G. Myers (ftp://ftp.andrew.cmu.edu:/pub/mpack/)

But check your local system before downloading one of these packages, many UNIX systems (e.g. Linux) come with one or more of them pre-installed.

mutt is an interactive, text-oriented e-mail client. Not very useful for usage in a script, one might think. But on closer view the program turns out to provide an easy way to send e-mails with file attachments. Have a look at the following example:

$ mutt -s "Birthday celebration" -a citymap.jpg all@friends.org \ < invitation.txt

This command shows how to specify four important parts of an e-mail:

• The recipient ("all@friends.org")
• The main body of the e-mail (read from standard input, here redirected from the file "invitation.txt")
• An attachment (with option -a)
• A subject line (option -s)

The interesting part is the option -a, which allows us to send an attachment (in this case a picture of a city map). We could have added more attachments by using multiple -a options.

mutt always reads a text from standard input that will become the main body of the e-mail, the text before the attachment. If the mail should consist of attachments only, we can either specify/dev/null as the file to read, e.g.

$ mutt -a syslogs.tar.gz admin@domain.org < /dev/null

or use an empty line as the mail body:

$ echo | mutt -a syslogs.tar.gz admin@domain.org

mutt does some work behind the scenes, e.g. it's looking at the file extensions of the attachments, and selects an appropriate MIME type for each. This works reasonably well (depending on the configuration of the system in general and mutt in particular), but if more control about MIME types and the sending of the e-mail is required, the next package may be more appropriate.

The remainder of this chapter will use programs of the MetaMail package for the examples. Don't worry if the command lines seem somewhat cryptic, at the end of this article we will present a script simplifying the sending of mail attachments.

MetaMail provides two programs to send mail: mailto and metasend. We will use the second one for scripting, because it can be used non-interactively. The most interesting command line arguments of metasend are listed in the following table [refer to metasend(1) for a complete list].

-b	batch (non-interactive) mode
-c cc	CC address (for copy of the mail)
-f filename	Name of file to attach
-m MIME-type	MIME content type, e.g. "text/plain" or "application/octet-stream"
-s subject	Title (subject) of the mail message
-t to	Recipient's address
-n	Next file attachment (needed for multiple file attachments)
-D description	Description of the file content
-o outputfile	Name of an output file. If the -t option is given, the mail is sent directly to the addressee

This new knowledge enables us to send an audio file using "metasend":

$ metasend -b -t john@friends.org -s "Hear our son!" \ -m audio/basic -f crying.au

This invocation of "metasend" sends a mail to "john@friends.org" (option -t) with the subject "Hear our son!" (option -s), without prompting for further arguments (option -b). Without the "-b" argument, the command would have asked for addresses to send "carbon copies" to. The file to attach is called "crying.au", and the file type is "audio/basic".

The file type (or "MIME-type") "audio/basic" gives the recipient's mail reader a hint on the contents of the file attachment. Some contents may be displayed directly (e.g. "text/plain", "image/gif"), for others the mail reader may call external programs to present the contents (e.g. "application/postscript", "audio/wav"). The relation between MIME content type and external program to call often is established using a file called "mailcap" (see mailcap(4), if available on your system). Mozilla or Netscape's Communicator allows to specify "helper applications" that are invoked depending on the MIME type.

An annoying property of "metasend" is the need to specify the MIME type for each file. The script sendfile simplifies this. The following example sends two files, "cover.gif" and "contents.ps":

$ sendfile editor@somewhere.com cover.gif contents.ps [Text to appear before the attachments, EOF to end] Hello John, you'll find a table of contents attached to this e-mail. ^D

The script is easier to use because it determines the MIME type of the specified files by examining their file name extension, e.g. ".gif" or ".ps".

The command used to determine the MIME type is getmimetype.

Enable EPEL Repo on CentOS 5 and CentOS 6

What is the EPEL repo?

The EPEL (Extra Packages for Enterprise Linux) yum repository is an excellent source for additional packages for CentOS. Instead of having to compile applications that aren’t included in CentOS’ built-in repositories from source, EPEL can be used.

The EPEL repo is enabled by simply installing an RPM. Please use the command below to install the EPEL repository on your CentOS server. If you are unsure of your CentOS version or architecture, 

CentOS 6 – 32-bit

1	rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

CentOS 6 – 64-bit

1	rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

CentOS 5 – 32-bit

1	rpm -Uvh http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm

CentOS 5 – 64-bit

1	rpm -Uvh http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm

After running the above commands for your relevant CentOS version, the following file is created:

/etc/yum.repos.d/epel.repo

The above file can be edited directly to enable or disable the EPEL repo.

SSHFS: How to Mount Remote Partition via SSH on CentOS

We can easily mount a remote file system by using SSHFS.

1. Enable the EPEL repo

We will need to install a few packages that are not available in the standard CentOS repository. In order to do this, we must enable the EPEL repo.

2. Install FUSE and SSHFS packages

SSHFS uses FUSE (Filesystem in Userspace). Install the required packages:

1	yum install fuse sshfs

 3. Load the FUSE module

1	modprobe fuse

Confirm that the FUSE module is loaded:

1	lsmod | grep fuse

2	fuse                   84368  2

(Optional) Make sure the FUSE module is loaded upon a reboot:

1	echo "modprobe fuse" >> /etc/rc.local

 4. Using SSHFS

Once the FUSE module is loaded, we can finally mount our remote partition using SSHFS:

1	sshfs user@remote_host:/remote_directory /local_mount_partition

2	sshfs root@1.2.3.4:/scripts /mnt

Note: SSHFS is not recommended for production, distributed file-systems. NFS is a better option, however, SSHFS can still be quite useful.