On Linux, the magic SysRq key can send commands directly to the Linux kernel. You can use it to recover from freezes or cleanly restart your system, even if nothing appears to be responding.

The magic SysRq key is implemented as part of Linux’s keyboard driver – it will work as long as the Linux kernel is still running. Only a kernel panic should disable this key combination.

Image Credit: solylunafamilia on Flickr

Using the Magic SysRq Key

The SysRq key is located near the Scroll Lock key on your keyboard – the Sys Rq key is generally the same as your Print Screen key. The “magic” SysRq combination is Alt+SysRq.

To use this key combination, your Linux kernel must have been compiled with the CONFIG_MAGIC_SYSRQ compile option – most Linux distributions will have this enabled by default. Assuming it’s compiled into your kernel, it can be enabled or disabled on a running system by changing the value of /proc/sys/kernel/sysrq. To check if it’s enabled, run the following command:

cat /proc/sys/kernel/sysrq

If you see a “1”, the magic SysRq key is enabled.


If you see a “0”, you’ll have to enable it yourself by running the following command as root:

echo “1” > /proc/sys/kernel/sysrq

Dealing With a Frozen X Server

If your X server (the program that runs your graphical desktop) freezes, you may find yourself unable to use your system. There are a few magic SysRq commands that can help:

  • Alt + SysRq + r – Takes the keyboard out of raw mode, taking control away from the X server. After running this combination, you should be able to use the Ctrl + Alt + F1 (and other F-key) keyboard shortcuts to switch to another console and restart X.
  • Alt + SysRq + k – Kills all programs on the current virtual console, including X. You can also enable the Ctrl+Alt+Backspace keyboard shortcut in Ubuntu’s keyboard preferences to restart your X server – however, this shortcut is implemented by the X server and may not always work.

Cleanly Restarting Your System

Used in sequence, some of these actions can be used to cleanly end processes, flush data to disk, unmount all file systems, and restart your computer. To perform this process, press and hold the Alt + SysRq key combination and – while holding the Alt and SysRq keys down — type the following keys in order, pausing for several seconds in between each key:


The mnemonic “Raising Elephants Is So Utterly Boring” is often used to remember this sequence. Here’s what each key does:

  • r – Puts the keyboard into raw mode, taking control of it away from the X server.
  • e – Sends the terminate signal to all processes, asking them to end gracefully.
  • i – Sends the kill signal to all processes, forcing them to end immediately.
  • s – Flushes data from your cache to disk.
  • u – Remounts all file systems read-only.
  • b – Reboots your computer.

More Commands

Here are some other actions you can perform with the magic SysRq key. To perform an action, press and hold the Alt + SysRq keys while typing the letter:

  • n – Resets the nice level (priority) of all high and realtime priority processes.
  • f – Calls oom_kill, which will kill a memory-hogging process.
  • o – Shuts off the computer.

There are other actions, but they may be more useful to developers than the average Linux geek. For more information on the magic SysRq key – and a full list of actions you can perform – consult the sysrq.txt file included with the Linux kernel.

 1,737 total views


DefenseCode released an advisory in which researcher Leon Juranic details security issues related to using wildcards in Unix commands. The topic has been talked about in the past on the Full Disclosure mailing list, where some people saw this more as a feature than as a bug.

There are clearly a number of potential security issues surrounding this, so Mr. Juranic provided five actual exploitation examples that stress out the risks accompanying practice of using the * wildcard with Linux/Unix commands.

The issue can be manifested by using specific options in chown, tar, rsync etc. By using specially crafted filenames, an attacker can inject arbitrary arguments to shell commands run by other users – root as well.

One of the examples provided is the tar arbitrary command execution. The binary has two options that can be used for poisoning:

display progress messages every NUMBERth record (default 10)

execute ACTION on each checkpoint

By using tar with these options, a specified action can be used after a checkpoint. This action could be a malicious shell script that could be used for executing arbitrary commands under the user who starts tar. “Tricking” root to use the specific options is quite easy, and that’s where the wildcard comes in handy.

Running tar cf archive.tar * on a folder with these files seems pretty straightforward and benign.

[[email protected] public]# ls -al
drwxrwxrwx. 2 user user 4096 Oct 28 19:34 .
drwx——. 24 user user 4096 Oct 28 18:32 ..
-rw-rw-r–. 1 user user 20480 Oct 28 19:13 admin.php
-rw-rw-r–. 1 user user 34 Oct 28 17:47 ado.php
-rw-rw-r–. 1 user user 187 Oct 28 17:44 db.php
-rw-rw-r–. 1 user user 201 Oct 28 17:43 download.php

The problem arises if the user created a couple of fake files and a shell script that contains any arbitrary command.

[[email protected] public]# ls -al
drwxrwxrwx. 2 user user 4096 Oct 28 19:34 .
drwx——. 24 user user 4096 Oct 28 18:32 ..
-rw-rw-r–. 1 user user 20480 Oct 28 19:13 admin.php
-rw-rw-r–. 1 user user 34 Oct 28 17:47 ado.php
-rw-r–r–. 1 leon leon 0 Oct 28 19:19 –checkpoint=1
-rw-r–r–. 1 leon leon 0 Oct 28 19:17 –checkpoint-action=exec=sh
-rw-rw-r–. 1 user user 187 Oct 28 17:44 db.php
-rw-rw-r–. 1 user user 201 Oct 28 17:43 download.php
-rwxr-xr-x. 1 leon leon 12 Oct 28 19:17

By using the * wildcard in the tar command, these files will be understood as passed options to the tar binary and will be executed as root.

The advisory in question details other similar exploitation methods. Also, around the same time when Mr. Juranic informed us about his work, another researcher posted to the Full Disclosure mailing list a similarly themed research focused on exploiting wildcards.

Is there a workaround? To quote the most upvoted post on a recent Reddit thread regarding wildcard exploitation: “./* Done”.

 1,181 total views


Security Checklist for Linux System

I don’t really know why this subject is routinely ignored by users regardless of device or OS. Everyone seems to be concerned with their own security, but it all ends merely on complaining and blaming others, not ourselves.

Maintaining security of an operating system is one of the primary responsibilities of any Linux system administrator. I must say that, its also one of the toughest tasks. You can never be certain, that the machine you’re working on is secure. To be honest, there is no way a machine connected to the Internet, can be called as a secure machine. To be honest, there is no such thing as security the moment you connect to the Internet.

securityBefore we proceed I must tell you something. Don’t get fooled by the phrase –

Linux system administrator.

Don’t think this post is for some geek with glasses, sitting in a dark, smelly room, with empty cans and fast-food containers lying around, staring at thousands of computer screens doing his computer voodoo. No. This post is mainly for you, the Linux user. Believe it or not, you ARE a Linux administrator. You use, maintain, update your Linux system, don’t you? Even if it’s merely a small Raspberry Pi, a laptop or XMBC server, it doesn’t matter at all. Those are still Linux machines, nothing else, and they need your care and attention!

Let’s get back to our point. The only way you can make your computer to be the most secure machine in the world, just by pulling out the Network cable, or ripping your WiFi card out of your computer. If you think a bit deeper you will realize, that its quite true. You cannot make a system completely secure. Even if you don’t connect to the Internet (yeah, you don’t), there still exists a risk for your system to be at risk. You use removable media, mount USB sticks and CD/DVD/Blu-Ray disks that were not created by you. Unix/Linux viruses do exist. Threats to Linux systems are also posed by other forms of malware, such as Trojan horses, rootkits, and spyware. Yeah, don’t believe anyone saying there is no virus for Linux and that Linux is safe and secure! It’s completely untrue! Unix/Linux viruses do exist. Your system won’t be secure unless you take care of it!

In this post, I have created a mini security checklist for a Linux server, consisting of things I think are crucial for maintaining a sane server. I know that not all of them can be implemented everywhere, but for a general Linux usage, they’re an imperative.

Note: As said, this checklist won’t make your system a secure one. However, it would surely reduce the risk of your system being compromised.

  1. Keep the system updated with latest security patches
  2. Keep yourself updated with latest vulnerabilities through mailing lists, forums etc.
  3. Stop and disable unwanted services
  4. Use SUDO to limit ROOT Access
  5. SSH security settings
  6. Tunnel all of your XWindow sessions through SSH
  7. Create only a required number of users
  8. Maintain a good firewall policy
  9. Scan for viruses and other malware!
  10. Configure SSL/TLS if you are using FTP
  11. Secure your communication with GPG
  12. Check file permissions across filesystems
  13. Bootloader and BIOS security
  14. Enable remote Logging
  15. Keep a good password policy


Keep the system updated with latest security patches

You must be aware that this is the first and the most important thing to do for your system. There really exists a widespread belief that Windows should be updated, but Linux is much secure even without the patches and updates. This is totally wrong.

If you have a look at any security report, you will realize that out of all the compromises that took place, most of them occurred because of old vulnerable version of software packages or kernel.

CVE (Common Vulnerability Exposures) vulnerability details, always point towards a specific version of the package and the vendor of the package most of the times already roll out their patches.





 package manager, to keep the packages updated. If using Debian-based system, add the security repository to your 



Also, patch your kernel in an organised manner from time to time with latest patches available.


Keep yourself updated with latest vulnerabilities through mailing lists, forums etc.

Many open source mailing lists (product specific as well as Linux general), offer detailed information and the relevant fixes required for the latest vulnerabilities.

You should always keep yourself updated about a specific product by subscribing to security mailing lists. Don’t consider it a spam and forget about it. Read the messages posted there at least from time to time.



Stop and disable unwanted services

You should get to know all the services running on your system, and periodically consult with other users to ensure that only services that are required are running. No unwanted service should be running on your server. Making a list of boot up services from 





 can provide you with a list of services that will come up at boot time. Disabling unwanted services on the server will also improve the server performance wise. Webmin, a web-interface for your system, might come in hand if you don’t feel comfortable enough with command line.


Use SUDO to limit ROOT Access



 to restrict user to some critical commands, is advisable. You can easily achieve this by modifying 




 can be configured on a command by command basis, 


 file can be used to control the commands with restrictions.


SSH security settings

Almost all Linux machines use SSH service for remote login. You use SSH to access your Raspberry Pi, don’t you? Although SSH is pretty secure by itself, it doesn’t have the ability to protect the server against human mistakes. Some precautions must always be done regarding the SSH protocol.

First of all, disable 


 login through SSH protocol, by modifying the


 file and setting:

PermitRootLogin no

Make sure that SSH protocol version 2 is used instead of 1 (latest version of the packages use version 2 by default, so no need to modify):

Protocol 2

Bing the default SSH port from 22 to any other (as well as IP, pointing to your machine’s IP):

Port 300

Disable Host-Based Authentication:

HostbasedAuthentication no

Limit only specific users to access your machine via SSH:

AllowUsers user1 user2

Disable password-based authentication and allow public key based authentication. This will help to securely allow users whose public key is deployed on the server to login through SSH. This can be done by modifying the 


 file on the server as below:

ChallengeResponseAuthentication no
PasswordAuthentication no
PubkeyAuthentication yes

For more tips, head to nixCraft website.


Tunnel all of your XWindow sessions through SSH

This will harden the graphical communications which is normally unencrypted. To do this, you need to have the following entry in your 



ForwardX11 yes

Now you can connect the server using

ssh -X -c [email protected] -p 123



 option allows us to use forwarded XWindow system.



 designates port to connect to if using different port than the default 22.



 option is a nice way to compress the traffic. Its a good option is you have low bandwidth.


Create only a required number of users

This is self-explanatory. There is no need to create thousands of user accounts. Make a list of all user accounts you have on the server, and delete all unwanted users on the system.


Maintain a good firewall policy

Write down the IP/subnets that you want to allow access to the machine and allow only them. It’s a good idea to make a firewall script for both inbound and outbound connections and enable the script for the firewall rules.

On most of the Linux firewalls, the order in which the rules are applied matters. So as mentioned, managing all rules for the firewall with a firewall script, and checking periodically the set of rules applied is a good idea.

There are a lot number of firewall’s available for Linux out there, some of them are mentioned below.

  • iptables
  • ufw
  • checkpoint
  • shorewall
  • pfsense

The important thing that matters is how you configure them, because almost all of them are good at what they do. According to me, iptables, the default firewall for most of the distributions out of the box, will be a good point to start with. You can do almost everything, that you need with this firewall. If you’re interested, here ismy post about iptables, and here you can find an example iptables script.

On top of a firewall, you might want to use additional software, like fail2ban orsnort that running along with your firewall, harden your system.


Scan for viruses and other malware!

As mentioned at the beginning, Linux is not virus-proof. In fact, Any computer that is attached to a network is not immune to viruses. The next thing you might want to do is to take a critical look at who’s knocking at your doors. You should also scan your machine for viruses.

To make sure everything that gets into your system is clean and safe useClamA[nti]V[irus]:

To install:

sudo apt-get install clamav

To update:

sudo freshclam

To inspect e.g. your download folder:

sudo clamscan -ri /path/to/your/home/downloads

This will ClamAV do a scan recursively, i.e. also scan the content of folders and inform you about possibly infected files.

To inspect your whole system:

sudo clamscan -irv --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/media --exclude=/mnt

Remember: ClamAV is known for its tight nets. That means that you are likely to get some false positives from time to time. Do a web-search if you’re in doubt in regards to its findings.

To hunt down any rootkits that might infect your system, use RKHunter – which is short for [R]oot[K]itHunter. Installation, again, is simple:

sudo apt-get install rkhunter

The best is to run rkhunter on a clean installation – just to make sure nothing has been tampered with already. Directly after commands like apt-get update && apt-get upgrade run:

sudo rkhunter --propupd

This tells rkhunter: It’s all good.

To run rkhunter:

sudo rkhunter -c --sk

You find rkhunter’s logfile in 


. So when you get a warning you can in detail check out what caused it.

To set up a cronjob for RKHunter:

sudo nano /etc/cron.daily/

insert and change the mail-address:

-c --cronjob 2>&1 | mail -s 
"RKhunter Scan Details"
[email protected]

make the script executable:

sudo chmod +x /etc/cron.daily/

update RKHunter:

sudo rkhunter --update

and check if it functions the way it’s supposed to do:

sudo rkhunter -c --sk

Another neat tool with similar functionality is 


. To install:

sudo apt-get install chkrootkit

To run:

sudo chkrootkit


Configure SSL/TLS if you are using FTP

FTP is considered to be an insecure protocol. It is advisable that you do the following things while working with FTP service:

  • Use the latest version of the FTP package
  • Force only required users to login through FTP
  • Allow only TLS with FTP access to the server.
  • If possible, keep the user in chroot jail.


Secure your communication with GPG

You can encrypt communication going from your machine using GPG. It’s a good practice, ensuring no unauthorized access to critical data, like logwatch, system reports, but also protects your own mail and conversations. For more information on GPG head here: GNU Privacy Guard – The Basics.


Check file permissions across filesystems

As you might already know, the file permissions play an important role in securing a Linux server. You need to periodically make sure all your important files are given permissions correctly.

Things to check regarding file permissions:

  • Check and confirm, if the UMASK value is as required
  • Periodically search for files with absurd permissions set on them. Like globally writeable files etc. You can search them using command:
find / -perm -o=w ! -type l -ls
  • Use tools like adeos for potential file state. Scanning the whole system with tools like adeos for files with dangerous permissions is a good method to follow. You can get the tool from here. It will search for files which are world writable, SUID etc.


Bootloader and BIOS security

Normally, people ignore this step as they always think attackers and intruders are always remote people tying to gain access over the Internet.

Access to BIOS means access to do anything… You can easily boot the system from any disk or other media if you have access to BIOS. So keep a secure password for BIOS. Also, protect your boot loader (GRUB, LILO) with a secure password, so that no one would change your boot options without password.


Enable remote Logging

Most of the time intruders and attackers after gaining access to the system, delete the system logs in order to delete any trace of their intrusion. However, if you have remote logging enabled, the attacker now needs to compromise multiple systems to delete the logs (which most of the times is not that easy). You can achieve remote logging with multiple tools like the following:


Keep a good password policy

Understand the usage of 


 command and use it effectively to modify password setting per user. By default, the command will show you the password information of a particular user.

chage --list <username>

Modify the password expiry per user with the help of 



chage -M <number of days to expire> <username>

Modify the 


 file to suite your needs. Also check and confirm /


 (this sets the default settings when a user is created) is as required.


I hope you enjoyed the read and found at least one useful thing for your system.

If you have any other tips for keeping the system secure, please let me know, and, most of all, leave a comment.

Pass this on:


POSTED: 11.12.2013



5 Responses to “Security Checklist for Linux System”

  1. Michael says:

    Great article and nice tips! For automated testing and hardening, have also a look at my open source auditing tool Lynis.

    Project page:

    Happy hardening!

  2. Great post ! Thanks for sharing with us 🙂

  3. planetscape says:

    Just what I needed, thank you!

  4. santhosh says:

    Every system administrator need to follow this checklist to make system more secure.

    Great post! Thanks for sharing.

 1,202 total views

Fresh hacks every day
DECEMBER 6, 2013
SkyJack: A Drone to Hack All Drones

December 6, 2013 by Josh Marsh 9 Comments

Quadcopters are gradually becoming more affordable and thus more popular; we expect more kids will unwrap a prefab drone this holiday season than any year prior. [Samy’s] got plans for the drone-filled future. He could soon be the proud new owner of his own personal army now that he’s built a drone that assimilates others under his control.

The build uses a Parrot AR.Drone 2.0 to fly around with an attached Raspberry Pi, which uses everybody’s favorite Alfa adapter to poke around in promiscuous mode. If the SkyJack detects an IEEE-registered MAC address assigned to Parrot, aircrack-ng leaps into action sending deauthentication requests to the target drone, then attempts to take over control while the original owner is reconnecting. Any successfully lassoed drone doesn’t just fall out of the sky, though. [Samy] uses node-ar-drone to immediately send new instructions to the slave.

You can find all his code on GitHub, but make sure you see the video below, which gives a thorough overview and a brief demonstration. There are also a few other builds that strap a Raspberry Pi onto a quadcopter worth checking out; they could provide you with the inspiration you need to take to the skies.

 1,095 total views