Please see: Viewing system information in the Commandline
Have a burning urge to discover the UUID’s of your disk partitions? Run Ubuntu or some other Debian based distro like maybe Debian? Well have I got the article for you friend! Here it is, two easy steps to discovering your UUID – and the best part? For two steps I’ll give you two different ways to get that pesky UUID on your screen.But first, what exactly is a UUID? From Wikipedia we see that a UUID is a Universally Unique Identifier. “The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else.”
For a little more trivia: A UUID is a 16-byte (128-bit) number. The number of theoretically possible UUIDs is therefore 216*8 = 2128 = 25616 or about 3.4 × 1038. This means that 1 trillion UUIDs would have to be created every nanosecond for 10 billion years to exhaust the number of UUIDs. That’s a lot of UUIDs.
These unique ID’s are used by Ubuntu to identify your various partitions for the system. So if you do a quick
You should see at least one, probably two and possibly more UUID’s in there. One for your primary partition and one for your swap partition, plus more if you have any removable devices, other drives or other partitions around. It will look something like UUID=1c9e4ae2-0ddc-4e3c-8758-4cdd6c90407a.
So how do you discover just what partition belongs to which UUID? Open up a terminal session (Applications -> Accessories -> Terminal) and type the following:
On my system, the output is as follows:
/dev/sda1: UUID=”1c9e4ae2-0ddc-4e3c-8758-4cdd6c90407a” SEC_TYPE=”ext2″ TYPE=”ext3″
/dev/sda5: UUID=”a647ea33-74ee-4123-84bf-7edc32e2e39b” TYPE=”swap”
So sda1 (my primary partition) and sda5 (my swap partition) are identified.
Or, your could type:
ls -l /dev/disk/by-uuid
and see something like this:
lrwxrwxrwx 1 root root 10 2008-01-02 08:26 1c9e4ae2-0ddc-4e3c-8758-4cdd6c90407a -> ../../sda1
lrwxrwxrwx 1 root root 10 2008-01-02 08:26 a647ea33-74ee-4123-84bf-7edc32e2e39b -> ../../sda5
There you can get the UUID and also see who owns the partitions, when they were last touched, their permissions and finally, what they’re called (sda1 and sda5 in this case).
If you’re trying to pin down which UUID is associated with a particular thing, such as your root partition, you can cat /etc/fstab and look for the UUID associated with the mount point “/“.
Nmap is a very powerful tool with LOTS of options and features to visualize your network. Check which services are running on various hosts and find suspicious malicious programs running in your network. Even though Nmap is the swiss-army knife for network scanning, most of its benefits can be gained by the average Network Administrator without diving deep in to its complications. Chances are, most of the time you will find yourself using common switches even if you know all of them.
The basic syntax for Nmap is ; nmap <IP ADD> , for eg:
the above command scans the given host with defaults – standard TCP connect method (-sT option) and known ports (those specified in the /etc/services file. You may need to scan a whole subnet, in which case you can use:
both the command would do the same here.
One of the simplest scan methods that I come up with almost every day is the Ping Scan:
nmap -sP 184.108.40.206
Starting Nmap 4.03 ( http://www.insecure.org/nmap/ ) at 2008-01-04 18:13 MVT
Host 192.168.0.3 appears to be up.
MAC Address: 00:B0:D0:D1:DD:97 (Dell Computer)
the -sP option simply pings the host and reports back whether the host is up or down. Run in the local network, it gives you some additional detail such as MAC Address and the Company for which the NIC card is registered. It is also possible to ping sweep your entire network by specifying a network address and the bitmask.
Stealth Scanning might come in handy too (-sS):
nmap -sS 220.127.116.11
Starting Nmap 4.03 ( http://www.insecure.org/nmap/ ) at 2008-01-04 18:19 MVT
Interesting ports on linuxbox (18.104.22.168):
(The 1671 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
111/tcp open rpcbind
Nmap finished: 1 IP address (1 host up) scanned in 0.156 seconds
The -sT method (default) makes a full connection to that port to see whether the port is open. But in a stealth scan a SYN packet is sent to the host and waits until a SYN from the target host is received to see whether the port is open or closed. In other words does not make a full connection, which reduces the chance of being seen on a target log file.
Scan specific ports and port ranges (-p) :
nmap -sS 22.214.171.124 -p 22,80,50-500
the above command scans the target host for ports 25, 80 and the range between 50 and 500.
OS detection (-O):
nmap -sS 126.96.36.199 -O
the -O option displays the Operating System and its version running on target system. This may not be accurate and may sometimes fail to identify the target OS. But most of the time you’ll end up being lucky…trust me…!
Detect the version of running services (-sV):
nmap -sV 188.8.131.52 -p 25
Starting Nmap 4.03 ( http://www.insecure.org/nmap/ ) at 2008-01-04 18:56 MVT
Interesting ports on linuxbox (184.108.40.206):
PORT STATE SERVICE VERSION
25/tcp open smtp Sendmail 8.13.7/8.13.7
Service Info: Host: linuxbox; OS: Unix
Nmap finished: 1 IP address (1 host up) scanned in 0.070 seconds
It is clear from above that the target system is running sendmail 8.13.7 for its SMTP engine and that the target system is a UNIX based system.
You may also use the -A switch to request Nmap to check for OS version as well as Services version which is easier. There are many other options such as -D (decoy), -sU (UDP scan), etc; not specified in this tutorial that might be useful to you. Please check the nmap documentation and evolve you knowledge on Nmap.
This HOWTO shows you how to take a completely new hard disk and encrypt its entire contents using dm-crypt and LUKS. Actually, it’s the partitions that are encrypted, not the disk itself (details below). So if you wish, you can make multiple partitions with different passphrases, or some not encrypted. With a bit of work, you can adapt these instructions to make an encrypted partition on an existing disk, possibly with some unencrypted partitions on the same disk.
dm-crypt asks for a passphrase before you can mount the disk. This provides good protection against your PC getting stolen – once they reboot your PC, the thieves have lost access to your data. Throughout, I will use the ‘cryptsetup’ interface to dm-crypt.
What is LUKS? See http://luks.endorphin.org/about. In simple terms, it’s better encryption, but more importantly to the end user, it allows you to change the password for your disk, without requiring a very slow re-encode of the whole disk. You also have the option of having several different passwords for the same data.
Note : if you want your encryption to defeat a full cryptoanalytic attack, not just casual snooping, you need to fill the disk with high quality random data. Badblocks below justs uses ‘libc’ random(), but is fast (your limitation will be disk speed, not CPU speed). /dev/urandom is better (takes about 5 minutes per gigabyte on my system), /dev/random is best (takes about 1 year per gigabyte on my system, much too slow!).
Step 0: Get the right cryptsetup
You need the version of cryptsetup with luks enabled, you can get it at http://luks.endorphin.org/dm-crypt. To test whether it’s installed, try:
# cryptsetup –help
If you see a help page including details like ‘luksFormat’, then you have the right version already.
Step1a : (Optional) Check the hard disk for errors (side effect, fill it with random data).
It’s probably a good idea to check your entire disk for errors before you start. Not only is this good practise, but modern hard disks contain a few ‘spare’ sectors, and if they detect errors in reading, they can silently replace the bad sector with a backup sector (this is invisible to the OS). So writing and reading the entire disk before you start should allow this to happen.
You need to know what device your new disk is attached to. For PATA disks (parallel ATA) on Linux, they’ll probably be /dev/hda, /dev/hdb and so on. For SATA, SCSI or USB attached disks, they’ll probably be /dev/sda, /dev/sdb, /dev/sdc and so on. I am attaching a USB disk, I already have 2 SATA disks so this disk seems to appear under /dev/sdc. Make sure you find out, and adapt the below commands as necessary, or you may overwrite your existing data!
It’s good to fill an encrypted disk with initial random data. This makes breaking the passphrase so much harder. The below method is sufficient for a casual attack but is not ‘random enough’ to defeat sophisticated cryptographers. If you need that, use the ‘/dev/urandom’ method below or read a good book on cryptography and random numbers!
I recommend the disk check and the fill with random data be done at the same time. Read the man page for more details on this command:
# /sbin/badblocks -c 10240 -s -w -t random -v /dev/sdc
(wait several hours…)
Checking for bad blocks in read-write mode
From block 0 to 295360984
Reading and comparing: done
Pass completed, 0 bad blocks found.
This will take some time, on my USB-attached 300Gb disk it took around 8 hours. Phase 1 will write random data to the disk, phase 2 will read it back and verify it.
Step 1b (Optional) Fill the disk with random data
If you didn’t do step 1a, do step 1b. This will take a long time (around 5 minutes per gigabyte on my system), because generating good quality random data is very CPU intensive. Method 1a has an easy progress indicator, while “dd” only shows its progress when a USR1 signal is sent to it (“kill -USR1 `pidof dd`”). However, this method is ‘more random’ (and more secure) than the primitive random number generator included in ‘badblocks’, above.
# dd if=/dev/urandom of=/dev/sdc
(wait several hours…)
Step 2 : Partition the disk
Remember, the data on a hard disk consists of (1) a partition table (2) one or more partitions.
The way dm-crypt works is, you mount an encrypted partition. So we won’t encrypt the whole hard disk, rather we’ll create a partition table (unencrypted) as usual, then create one or more partitions on the disk, as usual, except the partition(s) can be encrypted if we choose.
So, we partition the hard disk. In my case, I am partitioning my entire 300Gb hard disk as a single partition.
# /sbin/fdisk /dev/sdc
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won’t be recoverable.
The number of cylinders for this disk is set to 36481.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Command (m for help): p
Disk /dev/sdc: 300.0 GB, 300069052416 bytes
255 heads, 63 sectors/track, 36481 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
Command (m for help): n
p primary partition (1-4)
Partition number (1-4): 1
First cylinder (1-36481, default 1): 1
Last cylinder or +size or +sizeM or +sizeK (1-36481, default 36481): (enter)
Using default value 36481
Command (m for help): p
Disk /dev/sdc: 300.0 GB, 300069052416 bytes
255 heads, 63 sectors/track, 36481 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 36481 293033601 83 Linux
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Step 3 : Create mapping between logical and physical partitions
dm-crypt works by transparently translating (in the kernel) between a physical on-disk partition (which is encrypted) and a logical partition which you can then mount and use as normal. This step takes no time and writes no data, it just establishes the mapping for future use.
The physical (encrypted) partition will be /dev/something
The logical (unencrypted) partition will be /dev/mapper/something2
I prefer to keep the names the same, so something=something2. That makes things easier to remember.
# cryptsetup –verbose –verify-passphrase luksFormat /dev/sdc1
This will overwrite data on /dev/sdc1 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: (enter your passphrase, and write it down somewhere!)
Verify passphrase: (repeat passphrase)
# cryptsetup luksOpen /dev/sdc1 sdc1
Enter LUKS passphrase:
If all is well, you now have a special file called /dev/mapper/sdc1. This is what you will mount.
# ls -l /dev/mapper/
crw——- 1 root root 10, 63 Jul 16 01:34 control
brw-r—– 1 root root 253, 0 Jul 16 01:52 sdc1
Step 4 : Create a filesystem on the logical partition
This is just like making a normal filesystem, just point ‘mkfs’ at the logical partition. Use your favourite options, filesystem type etc (I use ext3) or just copy my options. As always, remember to change ‘sdc1’ as appropriate.
# /sbin/mkfs.ext3 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/sdc1
(wait several minutes…)
mke2fs 1.35 (28-Feb-2004)
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
36634624 inodes, 73258400 blocks
732584 blocks (1.00%) reserved for the super user
First data block=0
2236 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Step 5 : Mount the Filesystem
This is just like a normal mount, except you use the logical (/dev/mapper) device. First make a mount point if necessary. In my case I am using /home4
# mkdir /home4
# mount /dev/mapper/sdc1 /home4
# df -H
Filesystem Size Used Avail Use% Mounted on
/dev/hda3 11G 5.2G 4.2G 56% /
/dev/hda1 510M 63M 395M 14% /boot
/dev/hda2 11G 3.5G 5.9G 37% /usr
none 797M 0 797M 0% /dev/shm
/dev/mapper/sdc1 296G 34M 294G 1% /home4
Hoorah! Now just use /home4(or whatever) as normal. In my case, I now have another 300Gb to play with It may be slower than a normal disk, due to the CPU time required to encrypt/decrypt. If you wish, use /sbin/hdparm to benchmark. However my benchmarks on an AMD Athlon 3200 indicate no great difference between an encrypted and a normal unencrypted partition.
Step 6: Mounting and unmounting in future
This is a simple procedure. You may be even able to edit your /etc/rc.local script to prompt for a password and mount your encrypted partition at boot.
# cryptsetup luksOpen /dev/sdc1 sdc1
Enter LUKS passphrase: (enter passphrase)
key slot 0 unlocked.
# mount /dev/mapper/sdc1 /home4
# umount /home4
# cryptsetup luksClose sdc1
To add an additional password, so you can unlock your partition with a choice of different passwords (you can do this with the encrypted partition mounted, if you wish):
#cryptsetup luksAddKey /dev/sdc1
Enter any LUKS passphrase: (enter an existing password for this partition)
key slot 0 unlocked.
Enter new passphrase for key slot: (enter the extra password)
To delete an existing password (but don’t delete the last one, your data will be lost forever, you will be warned if you try this), you need to know which slot the password is in. The first password goes in slot 0, any additional passwords go in slot 1, 2 etc. You can do this with the encrypted partition mounted, if you wish. So to delete the very first password you used, use:
#cryptsetup luksDelKey /dev/sdc1 0
To change the password, first add an additional password then delete the original password.
You use a “hardening program” to try to make your system as secure as possible, from the ground up. Generally, you deactivate unnecessary services and better the configurations of the ones you leave enabled. This is wildly effective, as it can eliminate many of the vulnerabilities that are common on Linux/Unix platforms. This article presents a walkthrough of Bastille Linux, a popular hardening program for Red Hat and Mandrake, available for free from Jon Lasser, Pete Watkins, myself, and the rest of the Bastille Linux project. This walkthrough won’t be the kind of “paranoid” setup that I enjoy most, as that could remove too much functionality for the average reader. Don’t worry – I’ll explain what we’ll break in each setting, how we’ll break it, and how you can fix it. But first, a shameless plug: I’ll let you know about the cool features in the newest Bastille version, which we’ve just released.
Cool Features in Bastille Linux 1.1:
With all that said, please be assured that development is continuing. We’re implementing even more cool functionality and we’re all quite sure that Bastille is, and will continue to be, one of the most full-featured hardening programs out! Got a suggestion? E-mail me at firstname.lastname@example.org. With that said, let’s get to the walkthrough!
Starting The Walkthrough:
At the time of this writing, Bastille 1.1.0 has been released. It might be a little rough around the edges, but if something doesn’t work as planned, it can be easily undone or we can release a quick fix. I’m recommending this version specifically because the new architecture is much more featureful. Let’s download, install and run Bastille on an x86-based Red Hat 6.x box. First, switch to console mode. While Bastille uses a GUI-like (curses-based) Text User Interface, it’s still a console tool that runs best on a standard size 80×25 screen.
# cd /root
Download Bastille From http://downloads.sourceforge.net/bastille-linux/Bastille-3.0.9.tar.bz2?modtime=1145340334&big_mirror=0 and place it in your root folder, and un-archive it.
# cd /root/Bastille
Bastille starts with the four most powerful steps you can take to secure a Linux/Unix box:
Let’s step through these…
Bastille starts by offering to configure a firewall. While this is not all that is required to secure a machine, firewalls can be great start. They function to block network traffic from hitting your machine’s network daemons. Why not just secure the daemons or deactivate them? Actually, we’ll take all three of these actions. Why not just do one or the other? The answer is a basic tenet of operating system security: Defense in Depth.
Defense In Depth
Protect each service or possible vulnerability through multiple means, so that if one fails, the remaining methods keep your machine from being compromised.
To keep this article from getting too deep too fast, we’ll skip firewalling for now. Bastille has very good explanations in the IPCHAINS module – further, the default answers should be fairly safe. Unfortunately, this module is long enough to necessitate its own walkthrough. Look for a future article, Real Soon Now on this topic.
Q: Would you like to run the ipchains script? [N]
(Module: Patch Download)
Bastille now tells us about downloading new patches. This is VERY important. Bastille can minimize damage from vulnerable services through preventive measures, but it really is most effective to patch the security holes in the first place! Most operating systems (save OpenBSD) seem to release with vulnerable programs, some of which can be abused to gain root on your system. If you’re still not patching, please remember the remote vulnerability present in Red Hat 6.0’s BIND version… This step, however, is best done manually…
Q: Would you like to download and install updated rpms?
(Module: File Permissions)
Now we’ll audit file permissions. If you’re an advanced user, you may use the general permissions audit. This audit, adapted from a SANS document, restricts permissions on many binaries. Most people should choose N here.
Q: Would you like to set more restrictive permissions on the administrative utilities? [N]
Now we get to that third “most powerful action” quoted from above: the SUID Audit. Bastille lets us strip the SUID bit on about half of the SUID programs on a Red Hat 6.x or Mandrake system. Since this is the non-paranoid run, we won’t disable all of them…
We’ll leave the SUID bit on mount/umount, so that ordinary users can still mount floppies and cdroms.
Q: Would you like to disable suid status for mount/umount?
We’ll also leave ping and traceroute active, so ordinary users can test network connectivity. These are really not needed, but I am attempting to be less paranoid, in the name of user convenience.
Q: Would you like to disable suid status for ping?
We’ll strip the SUID bit from dump and restore, which are used for system backups. Root can take care of system backups.
Q: Would you like to disable SUID status for dump and restore?
We’ll also rip SUID status off of cardctl, which is used to configure PCMCIA services – you can answer N here if you’re running a notebook.
Q: Would you like to disable SUID status for cardctl?
We’ll also rip SUID status off of at, because it has had a rich history of security problems. You can achieve all the same functionality with cron, so this is safe.
Q: Would you like to disable SUID status for at?
We can safely tear SUID off of dos (dosemu). Dosemu is a DOS emulator for Linux and, as such, is very open to manipulation by the user. It also is used by few users – feel free to re-enable suid if you’re planning on making this available to many users.
Q: Would you like to disable SUID status for DOSEMU?
It is also very safe to remove the SUID bit from the news (UseNet) server control utilities, inndstart and startinnfeed. Most people reading this article aren’t running a news server on their machines… Even if they were, only root should be starting the news server! Ordinary users can read news without needing to be able to start a news server, especially since most people read UseNet via their ISP’s news server.
Q: Would you like to disable SUID status for news server tools?
We’ll leave the SUID bit on the printing utilities, though you should disable these if your machine won’t be used for printing.
Q: Would you like to disable SUID status for printing utilities?
Now, we get to one of my favorite topics, the Berkeley r-tools, like rcp, rlogin and rsh. These harbingers of doom use IP addresses for authentication, which unfortunately is not a suitable method of authentication. Trust me here, turn these the heck off!
Q: Would you like to disable SUID status for the r-tools?
We’ll slip back to permissive mode now, and leave SUID on usernetctl. This utility is used by ordinary users to activate and deactivate network interfaces, like their dial-up modems. Feel free to leave this on…
Q: Would you like to disable SUID status for usernetctl?
Q: Would you like to disable SUID status for traceroute?A: N
Now, I promise there aren’t so many questions in most of the other modules!
Module: Account Security
Bastille now moves to Account Security, which is not the last of the four “most powerful steps” that I outlined above. Don’t panic! We’ll come back to that one… Often a system cracker starts by stealing one of your user’s accounts or by compromising a non-user account. The AccountSecurity module enforces some Best Practices and creates a few tricks, as we’ll show below.
We’ll create a second superuser account. You should use this for root activities and leave the root account untouched.
Q: Would you like to set up a second UID 0 account?
Bastille will now request permission to disable the Berkeley r-tools: rsh, rlogin, rcp by making PAM modifications, commenting out lines in inetd.conf, and removing all permissions on these binaries.
Q: May we take strong steps to disallow the dangerous r-protocols? [Y]
We’ll now elect to enforce password aging, to freeze unused accounts before they can be used to compromise your system.
Q: Would you like to enforce password aging? [Y]
If you haven’t created an ordinary user account, you should let Bastille do this for you. Otherwise, skip it like so:
Q: Would you like to create a non-root user account? [N]
We’ll restrict most users from using cron – it represents a double risk: first, it runs as root and might be open to compromise. Second, an attacker can use cron to hide commands and run them outside of the interactive sessions that you’d be able to monitor easily.
Q: Would you like to restrict the use of cron to administrative accounts? [Y]
We’ll also go ahead, in the future, and assign a restricted/useless shell, like /bin/false, to all non-user accounts.
Module: Boot Security
Interestingly enough, in Red Hat 6.0, anyone who can get to a LILO prompt can have root on your system! Try this at the LILO prompt: type “linux single”. You’ll find yourself with a nice root shell! If we deactivate that, you can still type at the LILO prompt: linux init=/bin/bash. We can do something about this.
Q: Would you like to password-protect the LILO prompt? [N]
Q: Enter LILO password, please. 
A: put-in-your-own-password-please-or-you’ve-done-something really-dumb
This solution actually prevents both of the exploits above, as it protects the LILO prompt. We can protect this prompt further by not giving an attacker any chance to even try a password…
Q: Would you like to reduce the LILO delay time to zero? [N]
We can write this lilo configuration to our hard drive or to a pre-made boot floppy, or both. Supposing that we boot from your hard drive only:
Q: Do you ever boot Linux from the hard drive? [Y]
Q: Would you like to write the LILO changes to a boot floppy? [N]
We could disable CTRL-ALT-DEL rebooting, but this doesn’t always make sense.
Q: Would you like to disable CTRL-ALT-DELETE rebooting? [N]
We can take one final step to prevent the “LILO: linux single” root-grab. Remember: Defense in Depth!
Q: Would you like to password protect single-user mode? [Y]
OK, back to the fourth of the “four most powerful steps.” Our last “powerful” step, restricting and deactivating unnecessary services, follows from another basic tenet of system security: Minimalism.
Since crackers may discover an exploitable vulnerability in any service running with privilege, minimize both the number of these services and their levels of privilege.
This principal will save your butt over and over. A Red Hat 6.0 box running with “Everything” installed and every service active can be rooted remotely rather easily through, among other things, its Name Server. If you take the five minutes to turn this off, you win! If you had to leave it on, but you lower its level of privilege by setting it to run as an ordinary user, you win again. Otherwise, you can be rooted by the least experienced script kiddie.
We’ll start the process of restricting unnecessary services by changing /etc/inetd.conf and the TCP Wrappers /etc/hosts.allow file. We’ll disable telnet, ftp, pop, imap, rsh, rlogin, and talk. Pop and imap are mail protocols that should be disallowed unless you really do use them. Telnet, rlogin and rsh are all horribly insecure and can be replaced by ssh. Often, rcp and ftp can be replaced by the much safer scp. We remove talk simply because we don’t need it.
Q: Would you like to modify inetd.conf and /etc/hosts.allow to optimize use of Wrappers? [Y]
You can turn these back on, or allow them from required systems, by editing the /etc/hosts.allow file. Try: man hosts_access. Moving on, we’ll choose to leave ssh open to the entire Internet, for now.
Q: Would you like to set sshd to accept connections only from a small list of IP addresses. [N]
Finally, we’ll choose to add “Authorized Use Only” banners to the system. These are often required to successfully prosecute system crackers.
Q: Would you like to make “Authorized Use” banners? [Y]
Following the principle of Minimalism, we can now set permissions to only allow root to use the compiler. If you need users to run this, please don’t choose Y here.
Q: Would you like to disable the compiler? [N]
Sidetracking from the “minimalism” stuff, we make some modifications that should make it difficult for any one user, including the “nobody”, “web” or “ftp” users, to abuse system resources to cause a Denial of Service (DoS) attack.
Q: Would you like to put limits on system resource usage? [Y]
Q: Should we restrict console access to a small group of user accounts? [N]
We’ll add some additional logging to the system, creating special logs for kernel messages and severe error messages and, furthermore, logging important information to two virtual TTY’s. After we’re done, you’ll use – and – to view these and – to get back to an X server.
Q: Would you like to add additional logging? [Y]
Unless you have a remote logging host, we’ll answer the next question like so:
Q: Do you have a remote logging host? [N]
Process accounting logs every process as it starts. If you’ve got the disk space and CPU time to spare, or are very paranoid, this can be very useful. Most people shouldn’t touch this.
Q: Would you like to set up process accounting? [N]
We now get directly back to our Minimalism-motivated process. We’ll turn off every system daemon that you don’t need. In this walkthrough, we turn most everything off. You can turn it back on with the command chkconfig on.
Q: Would you like to disable apmd? [Y]
Q: Would you like to deactivate NFS and Samba? [Y]
Q: Would you like to disable atd? [Y]
Q: Would you like to disable PCMCIA services? [Y]
Q: Would you like to disable the DHCP daemon? [Y]
Q: Would you like to disable GPM? [Y]
Q: Would you like to disable the news server daemon? [Y]
Q: Would you like to deactivate the routing daemons? [Y]
Q: Would you like to deactivate NIS server and client programs? [Y]
Q: Would you like to disable SNMPD? [Y]
Continuing to follow the principle of Minimalism, we can now deactivate sendmail’s “listen mode.” It will still be available to send mail off the system, but won’t receive any from the network. If you need to receive mail via sendmail, choose Y:
Q: Do you want to leave sendmail running in daemon mode? [Y]
To disable automated sendmail altogether, we’d choose N for the next question.
Q: Would you like to run sendmail via cron to process the queue? [N]
Finally, we’ll disable some sendmail commands that are commonly used to gain information about your system for cracking or spamming.
Q: Would you like to disable the VRFY and EXPN sendmail commands? [Y]
You should install Secure Shell (ssh) on every system that needs remote access, though you may want to do it manually.
Q: Would you like to download and install ssh? [N]
You might notice a strange practice in the remaining modules: we tighten services that we turn off. We recommend you do this because you never known when you might have to turn them back on. Paranoid, yes, but from experience, a sound practice.
We secure DNS initially by running it as an ordinary user and restricting (chroot-ing) it to a small subset of the filesystem. This turns the recent BIND (DNS) exploit from a root-grab into DNS server Denial of Service (DoS). Actually, we (and the guys at SANS) implemented and suggested this months before the exploit was found.
Q: Would you like to chroot named and set it to run as a non-root user? [N]
Q:Would you like to deactivate named, at least for now? [Y]
You’ll have to get used to two small changes in the way your admin your DNS server when you do this – read the Bastille explanations carefully.
Unless you’ll be using your web server immediately, we’ll turn it off for now. Reactivate it later with chkconfig httpd on.
Q: Would you like to deactivate the Apache web server? [Y]
If you only need the webserver to test web pages that you’re working on locally, we can bind it to a your local interface. We could also bind it to only one interface (like your ethernet card, but not your PPP link.) I assume here that your web server must be viewable by the entire internet.
Q: Would you like to bind the web server to listen only to the localhost? [N]
Q: Would you like to bind the web server to a particular interface? [N]
We have more choices than just deactivating Apache. While Apache has some nice features, we’d prefer to disable features we aren’t directly using. Apache can follow symbolic links, so that if one of your users makes a link from his web directory to /, Apache can show any user-viewable file to the entire Internet! We’ll turn this off:
Q: Would you like to deactivate the following of symbolic links? [Y]
Server side includes aren’t used by most casual users. They can be rather dangerous.
Q: Would you like to deactivate server-side includes? [Y]
CGI scripts incredibly useful on servers – simultaneously, badly written CGI scripts represent one of the most common methods of system compromise today. Decide carefully: will you be writing, downloading or buying CGI scripts? Many conscious sites run them on only some servers and then only after auditing each CGI script for problems.
Q: Would you like to disable CGI scripts, at least for now? [Y]
Lastly, we think about indices. In the absence of a index.html file, Apache will list all files in the current directory. These aren’t as bad as symbolic links, since they don’t enable an attacker to see files outside the web directories.
Q: Would you like to disable indexes? [N]
If your box isn’t being used to print, we can disable the printing daemon and strip SUID from lpr and lprm, like so:
Q: Would you like to disable printing? [N]
Last module! Anybody tired yet? We now can prune back the access of the FTP daemon, wu-ftpd. From a security perspective, FTP is a very problematic protocol. Further, wu-ftpd has had a number of security alerts lately. Most security-conscious people try to avoid running an ftpd like the plague and you might want to follow their example. Even if you can, let’s prune this daemon.
Of all possible configurations, the worst is one that allows anonymous upload. Luckily, this is not the default configuration! Still, Red Hat’s default configuration allows user/password access as well as anonymous download. You can deactivate one or both of these. Here, we deactivate only user ftp access:
Q: Would you like to disable user privileges on the FTP daemon? [N]
Q: Would you like to disable anonymous download? [N]
OK, that’s it. We’ve made our choices in the front end, which should now create a configuration file. Let’s implement these choices like so:
( Exit from the Credits screen by pressing Tab )
Your changes should now be implemented. You’ll find your machine to be slightly less functional, but only in ways that you chose. You’ll find backup copies of every configuration file changed in /root/Bastille/undo/backup. Reboot your machine and notice the changes. An attacker will find far fewer avenues of attack against your machine, depending on what options you picked.
Jay Beale is the Lead Developer of the Bastille Linux Project (http://www.bastille-linux.org). He is the author of several articles on Linux/Un*x security, along with the upcoming book “Securing Linux the Bastille Way,” to be published by Addison Wesley. At his day job, Jay is a security admin working on Solaris and Linux boxes.
- To seach for a application
Yum will search all your enabled repos and tell you where you can obtain the package from
yum search application_name
- Yum can list all available packages from your enabled repos and tell you where you can obtain the package from:
yum list available
- To find out more info about some package
yum info application_name
- Installing applications
Inastalling is as easy as
yum install application_name
- Listing rpms
yum can list installed rpms for you from the repos you have enabled
yum list extras
- Removing rpms
Yum can remove a application and the dependenciesit installed with tat application. it will not remove depenencies if another application installed needs them.
yum remove application_name
- Updating the system
Yum can update the system for you with out user interact if you want it to.
- Not sure if you have upates?
- Local install
downloaded a rpm and cannot install it with rpm because of dependencies?
yum localinstall /path/to/the/rpm
On Ubuntu: sudo apt-get install mencoder
On Fedora: yum install mencoder
mencoder infile.wmv -ofps 23.976 -ovc lavc -oac copy -o outfile.avi
Sometimes simple answers to problems can be a pain in the rear to find, this is one of them.
A step by step guide:
1 – open my computer
2 – right click the cd drive and open properties from the menu
3 – in the proprties popup click the autoplay tab
4 – select Blank CD from the pulldown menu
5 – in actions select the “prompt me each time to choose an action” dot
6 – hit “OK”
Many users (including system administrators) leave their logged in Linux shell open and leave their desk. There is no lock screen option if you are running your Linux box in pure CLI mode so any sneaker can access your documents, the situation is worse if a root user leaves his session as the sneaker can poke their nose into the whole system and do whatever they want.
Luckily there is an environment variable in BASH1 called TMOUT by using you can instruct the shell to exit (or logout) if it is idle for the given seconds. Note the shell will only exit if it is idle that is no actively running program like vi editor session. Use the following in your ~/.bash_profile file to make this permanent.
This is will make the shell to exit automatically if left idle for 300 seconds (5 minutes)
What will you do when you leave your X Window desktop on a Linux box?
obviously, lock it to protect your precious data. But this is not a full protection yet, why? because one can still press <Ctrl> + <Alt> + BackSpace key to kill your entire session. If you have any unsaved documents they all are gone.
Open /etc/X11/xorg.conf file in your favorite text editor and look for
Section “ServerFlags” line. If one already exists add the following line between start and end of that section.
Option "DontZap" "true"
If the section does not exists at all, append the following lines to your xorg.conf file
Section "ServerFlags" Option "DontZap" "true" EndSection
You can also add the following option to disable switching to full text mode (VT).
Option "DontVTSwitch" "true"
BE WARNED! this will disable both killing your X session forcefully and switching to text mode. If some application got hung and your X session is not responding you will have to restart your machine.