I wander'd lonely into the cloud
That floats on high with sales and spiels,
When all at once I saw a crowd,
A host of golden server deals,
In the racks and beneath the fans,
Placing hard-earned money in my hands.
To find the true word's worth from the preceding stanza, you'll have to journey into the world of Virtual Private Server (VPS) hosting. You'll soon discover that by choosing VPS hosting, it'll cost you about a dollar a day for a dedicated Windows or Linux server. Sound impossible? It isn't. Using a clever server configuration, brought to you by Parallels, hosting providers make dedicated servers available to you at about a tenth of the cost of a dedicated hardware system.
Virtual Private Servers
A VPS is a virtual machine hosted remotely for which you pay a monthly or yearly fee. Typical offerings include a guaranteed numbers or amounts of memory, disk space, CPU, IP addresses and network bandwidth. The system is always on and running just as if it were a physical system in your own data center. Most hosting providers supply you with your own control panel with which you can configure your system and services. Once configured, the VPS acts like any other racked system to which you have full root or administrator access.
Each VPS is a container similar to a BSD jail where the running kernel and all standard files, including libraries, are common to all virtual machine instances. Therefore, your VPS resides on a common host with other similar VPSs. In other words, if your VPS runs Microsoft Windows 2003 Server, all systems common to that host also run Windows 2003 Server. Similarly, a VPS host system running a Linux kernel hosts only VPSs running Linux.
VPS Features
Security
Guaranteed Bandwidth
Excellent Performance
24x7 Support
99.9 percent + Uptimes
Easy Setup and Operation
Isolation provides the security for VPSs residing on a common host. Your VPS instance shares some files with all other instances but configurations, network settings, users, applications and personal files remain isolated to your instance. Guaranteed network bandwidth links to your particular hosting package you've selected but optionally upgradeable to higher levels. Ask about, or look for, dynamic (burstable) bandwidth and memory values when comparing services. The Parallels' container configuration optimizes performance near native levels for Windows and Linux-based operating systems.
Your monthly fee also covers the cost of 24x7 support for your VPSs, the hardware on which they reside and your control panel applications. Hosting providers have found that the customer service value drives sales and customer loyalty. Providers know that guaranteed uptimes don't hurt loyalty either. Highly available hardware setups and automated failover configurations mean near 100 percent uptimes for your VPSs.
Setup and configuration couldn't be simpler with the CPanel or Plesk applications that all Parallels-based hosts offer to their customers. After initial sign-up, your new VPS is only minutes away from availability and once setup, remote access through SSH (Linux) or Windows Terminal Services connect you into your new system.
Lucky you — you have dozens of choices when it comes to selecting a VPS provider. Open your favorite Internet browser and enter "virtual private server hosting" into the search field. Today, you'll see 13,200,000 results. I don't believe that all of those hits represent hosting companies, offerings or legitimate businesses, but you'll find what you're looking for in the first 50. Numerous reputable providers pop up in those first few results and you're sure to find one that's right for you.
When making your provider selection, look at those bulleted points listed earlier. Call their number to ask any questions you might have though most of the answers exist on line as FAQs. Most hosting companies have automated sign-up available on their Web sites, in which case, you might need no human interaction at all.
Just think, you'll have no more long provisioning times to haunt your dreams, no "hurry up and wait" deployment scenarios to plague your productivity and no high-dollar hosting fees to deplete your bank account. If you have an idea this morning, by this afternoon it's an online reality. Virtual Private Servers give you something to think about when on your couch you lie, filling your heart with pleasure-scenes of saved dollars dancing by.
Ken Hess is a freelance writer who writes on a variety of open source topics including Linux, databases, and virtualization. You may reach him through his web site at http://www.kenhess.com.
Wednesday, September 16, 2009
Kernel Module writing with examples
Kernel Module writing with examples
introduction :
Hello all , as we all know linux is a BIG do it your self program
it allow you to do EVERY THING on your system
all what you have to do is to learn how to use it's capabilities
WE are going to deal with kernel by modules right now , but what is module ?
it's like a small kernel application (not user application) that can be loaded into kernel at run time whenever you need it by insmod , modeprobe
that is a good advantage actually , you don't need to compile kernel statically every time you need a module and that will cause you to reboot your system , imagine how could this be a west of time
but why that ([color="#0000FF"]kernel application[/color]) what is the difference between it and user application
[color="#FF0000"]user application:[/color][/i]
as we all know user application (ordinary programs) start execution from [color="#0000FF"]main()[/color] function
continue execution of this function until it satisfy it's job then exit
you can use standard libraries and user libraries
[color="#0000FF"]kernel applications[/color] : modules
piece of code that will be compiled against kernel objects producing a kernel module
that can be linked dynamically and removed dynamically at run time without a need to reboot
kernel modules doesn't start execution like ordinary programs from main()
However , it starts execution from function we call (initialization function) which you will code
module end when you request it to be removed but before kernel unload it . it will call a function we call (cleaning up function) and clean up all it's job.
calling this functions will depend on you because you will specify which function is the init and which function is the cleanup (later);
when a module is loaded kernel get the address of the init function and run it , then it hangs on the kernel until some application requires a symbol that this module exported ;
NOTE : if kernel is suspicious about module job (still hanging around with a file descriptor or what ever) it will not unload it until it finishes it's job .
unless you specified `MODULE_FORCE_UNLOAD` in your kernel configuration
modules doesn't hang in memory like ordinary applications might does . kernel handles it memory and kernel frees it's memory;
any fault at modules can cause a BIG something if you are not careful.....
SIGSEGV in ordinary app will cause a core dumb and exit
but in kernel it might be a disaster...
you can't use library function in modules (NO linking to libc or any other library)
modules are objects files . they only able to deal with internal kernel functions ("/proc/kallsyms")
which we can call SYSTEM CALLS .
system calls are defined in kernel which load the modules and resolve it's referencing
at insmod"ing time ;
in a kernel space you can do anything you want
you are dealing with kernel;
you MUST have a kernel source tree to be able to compile your module
you will NOT be able to do anything without a kernel source
a kernel module runs on kernel 2.6 will definitely not able to run on 2.4
a compiled module runs on 2.6.X might not run in 2.6.D
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++
[color="#0000FF"]your First kernel module :[/color]
get a shell and pick and editor and start typing :
after saving It
let's start explaining what is this
essential headers to make module able to load
+++++++++++++++++++++++
initialization :
+++++++++++++++++++++++
static int __init module_start(void);
this function will be passed to module_init why ? because module_init specify that this is the function should be called when module is loaded
which will point in module(object file) that this is the function should be called whenever this module is loaded
++++++++++++++++++++++
exiting: cleaning up
++++++++++++++++++++++
static void module_end(void);
will be passed to module_exit(); same as module_init() but it does the opposite it points to cleanup = exit function;
passing parameters :
this function allow you to pass parameters to the module at loading time by
insmod module.kp name="Bleh"
specify variablename=value
you can't pass a float point variable;
types:
also you can pass arrays
like
each value separated by (,)
but you will have to change it like
++++++++++++++
[color="#0000FF"]printk: your first kernel hacking[/color]
++++++++++++++
what the hell is printk ? where is f ? did the grinch stole it :@ what a bastard :@
no he didn't , I told you before that you can't use library function
printk is the kernel version of printf function which is a system call allow you to print format messages .it prints by priority by the way , and that is [color="#0000FF"]KERN_INFO[/color] is it's a priority every string is printed by this
information about module as you can see
no what is that make command ?
as I told you before modules compiled against several objects files in the kernel source tree
as an example : magicversion.o this object file contain information about the module
date , version , which kernel it was compiled on , etc
make -C |link source tree| enter that folder and uses it's object files
M=`pwd` this argument says that files in here should be compiled to objects
then against Linux objects the modul
moudles : tell the make command that output will be a module not an ordinary object file
how to load it then ?
or better :
modprobe module.ko
it's better because it solves the references by this module and catches any undefined symbol in kernel . if any it checks for it's standard moudles directory and load any depends required by insmod them
how to unload it then ?
how list running modules ?
files ?
cd /sys/module -> directory contain directories about the running modules
Examples :
Use it in a kernel application if you want , using seq_file
introduction :
Hello all , as we all know linux is a BIG do it your self program
it allow you to do EVERY THING on your system
all what you have to do is to learn how to use it's capabilities
WE are going to deal with kernel by modules right now , but what is module ?
it's like a small kernel application (not user application) that can be loaded into kernel at run time whenever you need it by insmod , modeprobe
that is a good advantage actually , you don't need to compile kernel statically every time you need a module and that will cause you to reboot your system , imagine how could this be a west of time
but why that ([color="#0000FF"]kernel application[/color]) what is the difference between it and user application
[color="#FF0000"]user application:[/color][/i]
as we all know user application (ordinary programs) start execution from [color="#0000FF"]main()[/color] function
continue execution of this function until it satisfy it's job then exit
you can use standard libraries and user libraries
[color="#0000FF"]kernel applications[/color] : modules
piece of code that will be compiled against kernel objects producing a kernel module
that can be linked dynamically and removed dynamically at run time without a need to reboot
kernel modules doesn't start execution like ordinary programs from main()
However , it starts execution from function we call (initialization function) which you will code
module end when you request it to be removed but before kernel unload it . it will call a function we call (cleaning up function) and clean up all it's job.
calling this functions will depend on you because you will specify which function is the init and which function is the cleanup (later);
when a module is loaded kernel get the address of the init function and run it , then it hangs on the kernel until some application requires a symbol that this module exported ;
NOTE : if kernel is suspicious about module job (still hanging around with a file descriptor or what ever) it will not unload it until it finishes it's job .
unless you specified `MODULE_FORCE_UNLOAD` in your kernel configuration
modules doesn't hang in memory like ordinary applications might does . kernel handles it memory and kernel frees it's memory;
any fault at modules can cause a BIG something if you are not careful.....
SIGSEGV in ordinary app will cause a core dumb and exit
but in kernel it might be a disaster...
you can't use library function in modules (NO linking to libc or any other library)
modules are objects files . they only able to deal with internal kernel functions ("/proc/kallsyms")
which we can call SYSTEM CALLS .
system calls are defined in kernel which load the modules and resolve it's referencing
at insmod"ing time ;
in a kernel space you can do anything you want
you are dealing with kernel;you MUST have a kernel source tree to be able to compile your module
you will NOT be able to do anything without a kernel source
a kernel module runs on kernel 2.6 will definitely not able to run on 2.4
a compiled module runs on 2.6.X might not run in 2.6.D
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++
[color="#0000FF"]your First kernel module :[/color]
get a shell and pick and editor and start typing :
Code: [Select]
#include <linux/init.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/stat.h>
static char *name = "Kernel Hacking first module\n";
module_param(name , charp , S_IRUGO | S_IWUSR);
static int __init module_start(void)
{
printk(KERN_INFO"Hello This IS a kernel module testing\n");
printk(KERN_INFO"Information : %s\n", name);
printk(KERN_INFO"Information Delevered\n");
return 0;
}
static void __exit module_end(void)
{
printk(KERN_INFO"\nEnd And\n\n");
printk(KERN_INFO"Every Thing Has a beginning has an end");
}
MODULE_LICENSE("GPL");
MODULE_AUTHOR("St0rM");
MODULE_DESCRIPTION("Something Nice we do in here");
module_init(module_start);
module_exit(module_end);after saving It
Quote
make -C /lib/modules/`uname -r`/build M=`pwd`
let's start explaining what is this
Code: [Select]
#include <linux/init.h>
#include <linux/module.h>essential headers to make module able to load
Quote
#include <linux/moduleparam.h> --> allow module to receive parameters while loadingparameters
#include <linux/stat.h> --> contain definition of permission flags like S_IRDWR by it you can specify which user can read/write/read&write on
+++++++++++++++++++++++
initialization :
+++++++++++++++++++++++
static int __init module_start(void);
this function will be passed to module_init why ? because module_init specify that this is the function should be called when module is loaded
which will point in module(object file) that this is the function should be called whenever this module is loaded
++++++++++++++++++++++
exiting: cleaning up
++++++++++++++++++++++
static void module_end(void);
will be passed to module_exit(); same as module_init() but it does the opposite it points to cleanup = exit function;
passing parameters :
Code: [Select]
module_param(name , charp , S_IRUGO | S_IWUSR);this function allow you to pass parameters to the module at loading time by
insmod module.kp name="Bleh"
specify variablename=value
Quote
module_param(variable name . variable type , permissions);
charp = character pointer ;
you can't pass a float point variable;
types:
Quote
char
charp = character pointer
int
long
short
ushort = unsigned shor
ulong = unsigned long
also you can pass arrays
like
Quote
insmode module.ko array=x,v,d,g
each value separated by (,)
but you will have to change it like
Code: [Select]
int x[5];
module_param_array(x , int , 5 , permissions)++++++++++++++
[color="#0000FF"]printk: your first kernel hacking[/color]
++++++++++++++
what the hell is printk ? where is f ? did the grinch stole it :@ what a bastard :@
no he didn't , I told you before that you can't use library function
printk is the kernel version of printf function which is a system call allow you to print format messages .it prints by priority by the way , and that is [color="#0000FF"]KERN_INFO[/color] is it's a priority every string is printed by this
Code: [Select]
MODULE_LICENSE("GPL");
MODULE_AUTHOR("St0rM");
MODULE_DESCRIPTION("Something Nice we do in here");information about module as you can see
no what is that make command ?
as I told you before modules compiled against several objects files in the kernel source tree
as an example : magicversion.o this object file contain information about the module
date , version , which kernel it was compiled on , etc
make -C |link source tree| enter that folder and uses it's object files
M=`pwd` this argument says that files in here should be compiled to objects
then against Linux objects the modul
moudles : tell the make command that output will be a module not an ordinary object file
how to load it then ?
Quote
insmod module.ko |arguments if any|
or better :
modprobe module.ko
it's better because it solves the references by this module and catches any undefined symbol in kernel . if any it checks for it's standard moudles directory and load any depends required by insmod them
how to unload it then ?
Quote
rmmod module.ko
how list running modules ?
Quote
lsmod
files ?
Quote
/proc/modules
cd /sys/module -> directory contain directories about the running modules
Examples :
Code: [Select]
root@St0rM-Man:~/Desktop/linux.programming/kernel/pipe# insmod pipe_char.ko major=100 minor=0
root@St0rM-Man:~/Desktop/linux.programming/kernel/pipe# mknode /dev/pipe_char c 100 0
-bash: mknode: command not found
root@St0rM-Man:~/Desktop/linux.programming/kernel/pipe# mknod /dev/pipe_char c 100 0
root@St0rM-Man:~/Desktop/linux.programming/kernel/pipe# echo "It's only after we have lost every thing that we are free to do anything" > /dev/pipe_char
root@St0rM-Man:~/Desktop/linux.programming/kernel/pipe# cat /dev/pipe_char
It's only after we have lost every thing that we are free to do anythingCode: [Select]
#include <linux/module.h>
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/moduleparam.h>
#include <linux/fs.h>
#include <linux/kdev_t.h>
#include <linux/stat.h>
#include <linux/types.h>
#include <linux/cdev.h>
#include <linux/sched.h>
#include <asm/uaccess.h>
#include <linux/completion.h>
static int major;
static int minor;
static dev_t device_node;
static char buffer[265];
module_param(major , int , S_IWUSR | S_IRUSR);
module_param(minor , int , S_IWUSR | S_IRUSR);
struct cdev device;
struct completion complete_task;
static int pipe_open(struct inode *node , struct file *filp)
{
/* No defice specification Will be Done */
return 0;
}
static int pipe_read(struct file *filp , char __user *buf , size_t size , loff_t *pos)
{
wait_for_completion(&complete_task);
if(copy_to_user(buf , buffer , strlen(buffer)) > 0)
return -1;
else
return strlen(buffer);
}
static int pipe_write(struct file *filp ,
const char __user *buf ,
size_t size ,
loff_t *pos)
{
int count = size;
if(count > 264)
count = 264;
if(copy_from_user(buffer , buf , count) > 0)
return -1;
complete(&complete_task);
return count;
}
static int pipe_release(struct inode *node , struct file *filp)
{
return 0;
}
struct file_operations fops =
{
.open = pipe_open ,
.read = pipe_read ,
.write = pipe_write ,
.release = pipe_release,
};
static int __init pipe_init(void)
{
int result;
if(major)
{
device_node = MKDEV(major , minor);
result = register_chrdev_region(device_node , 1 , "pipe");
}else
{
result = alloc_chrdev_region(&device_node , 1 , 1 , "pipe");
}
if(result == -1)
{
printk(KERN_INFO"Failed To Register Device Number\n\n");
return result;
}
printk(KERN_INFO
"Registred with major:minor %d:%d\n",
MAJOR(device_node) , MINOR(device_node));
cdev_init(&device , &fops);
device.owner = THIS_MODULE;
result = cdev_add(&device , device_node , 1);
if(result == -1)
{
printk(KERN_INFO"Failed To register Char device\n\n");
return result;
}
printk(KERN_INFO"Device Is live\n\n");
/* initialize Complete Structure */
init_completion(&complete_task);
return 0;
}
static void __exit pipe_exit(void)
{
unregister_chrdev_region(device_node , 1);
cdev_del(&device);
printk(KERN_INFO"Device Is Removed\n\n");
}
module_init(pipe_init);
module_exit(pipe_exit);Use it in a kernel application if you want , using seq_file
Code: [Select]
#include <linux/module.h>
#include <linux/init.h>
#include <linux/proc_fs.h>
#include <linux/stat.h>
#include <linux/stat.h>
#include <linux/slab.h>
#include <linux/seq_file.h>
#include <linux/errno.h>
/* itmes will be sequenced and sended to user interface using the lovely seq_file
* interface; items will be initialized ar initializing modules time
* any fauilr will result in whole module failur and unload immediatly
*/
/* items hold data */
static struct items
{
struct items *next;
char *buffer;
}*head , *cur;
/* open seqeunce proto type function */
static int open_seq(struct inode *inode , struct file *filp);
/*iterator prototypes */
static void *start_seq(struct seq_file *s , loff_t *pos);
static void *next_seq(struct seq_file *s , void *data , loff_t *pos);
static void stop_seq(struct seq_file *s , void *data );
static int show_seq(struct seq_file *s , void *data);
/* Mark eof */
static int eof = 0;
/* erasing list function */
static void erase(struct items *head);
/* Seq operations */
static struct seq_operations seq_ops = {
.start = start_seq,
.next = next_seq,
.stop = stop_seq,
.show = show_seq
};
/* File operations */
struct file_operations fops =
{
.owner = THIS_MODULE,
.open = open_seq ,
.read = seq_read,
.release = seq_release,
.llseek = seq_lseek
};
/* Module initializiation function definition */
static int __init proc_seq_init(void)
{
/* We need to allocate 5 items for items structure and fill buffers in them */
int i;
struct proc_dir_entry *proc_entry;
head = NULL;
cur = NULL;
for(i=0; i <= 5; i++)
{
if(head == NULL) /*first */
{
head = kmalloc(sizeof(struct items) , GFP_KERNEL);
head->buffer = kmalloc(50 *sizeof(char), GFP_KERNEL);
if( !head ||!head->buffer)
{
if(head)
{
erase(head);
printk(KERN_INFO"allocating memory error\n");
}
return -ENOMEM;
}
cur = head;
cur->next = NULL;
}else if(!cur->next) /* other */
{
cur->next = kmalloc(sizeof(struct items) , GFP_KERNEL);
cur = cur->next;
if(cur)
{
cur->buffer = kmalloc(50 *sizeof(char), GFP_KERNEL);
if(!cur->buffer)
{
erase(head); /* the only reason i did this cause
memory is not enough in this case
and i don't want somebody's system
to hang
*/
printk(KERN_INFO"allocating memory error\n");
return -ENOMEM;
}
cur->next = NULL;
}else
{
erase(head);
return -ENOMEM;
}
}
/* fill the buffer with information */
sprintf(cur->buffer , "Ok this is the %d time\n",i);
}
/* initializing items is done at this case we should now register our proc_file */
/*using low level creat_proc_enrty cause we don't want to have a read only proc
* we are not implementing ordinary proc file we are using seq_file proc technique */
proc_entry = create_proc_entry("linked_info" , S_IRUSR | S_IROTH , NULL /* parent */);
if(proc_entry)
proc_entry->proc_fops = &fops;
else
return -1;
printk(KERN_INFO"All seems to be fine\n\n");
return 0;
}
static void __exit proc_seq_clean(void)
{
/* erase list */
erase(head);
/* remove file */
remove_proc_entry("linked_info" , NULL);
}
module_init(proc_seq_init);
module_exit(proc_seq_clean);
/* open_seq definition */
static int open_seq(struct inode *inode , struct file *filp)
{
/* all we want to do is register sequnece operation with file */
eof = 0;
return seq_open(filp , &seq_ops);
}
/* iterator functions definitions */
static void *start_seq(struct seq_file *s , loff_t *pos)
{
/* actually it will do nothing accept updating position */
*pos += sizeof(struct items) +( 50 *sizeof(char));
if(head->next)
return head->next;
else
return NULL;
};
static void *next_seq(struct seq_file *s , void *data , loff_t *pos)
{
struct items *item;
/* update postion and move on sequence list */
item = (struct items*) data;
if(item->next)
{
return item->next;
}
else
return NULL;
}
static void stop_seq(struct seq_file *s , void *data )
{
;
}
static int show_seq(struct seq_file *s , void *data)
{
struct items *item;
int result;
item = (struct items *) data;
if(eof == 1)
{
return 0;
}
result = seq_printf( s , item->buffer );
if(item->next == NULL)
eof = 1;
return result;
}
/* erasing function definition */
static void erase(struct items *item)
{
struct items *temp;
if(!item)
return;
while(item)
{
temp=item->next;
kfree(item);
item = temp;
}
}
MODULE_LICENSE("Gpl");
MODULE_AUTHOR("Ahmed Mosatfa");
MODULE_DESCRIPTION("/proc file system module");
MODULE_VERSION("0.0.1");Tuesday, September 15, 2009
The Secure Shell (SSH)
The Secure Shell
(SSH)
To tackle the issue of remote login versus password security, a solution called Secure
Shell (SSH) was developed. SSH is a suite of network communication tools that are col-
lectively based on an open protocol/standard that is guided by the Internet Engineer-
ing Task Force (IETF). It allows users to connect to a remote server just as they would
using Telnet, rlogin, FTP, etc.—except that the session is 100 percent encrypted. Someone
using a packet sniffer merely sees encrypted traffic going by. Should they capture the
encrypted traffic, decrypting it could take a long time.
In this chapter, we’ll take a brief and general look at the cryptography concept. Then
we’ll examine the versions of SSH, where to get it, and how to install and configure it.
UNDERSTANDING PUBLIC KEY CRYPTOGRAPHY
A quick disclaimer is probably necessary before proceeding: “This chapter is by no means
an authority on the subject of cryptography and, as such, is not the definitive source for
cryptography matters.” What you will find here is a general discussion along with some
references to good books that approach the topic more thoroughly.
Secure Shell relies on a technology called public-key cryptography. It works similarly to a
safe deposit box at the bank: You need two keys to open the box, or at least multiple layers
of security/checks have to be crossed. In the case of public-key cryptography, you need
two mathematical keys: a public one and a private one. Your public key can be published
on a public web page, printed on a T-shirt, or posted on a billboard in the busiest part of
town. Anyone who asks for it can have a copy. On the other hand, your private key must
be protected to the best of your ability. It is this piece of information that makes the data
you want to encrypt truly secure. Every public key/private key combination is unique.
The actual process of encrypting data and sending it from one person to the next requires
several steps. We’ll use the popular Alice and Bob analogy, and go through the process one
step at a time as they both try to communicate in a secure manner with one another. Fig-
ures 21-1 through 21-5 illustrate an oversimplified version of the actual process
Looking at these steps, notice that at no point was the secret (private) key sent over
the network. Also note that once the data was encrypted with Bob’s public key and
signed with Alice’s private key, the only pair of keys that could decrypt and verify it
were Bob’s private key and Alice’s public key. Thus, if someone intercepted the data in
the middle of the transmission, they wouldn’t be able to decrypt the data without the
proper private keys.
To make things even more interesting, SSH regularly changes its session key. (This
is a randomly generated, symmetric key for encrypting the communication between the
SSH client and server. It is shared by the two parties in a secure manner during SSH con-
nection setup.) In this way, the data stream gets encrypted differently every few minutes.
Thus, even if someone happened to figure out the key for a transmission, that miracle
would be valid for only a few minutes until the keys changed again.
Key Characteristics
So what exactly is a key? Essentially, a key is a large number that has special math-
ematical properties. Whether someone can break an encryption scheme depends on
their ability to find out what the key is. Thus, the larger the key is, the harder it will be
to discover it.
56
Low-grade encryption has 56 bits. This means there are 2 possible keys. To give
32 48 56
you a sense of scale, 2 is equal to 4 billion, 2 is equal to 256 trillion, and 2 is equal
to 65,536 trillion. While this seems like a significant number of possibilities, it has been
demonstrated that a loose network of PCs dedicated to iterating through every pos-
sibility could conceivably break a low-grade encryption code in less than a month. In
1998, the Electronic Frontier Foundation (EFF) published designs for a (then) $250,000
computer capable of cracking 56-bit keys in a few seconds to demonstrate the need
for higher-grade encryption. If $250,000 seems like a lot of money to you, think of the
potential for credit card fraud if someone successfully used that computer for that
purpose!
For a key to be sufficiently difficult to break, experts suggest no fewer than 128 bits.
Because every extra bit effectively doubles the number of possibilities, 128 bits offers a
genuine challenge. And if you want to really make the encryption solid, a key size of 512
bits or higher is recommended. SSH can use up to 1024 bits to encrypt your data.
The tradeoff to using higher-bit encryption is that it requires more math-processing
power for the computer to churn through and validate a key. This takes time and, there-
fore, makes the authentication process a touch slower—but most people feel this tradeoff
is worthwhile.
Cryptography References
SSH supports a variety of encryption algorithms. Public-key encryption happens to be
the most interesting method of performing encryption from site to site and is arguably
the most secure. If you want to learn more about cryptography, here are some good
books and other resources to look into:
? PGP by Simson Garfinkel, et al. (O’Reilly and Associates, 1994)
? Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition by
Bruce Schneier (John Wiley & Sons, 1995)
? Cryptography and Network Security: Principles and Practice, Third Edition by Wil-
liam Stallings (Prentice Hall, 2002)
? http://tools.ietf.org/id/draft-ietf-secsh-connect-25.txt
? www.apps.ietf.org/rfc/rfc3766.html
The PGP book is specific to the PGP program, but it also contains a hefty amount of
history and an excellent collection of general cryptography tutorials. The Applied Cryp-
tography book might be a bit overwhelming to many, especially nonprogrammers, but it
successfully explains how actual cryptographic algorithms work. (This text is considered
a bible among cypherheads.) Finally, Cryptography and Network Security is heavier on
principles than on practice, but it’s useful if you’re interested in the theoretical aspects of
cryptography rather than the code itself.
UNDERSTANDING SSH VERSIONS AND DISTRIBUTIONS
The first version of SSH that was made available by DataFellows (now F-Secure) restricted
free use of SSH to noncommercial activities; commercial activities required that licenses
be purchased. But more significant than the cost of the package is the fact that the source
code to the package is completely open. This is important to cryptographic software,
for it allows peers to examine the source code and make sure there are no holes that
may allow hackers to break the security. (In other words, serious cryptographers do not
rely on security through obscurity.) Since the U.S. government has relaxed some of its
encryption laws, work on the OpenSSH project has increased, and it is a popular alterna-
tive to some of the commercial versions of the SSH protocol.
Because the SSH protocol has become an IETF standard, there are also other devel-
opers actively working on SSH clients for other operating systems. There are many
Microsoft Windows clients, Macintosh clients, and even a Palm client, in addition to the
standard UNIX clients. You can find the version of OpenSSH that we will be discussing
at www.openssh.org.
OpenSSH and OpenBSD
The OpenSSH project is being spearheaded by the OpenBSD project. OpenBSD is a ver-
sion of the Berkeley Software Distribution (BSD) operating system (another UNIX vari-
ant) that strives for the best security of any operating system available. A quick trip to
their web site (www.openbsd.org) shows that they have gone ten years with only two
remote exploits in their default installation. Unfortunately, this level of fanaticism on
security comes at the expense of not having the most whiz-bang-feature-rich tools avail-
able, since they require that anything added to their distribution gets audited for security
first. This has made OpenBSD a popular foundation for firewalls.
The core of the OpenSSH package is considered part of the OpenBSD project and, thus,
is simple and specific to the OpenBSD operating system. To make OpenSSH available to
other operating systems, a separate group exists to make OpenSSH portable whenever
new releases come out. Typically, this happens quickly after the original release.
(SSH)
To tackle the issue of remote login versus password security, a solution called Secure
Shell (SSH) was developed. SSH is a suite of network communication tools that are col-
lectively based on an open protocol/standard that is guided by the Internet Engineer-
ing Task Force (IETF). It allows users to connect to a remote server just as they would
using Telnet, rlogin, FTP, etc.—except that the session is 100 percent encrypted. Someone
using a packet sniffer merely sees encrypted traffic going by. Should they capture the
encrypted traffic, decrypting it could take a long time.
In this chapter, we’ll take a brief and general look at the cryptography concept. Then
we’ll examine the versions of SSH, where to get it, and how to install and configure it.
UNDERSTANDING PUBLIC KEY CRYPTOGRAPHY
A quick disclaimer is probably necessary before proceeding: “This chapter is by no means
an authority on the subject of cryptography and, as such, is not the definitive source for
cryptography matters.” What you will find here is a general discussion along with some
references to good books that approach the topic more thoroughly.
Secure Shell relies on a technology called public-key cryptography. It works similarly to a
safe deposit box at the bank: You need two keys to open the box, or at least multiple layers
of security/checks have to be crossed. In the case of public-key cryptography, you need
two mathematical keys: a public one and a private one. Your public key can be published
on a public web page, printed on a T-shirt, or posted on a billboard in the busiest part of
town. Anyone who asks for it can have a copy. On the other hand, your private key must
be protected to the best of your ability. It is this piece of information that makes the data
you want to encrypt truly secure. Every public key/private key combination is unique.
The actual process of encrypting data and sending it from one person to the next requires
several steps. We’ll use the popular Alice and Bob analogy, and go through the process one
step at a time as they both try to communicate in a secure manner with one another. Fig-
ures 21-1 through 21-5 illustrate an oversimplified version of the actual process
Looking at these steps, notice that at no point was the secret (private) key sent over
the network. Also note that once the data was encrypted with Bob’s public key and
signed with Alice’s private key, the only pair of keys that could decrypt and verify it
were Bob’s private key and Alice’s public key. Thus, if someone intercepted the data in
the middle of the transmission, they wouldn’t be able to decrypt the data without the
proper private keys.
To make things even more interesting, SSH regularly changes its session key. (This
is a randomly generated, symmetric key for encrypting the communication between the
SSH client and server. It is shared by the two parties in a secure manner during SSH con-
nection setup.) In this way, the data stream gets encrypted differently every few minutes.
Thus, even if someone happened to figure out the key for a transmission, that miracle
would be valid for only a few minutes until the keys changed again.
Key Characteristics
So what exactly is a key? Essentially, a key is a large number that has special math-
ematical properties. Whether someone can break an encryption scheme depends on
their ability to find out what the key is. Thus, the larger the key is, the harder it will be
to discover it.
56
Low-grade encryption has 56 bits. This means there are 2 possible keys. To give
32 48 56
you a sense of scale, 2 is equal to 4 billion, 2 is equal to 256 trillion, and 2 is equal
to 65,536 trillion. While this seems like a significant number of possibilities, it has been
demonstrated that a loose network of PCs dedicated to iterating through every pos-
sibility could conceivably break a low-grade encryption code in less than a month. In
1998, the Electronic Frontier Foundation (EFF) published designs for a (then) $250,000
computer capable of cracking 56-bit keys in a few seconds to demonstrate the need
for higher-grade encryption. If $250,000 seems like a lot of money to you, think of the
potential for credit card fraud if someone successfully used that computer for that
purpose!
For a key to be sufficiently difficult to break, experts suggest no fewer than 128 bits.
Because every extra bit effectively doubles the number of possibilities, 128 bits offers a
genuine challenge. And if you want to really make the encryption solid, a key size of 512
bits or higher is recommended. SSH can use up to 1024 bits to encrypt your data.
The tradeoff to using higher-bit encryption is that it requires more math-processing
power for the computer to churn through and validate a key. This takes time and, there-
fore, makes the authentication process a touch slower—but most people feel this tradeoff
is worthwhile.
Cryptography References
SSH supports a variety of encryption algorithms. Public-key encryption happens to be
the most interesting method of performing encryption from site to site and is arguably
the most secure. If you want to learn more about cryptography, here are some good
books and other resources to look into:
? PGP by Simson Garfinkel, et al. (O’Reilly and Associates, 1994)
? Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition by
Bruce Schneier (John Wiley & Sons, 1995)
? Cryptography and Network Security: Principles and Practice, Third Edition by Wil-
liam Stallings (Prentice Hall, 2002)
? http://tools.ietf.org/id/draft-ietf-secsh-connect-25.txt
? www.apps.ietf.org/rfc/rfc3766.html
The PGP book is specific to the PGP program, but it also contains a hefty amount of
history and an excellent collection of general cryptography tutorials. The Applied Cryp-
tography book might be a bit overwhelming to many, especially nonprogrammers, but it
successfully explains how actual cryptographic algorithms work. (This text is considered
a bible among cypherheads.) Finally, Cryptography and Network Security is heavier on
principles than on practice, but it’s useful if you’re interested in the theoretical aspects of
cryptography rather than the code itself.
UNDERSTANDING SSH VERSIONS AND DISTRIBUTIONS
The first version of SSH that was made available by DataFellows (now F-Secure) restricted
free use of SSH to noncommercial activities; commercial activities required that licenses
be purchased. But more significant than the cost of the package is the fact that the source
code to the package is completely open. This is important to cryptographic software,
for it allows peers to examine the source code and make sure there are no holes that
may allow hackers to break the security. (In other words, serious cryptographers do not
rely on security through obscurity.) Since the U.S. government has relaxed some of its
encryption laws, work on the OpenSSH project has increased, and it is a popular alterna-
tive to some of the commercial versions of the SSH protocol.
Because the SSH protocol has become an IETF standard, there are also other devel-
opers actively working on SSH clients for other operating systems. There are many
Microsoft Windows clients, Macintosh clients, and even a Palm client, in addition to the
standard UNIX clients. You can find the version of OpenSSH that we will be discussing
at www.openssh.org.
OpenSSH and OpenBSD
The OpenSSH project is being spearheaded by the OpenBSD project. OpenBSD is a ver-
sion of the Berkeley Software Distribution (BSD) operating system (another UNIX vari-
ant) that strives for the best security of any operating system available. A quick trip to
their web site (www.openbsd.org) shows that they have gone ten years with only two
remote exploits in their default installation. Unfortunately, this level of fanaticism on
security comes at the expense of not having the most whiz-bang-feature-rich tools avail-
able, since they require that anything added to their distribution gets audited for security
first. This has made OpenBSD a popular foundation for firewalls.
The core of the OpenSSH package is considered part of the OpenBSD project and, thus,
is simple and specific to the OpenBSD operating system. To make OpenSSH available to
other operating systems, a separate group exists to make OpenSSH portable whenever
new releases come out. Typically, this happens quickly after the original release.
POP and IMAP
POP AND IMAP BASICS
Like the other services we have discussed so far, POP and IMAP each need a server pro-
cess to handle requests. The server processes listen on ports 110 and 143, respectively.
Each request to and response from the server is in clear-text ASCII, which means it’s
easy for us to test the functionality of the server using Telnet. This is especially useful
for quickly debugging mail server connectivity/availability issues. Like an SMTP server,
one can interact with a POP or IMAP server using a short list of commands.
To get a look at the most common commands, let’s walk through the process of con-
necting and logging on to a POP server and an IMAP server. This simple test allows you
to verify that the server does in fact work and is providing valid authentication.
Although there are many POP commands, a few worth mentioning are
? USER
? PASS
A few noteworthy IMAP commands are
? LOGIN
? LIST
? STATUS
? EXAMINE/SELECT
? CREATE/DELETE/RENAME
? LOGOUT
INSTALLING THE UW-IMAP AND POP3 SERVER
The University of Washington produces a well-regarded IMAP server that is used in
many production sites around the world. It is a well-tested implementation; thus, it is the
version of IMAP that we will install
Most Linux distributions have prepackaged binaries for UW-IMAP in the distros
repositories. For example, UW-IMAP can be installed in Fedora by using Yum like so:
[root@serverA ~]# yum -y install uw-imap
On Debian-like systems, such as Ubuntu, UW-IMAP can be installed by using
Advanced Packaging Tool (APT) like so:
yyang@ubuntu-serverA:~$ sudo apt-get -y install uw-imapd
Installing UW-IMAP from Source
Begin by downloading the UW-IMAP server to /usr/local/src. The latest version of
the server can be found at ftp://ftp.cac.washington.edu/imap/imap.tar.Z. Once it
is downloaded, unpack it as follows:
[root@serverA src]# tar xvzf imap.tar.Z
This will create a new directory under which all of the source code will be pres-
ent. For the version we are using, we will see a new directory called imap-2007b
created. Change into the directory as follows:
[root@serverA src]# cd imap-2007b/
The defaults that ship with the UW-IMAP server work well for most installa-
tions. If you are interested in tuning the build process, open the makefile (found
in the current directory) with an editor and read through it. The file is well docu-
mented and shows what options can be turned on or off. For the installation we are
doing now, we will want to stick with a simple configuration change that we can
issue on the command line.
In addition to build options, the make command for UW-IMAP requires that
you specify the type of system that the package is being built on. This is in contrast
to many other open source programs that use the ./configure program (also
known as Autoconf) to automatically determine the running environment. The
options for Linux are as follows:
Parameter Environment
ldb
Debian Linux
lnx
Linux with traditional passwords
lnp
Linux with Pluggable Authentication Modules (PAM)
lmd
Mandrake Linux (also known as Mandriva Linux)
lrh
Red Hat Linux 7.2 and later
Parameter Environment
lr5
Red Hat Enterprise 5 and later (should cover recent Fedora
versions)
lsu
SuSE Linux
sl4
Linux with Shadow passwords (requiring an additional library)
sl5
Linux with Shadow passwords (not requiring an additional
library)
slx
Linux needing an extra library for password support
A little overwhelmed with the choices? Don’t be. Many of the choices are for old
versions of Linux that are not used anymore. If you have a Linux distribution that
is recent, the only ones you need to pay attention to are lsu (SuSE), lrh (Red Hat),
lmd (Mandrake), slx, and ldb (Debian).
If you are using SuSE, Red Hat/Fedora, Debian, or Mandrake/Mandriva, go ahead
and select the appropriate option. If you aren’t sure, the slx option should work on
almost all Linux-based systems. The only caveat with the slx option is that you may
need to edit the makefile and help it find where some common tool kits, such as OpenSSL,
are. (You can also simply disable those features, as we do in this installation.)
To keep things simple, we will follow the generic case and disable OpenSSL
but enable Internet Protocol version 6 (IPv6) support. To proceed with the build,
simply run
[root@serverA imap-2007b]# make slx IP=6 SSLTYPE=none
The entire build process should take only a few minutes, even on a slow machine.
Once complete, you will have four executables in the directory: mtest, ipop2d,
ipop3d, and imapd. Copy these to the /usr/local/sbin directory, like so:
[root@serverA imap-2007b]# cp mtest/mtest /usr/local/sbin/
[root@serverA imap-2007b]# cp ipopd/ipop2d /usr/local/sbin/
[root@serverA imap-2007b]# cp ipopd/ipop3d /usr/local/sbin/
[root@serverA imap-2007b]# cp imapd/imapd /usr/local/sbin/
Be sure their permissions are set correctly. Since they only need to be run by root, it is
appropriate to limit their access accordingly. Simply set their permissions as follows:
[root@serverA imap-2007b]# cd /usr/local/sbin
[root@serverA sbin]# chmod 700 mtest ipop2d ipop3d imapd
[root@serverA sbin]# chown root mtest ipop2d ipop3d imapd
That’s it
Running UW-IMAP
Most distributions automatically set up UW-IMAP to run under the superdaemon xinetd
(for more information on xinetd, see Chapter 8). Sample configuration files to get the
IMAP server and the POP3 servers running under xinetd in Fedora are shown here.
For the IMAP server, the configuration file is /etc/xinetd.d/imap.
service imap
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/imapd
log_on_success += HOST DURATION
log_on_failure += HOST
disable = no
}
For the POP3 server, the configuration file is /etc/xinetd.d/ipop3.
service pop3
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/ipop3d
log_on_success += HOST DURATION
log_on_failure += HOST
disable = no
Before telling xinetd to reload its configuration, you will want to check that your
/etc/ services file has both POP3 and IMAP listed. If /etc/services does not have the pro-
tocols listed, simply add the following two lines:
pop3 110/tcp
imap 143/tcp
Finally, tell xinetd to reload its configuration. If you are using Fedora, RHEL, or
Centos, this can be done with the following command:
[root@fedora-serverA bin]# service xinetd reload
If you are using another distribution, you might be able to restart xinetd by passing
therestart argument to xinetd’s run control, like so:
yyang@ubuntu-serverA:~$ sudo /etc/init.d/xinetd restart
If everything worked, you should have a functional IMAP server and POP3 server.
Using the commands and methods shown in the earlier section “POP and IMAP Basics”
we can connect and test for basic functionality.
Checking Basic POP3 Functionality
We begin by using Telnet to connect to the POP3 server (localhost in this example). From
a command prompt, type
[root@serverA ~]# telnet localhost 110
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK POP3 localhost.localdomain 2006k.101 server ready
The server is now waiting for you to give it a command. (Don’t worry that you don’t
see a prompt.) Start by submitting your login name as follows:
USER yourlogin
where yourlogin is, of course, your login ID. The server responds with
+OK User name accepted, password please
Now tell the server your password using the PASS command
PASS yourpassword
where yourpassword is your password. The server responds with
+OK Mailbox open, messages
where X represents the number of messages in your mailbox. You’re now logged in and can
issue commands to read your mail. Since we are simply validating that the server is work-
ing, we can log out now. Simply type QUIT, and the server will close the connection.
QUIT
+OK Sayonara
Connection closed by foreign host.
That’s it.
Checking Basic IMAP Functionality
We begin by using Telnet to connect to the IMAP server (localhost in this example). From
the command prompt, type
[root@serverA ~]# telnet localhost 143
The IMAP server will respond with something similar to
* OK [CAPABILITY.......
Like the other services we have discussed so far, POP and IMAP each need a server pro-
cess to handle requests. The server processes listen on ports 110 and 143, respectively.
Each request to and response from the server is in clear-text ASCII, which means it’s
easy for us to test the functionality of the server using Telnet. This is especially useful
for quickly debugging mail server connectivity/availability issues. Like an SMTP server,
one can interact with a POP or IMAP server using a short list of commands.
To get a look at the most common commands, let’s walk through the process of con-
necting and logging on to a POP server and an IMAP server. This simple test allows you
to verify that the server does in fact work and is providing valid authentication.
Although there are many POP commands, a few worth mentioning are
? USER
? PASS
A few noteworthy IMAP commands are
? LOGIN
? LIST
? STATUS
? EXAMINE/SELECT
? CREATE/DELETE/RENAME
? LOGOUT
INSTALLING THE UW-IMAP AND POP3 SERVER
The University of Washington produces a well-regarded IMAP server that is used in
many production sites around the world. It is a well-tested implementation; thus, it is the
version of IMAP that we will install
Most Linux distributions have prepackaged binaries for UW-IMAP in the distros
repositories. For example, UW-IMAP can be installed in Fedora by using Yum like so:
[root@serverA ~]# yum -y install uw-imap
On Debian-like systems, such as Ubuntu, UW-IMAP can be installed by using
Advanced Packaging Tool (APT) like so:
yyang@ubuntu-serverA:~$ sudo apt-get -y install uw-imapd
Installing UW-IMAP from Source
Begin by downloading the UW-IMAP server to /usr/local/src. The latest version of
the server can be found at ftp://ftp.cac.washington.edu/imap/imap.tar.Z. Once it
is downloaded, unpack it as follows:
[root@serverA src]# tar xvzf imap.tar.Z
This will create a new directory under which all of the source code will be pres-
ent. For the version we are using, we will see a new directory called imap-2007b
created. Change into the directory as follows:
[root@serverA src]# cd imap-2007b/
The defaults that ship with the UW-IMAP server work well for most installa-
tions. If you are interested in tuning the build process, open the makefile (found
in the current directory) with an editor and read through it. The file is well docu-
mented and shows what options can be turned on or off. For the installation we are
doing now, we will want to stick with a simple configuration change that we can
issue on the command line.
In addition to build options, the make command for UW-IMAP requires that
you specify the type of system that the package is being built on. This is in contrast
to many other open source programs that use the ./configure program (also
known as Autoconf) to automatically determine the running environment. The
options for Linux are as follows:
Parameter Environment
ldb
Debian Linux
lnx
Linux with traditional passwords
lnp
Linux with Pluggable Authentication Modules (PAM)
lmd
Mandrake Linux (also known as Mandriva Linux)
lrh
Red Hat Linux 7.2 and later
Parameter Environment
lr5
Red Hat Enterprise 5 and later (should cover recent Fedora
versions)
lsu
SuSE Linux
sl4
Linux with Shadow passwords (requiring an additional library)
sl5
Linux with Shadow passwords (not requiring an additional
library)
slx
Linux needing an extra library for password support
A little overwhelmed with the choices? Don’t be. Many of the choices are for old
versions of Linux that are not used anymore. If you have a Linux distribution that
is recent, the only ones you need to pay attention to are lsu (SuSE), lrh (Red Hat),
lmd (Mandrake), slx, and ldb (Debian).
If you are using SuSE, Red Hat/Fedora, Debian, or Mandrake/Mandriva, go ahead
and select the appropriate option. If you aren’t sure, the slx option should work on
almost all Linux-based systems. The only caveat with the slx option is that you may
need to edit the makefile and help it find where some common tool kits, such as OpenSSL,
are. (You can also simply disable those features, as we do in this installation.)
To keep things simple, we will follow the generic case and disable OpenSSL
but enable Internet Protocol version 6 (IPv6) support. To proceed with the build,
simply run
[root@serverA imap-2007b]# make slx IP=6 SSLTYPE=none
The entire build process should take only a few minutes, even on a slow machine.
Once complete, you will have four executables in the directory: mtest, ipop2d,
ipop3d, and imapd. Copy these to the /usr/local/sbin directory, like so:
[root@serverA imap-2007b]# cp mtest/mtest /usr/local/sbin/
[root@serverA imap-2007b]# cp ipopd/ipop2d /usr/local/sbin/
[root@serverA imap-2007b]# cp ipopd/ipop3d /usr/local/sbin/
[root@serverA imap-2007b]# cp imapd/imapd /usr/local/sbin/
Be sure their permissions are set correctly. Since they only need to be run by root, it is
appropriate to limit their access accordingly. Simply set their permissions as follows:
[root@serverA imap-2007b]# cd /usr/local/sbin
[root@serverA sbin]# chmod 700 mtest ipop2d ipop3d imapd
[root@serverA sbin]# chown root mtest ipop2d ipop3d imapd
That’s it
Running UW-IMAP
Most distributions automatically set up UW-IMAP to run under the superdaemon xinetd
(for more information on xinetd, see Chapter 8). Sample configuration files to get the
IMAP server and the POP3 servers running under xinetd in Fedora are shown here.
For the IMAP server, the configuration file is /etc/xinetd.d/imap.
service imap
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/imapd
log_on_success += HOST DURATION
log_on_failure += HOST
disable = no
}
For the POP3 server, the configuration file is /etc/xinetd.d/ipop3.
service pop3
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/ipop3d
log_on_success += HOST DURATION
log_on_failure += HOST
disable = no
Before telling xinetd to reload its configuration, you will want to check that your
/etc/ services file has both POP3 and IMAP listed. If /etc/services does not have the pro-
tocols listed, simply add the following two lines:
pop3 110/tcp
imap 143/tcp
Finally, tell xinetd to reload its configuration. If you are using Fedora, RHEL, or
Centos, this can be done with the following command:
[root@fedora-serverA bin]# service xinetd reload
If you are using another distribution, you might be able to restart xinetd by passing
therestart argument to xinetd’s run control, like so:
yyang@ubuntu-serverA:~$ sudo /etc/init.d/xinetd restart
If everything worked, you should have a functional IMAP server and POP3 server.
Using the commands and methods shown in the earlier section “POP and IMAP Basics”
we can connect and test for basic functionality.
Checking Basic POP3 Functionality
We begin by using Telnet to connect to the POP3 server (localhost in this example). From
a command prompt, type
[root@serverA ~]# telnet localhost 110
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK POP3 localhost.localdomain 2006k.101 server ready
The server is now waiting for you to give it a command. (Don’t worry that you don’t
see a prompt.) Start by submitting your login name as follows:
USER yourlogin
where yourlogin is, of course, your login ID. The server responds with
+OK User name accepted, password please
Now tell the server your password using the PASS command
PASS yourpassword
where yourpassword is your password. The server responds with
+OK Mailbox open,
where X represents the number of messages in your mailbox. You’re now logged in and can
issue commands to read your mail. Since we are simply validating that the server is work-
ing, we can log out now. Simply type QUIT, and the server will close the connection.
QUIT
+OK Sayonara
Connection closed by foreign host.
That’s it.
Checking Basic IMAP Functionality
We begin by using Telnet to connect to the IMAP server (localhost in this example). From
the command prompt, type
[root@serverA ~]# telnet localhost 143
The IMAP server will respond with something similar to
* OK [CAPABILITY.......
The main.cf File
The main.cf File
The main.cf file is too large to list all of its options in this chapter, but we will cover the
most important options that will get your mail server up and running. Thankfully, the
configuration file is well documented and explains clearly what each option is used for.
The sample options that we discuss next are enough to help you get a basic Post-
fix mail server up and running at a minimum. The first option we will look at is the
myhostname parameter.
myhostname
This parameter is used to set the name that Postfix will be receiving e-mail for. Typi-
cal examples of mail server hostnames are mail.example.com or smtp.example.org. The
syntax is
myhostname = serverA.example.org
mydomain
This parameter is the mail domain that you will be servicing, such as example.com or
google.com. The syntax is
mydomain = example.org
myorigin
All e-mail sent from this e-mail server will look as though it came from this parameter.
You can set this to either $myhostname or $mydomain, like so:
myorigin = $mydomain
Notice that you can use the value of other parameters in the configuration file by
placing a $ sign in front of the variable name.
mydestination
This parameter lists the domains that the Postfix server will take as its final destination
for incoming e-mail. Typically, this value is set to the hostname of the server and the
domain name, but it can contain other names, as shown here:
mydestination = $myhostname, localhost.$mydomain, $mydomain, \
mail.$mydomain, www.$mydomain, ftp.$mydomain
If your server has more than one name, for example, serverA.example.org and
serverA.another-example.org, you will want to make sure you list both names here.
mail_spool_directory
You can run the Postfix server in two modes of delivery: directly to a user’s mailbox or
to a central spool directory. The typical way is to store the mail in /var/spool/mail. The
variable will look like this in the configuration file:
mail_spool_directory = /var/spool/mail
The result is that mail will be stored for each user under the /var/spool/mail
directory, with each user’s mailbox represented as a file. For example, e-mail sent to
yyang@example.org will be stored in /var/spool/mail/yyang.
mynetworks
Themynetworks variable is an important configuration option. This lets you configure
what servers can relay through your Postfix server. You will usually want to allow relay-
ing from local client machines and nothing else. Otherwise, spammers can use your mail
server to relay messages. An example value of this variable would be
mynetworks = 192.168.1.0/24, 127.0.0.0/8
If you define this parameter, it will override the mynetworks_style parameter.
The mynetworks_style parameter allows you to specify any of the keywords class,
subnet, or host. These settings tell the server to trust these networks that the server
belongs to
smtpd_banner
This variable allows you to return a custom response when a client connects to your mail
server. It is a good idea to change the banner to something that doesn’t give away what
server you are using. This just adds one more slight hurdle for hackers trying to find
faults in your specific software version.
smtpd_banner = $myhostname ESMTP
smtpd_banner
This variable allows you to return a custom response when a client connects to your mail
server. It is a good idea to change the banner to something that doesn’t give away what
server you are using. This just adds one more slight hurdle for hackers trying to find
faults in your specific software version.
smtpd_banner = $myhostname ESMTP
inet_protocol
This parameter is used to invoke the Internet Protocol Version 6 (IPv6) capabilities of the
Postfix mail server. It is used to specify the Internet protocol version that Postfix will use
when making or accepting connections. Its default value is ipv4. Setting this value to
ipv6 will make Postfix support IPv6. Example values that this parameter accepts are
inet_protocols = ipv4 (DEFAULT)
inet_protocols = ipv4, ipv6
inet_protocols = all
inet_protocols = ipv6
There are tons of other parameters in the Postfix configuration file that we did not
discuss here. You might see them commented out in the configuration file when you
set the preceding options. These other options will allow you to set security levels and
debugging levels, among other things, as required.
Now we will move on to running the Postfix mail system and maintaining your mail
server.
The main.cf file is too large to list all of its options in this chapter, but we will cover the
most important options that will get your mail server up and running. Thankfully, the
configuration file is well documented and explains clearly what each option is used for.
The sample options that we discuss next are enough to help you get a basic Post-
fix mail server up and running at a minimum. The first option we will look at is the
myhostname parameter.
myhostname
This parameter is used to set the name that Postfix will be receiving e-mail for. Typi-
cal examples of mail server hostnames are mail.example.com or smtp.example.org. The
syntax is
myhostname = serverA.example.org
mydomain
This parameter is the mail domain that you will be servicing, such as example.com or
google.com. The syntax is
mydomain = example.org
myorigin
All e-mail sent from this e-mail server will look as though it came from this parameter.
You can set this to either $myhostname or $mydomain, like so:
myorigin = $mydomain
Notice that you can use the value of other parameters in the configuration file by
placing a $ sign in front of the variable name.
mydestination
This parameter lists the domains that the Postfix server will take as its final destination
for incoming e-mail. Typically, this value is set to the hostname of the server and the
domain name, but it can contain other names, as shown here:
mydestination = $myhostname, localhost.$mydomain, $mydomain, \
mail.$mydomain, www.$mydomain, ftp.$mydomain
If your server has more than one name, for example, serverA.example.org and
serverA.another-example.org, you will want to make sure you list both names here.
mail_spool_directory
You can run the Postfix server in two modes of delivery: directly to a user’s mailbox or
to a central spool directory. The typical way is to store the mail in /var/spool/mail. The
variable will look like this in the configuration file:
mail_spool_directory = /var/spool/mail
The result is that mail will be stored for each user under the /var/spool/mail
directory, with each user’s mailbox represented as a file. For example, e-mail sent to
yyang@example.org will be stored in /var/spool/mail/yyang.
mynetworks
Themynetworks variable is an important configuration option. This lets you configure
what servers can relay through your Postfix server. You will usually want to allow relay-
ing from local client machines and nothing else. Otherwise, spammers can use your mail
server to relay messages. An example value of this variable would be
mynetworks = 192.168.1.0/24, 127.0.0.0/8
If you define this parameter, it will override the mynetworks_style parameter.
The mynetworks_style parameter allows you to specify any of the keywords class,
subnet, or host. These settings tell the server to trust these networks that the server
belongs to
smtpd_banner
This variable allows you to return a custom response when a client connects to your mail
server. It is a good idea to change the banner to something that doesn’t give away what
server you are using. This just adds one more slight hurdle for hackers trying to find
faults in your specific software version.
smtpd_banner = $myhostname ESMTP
smtpd_banner
This variable allows you to return a custom response when a client connects to your mail
server. It is a good idea to change the banner to something that doesn’t give away what
server you are using. This just adds one more slight hurdle for hackers trying to find
faults in your specific software version.
smtpd_banner = $myhostname ESMTP
inet_protocol
This parameter is used to invoke the Internet Protocol Version 6 (IPv6) capabilities of the
Postfix mail server. It is used to specify the Internet protocol version that Postfix will use
when making or accepting connections. Its default value is ipv4. Setting this value to
ipv6 will make Postfix support IPv6. Example values that this parameter accepts are
inet_protocols = ipv4 (DEFAULT)
inet_protocols = ipv4, ipv6
inet_protocols = all
inet_protocols = ipv6
There are tons of other parameters in the Postfix configuration file that we did not
discuss here. You might see them commented out in the configuration file when you
set the preceding options. These other options will allow you to set security levels and
debugging levels, among other things, as required.
Now we will move on to running the Postfix mail system and maintaining your mail
server.
SMTP
UNDERSTANDING SMTP
The SMTP protocol defines the method by which mail is sent from one host to another.
That’s it. It does not define how the mail should be stored. It does not define how the
mail should be displayed to the recipient.
SMTP’s strength is its simplicity, and that is due, in part, to the dynamic nature of net-
works during the early 1980s. (The SMTP protocol was originally defined in 1982.) Back
in those days, people were linking networks together with everything short of bubble
gum and glue. SMTP was the first mail standard that was independent of the transport
mechanism. This meant people using Transmission Control Protocol/Internet Protocol
(TCP/IP) networks could use the same format to send a message as someone using two
cans and a string.
SMTP is also independent of operating systems, which means each system can use its
own style of storing mail without worrying about how the sender of a message stores his
mail. You can draw parallels to how the phone system works: Each phone service pro-
vider has its own independent accounting system. However, they all have agreed upon
a standard way to link their networks together so that calls can go from one network to
another transparently.
Rudimentary SMTP Details
Ever had a “friend” who sent you an e-mail on behalf of some government agency
informing you that you owe taxes from the previous year, plus additional penalties?
Somehow, a message like this ends up in a lot of people’s mailboxes around April
Fool’s Day. We’re going to show you how they did it and, what’s even more fun, how
you can do it yourself. (Not that we would advocate such behavior, of course.)
The purpose of this example is to show how the SMTP protocol sends a message
from one host to another. After all, more important than learning how to forge an
e-mail is learning how to troubleshoot mail-related problems. So in this example, you
are acting as the sending host, and whichever machine you connect to is the receiv-
ing host
The SMTP protocol requires only that a host be able to send straight ASCII text to
another host. Typically, this is done by contacting the SMTP port (port 25) on a mail
server. You can do this using the Telnet program. For example,
[root@serverA /root]# telnet mailserver 25
where the host mailserver is the recipient’s mail server. The 25 that follows mailserver
tells Telnet that you want to communicate with the server’s port 25 rather than the nor-
mal port 23. (Port 23 is used for remote logins, and port 25 is for the SMTP server.)
The mail server will respond with a greeting message such as this:
220 mail ESMTP Postfix
You are now communicating directly with the SMTP server.
Although there are many SMTP commands, the four worth noting are
? HELO
? MAIL FROM:
? RCPT TO:
? DATA
TheHELO command is used when a client introduces itself to the server. The param-
eter to HELO is the hostname that is originating the connection. Of course, most mail
servers take this information with a grain of salt and double-check it themselves. For
example:
HELO example.org
If you aren’t coming from the example.org domain, many mail servers will respond
by telling you that they know your real IP address, but they may or may not stop the
connection from continuing.
The MAIL FROM: command requires the sender’s e-mail address as its argument.
This tells the mail server the e-mail’s origin. For example:
MAIL FROM: suckup@example.org
means the message is from suckup@example.org.
TheRCPT TO: command requires the receiver’s e-mail address as an argument. For
example:
RCPT TO: manager@example.org
means the message is destined to manager@example.org.
Now that the server knows who the sender and recipient are, it needs to know what
message to send. This is done by using the DATA command. Once issued, the server will
expect the entire message, with relevant header information, followed by one empty line, a period, and then another empty line. Continuing the example, suckup@example.
org might want to send the following message to manager@example.org:
DATA
354 End data with.
Just an FYI, boss. The project is not only on time, but it is within
budget, too!
Regards –
SuckUp_to Upper_Management
.
250 2.0.0 Ok: queued as B9E3B3C0D
And that’s all there is to it. To close the connection, enter the QUIT command.
This is the basic technique used by applications that send mail—except, of course,
that all the gory details are masked behind a nice GUI application. The underlying trans-
action between the client and the server remains mostly the same.
Security Implications
Sendmail, the mail server a majority of Internet sites use, is the same package most Linux
distributions use. Like any other server software, its internal structure and design are
complex and require a considerable amount of care during development. In recent years,
however, the developers of Sendmail have taken a paranoid approach to their design to
help alleviate these issues. The Postfix developers took it one step further and wrote the
server from scratch with security in mind. Basically, they ship the package in a tight secu-
rity mode and leave it to us to loosen it up as much as we need to for our site. This means
the responsibility falls to us for making sure we keep the software properly configured
(and thus not vulnerable to attacks).
These are some issues to keep in mind when deploying any mail server:
? When an e-mail is sent to the server, what programs will it trigger?
? Are those programs securely designed?
? If they cannot be made secure, how can you limit their damage?
? Under what permissions do those programs run?
In Postfix’s case, we need to back up and examine its architecture.
Mail service has three distinct components. The mail user agent (MUA) is what the user
sees and interacts with, such as the Eudora, Outlook, Evolution, and Mutt programs. An
MUA is responsible only for reading mail and allowing users to compose mail. The mail
transport agent (MTA) handles the process of getting the mail from one site to another;
Sendmail and Postfix are MTAs. Finally, the mail delivery agent (MDA) is what takes the
message, once received at a site, and gets it to the appropriate user mailbox.
Many mail systems integrate these components. For example, Microsoft Exchange
Server integrates the MTA and MDA functionalities into a single system. (If you consider
the Outlook Web Access interface to Exchange Server, it is also an MUA.) Lotus Domino
also works in a similar fashion. Postfix, on the other hand, works as an MTA only, pass-
ing the task of performing local mail delivery to another external program. This allows
each operating system or site configuration to use its own custom tool, if necessary (that
is, to be able to use a special mailbox store mechanism).
In most straightforward configurations, sites prefer using the Procmail program to
perform the actual mail delivery (MDA). This is because of its advanced filtering mecha-
nism, as well as its secure design from the ground up. Many older configurations have
stayed with their default /bin/mail program to perform mail delivery.
INSTALLING THE POSTFIX SERVER
In this section, we will cover the installation of the Postfix mail server. We chose it for its
ease of use and because it was written from the ground up to be simpler than Sendmail.
(The author of Postfix also argues that the simplicity has led to improved security.) Post-
fix can perform most of the things that the Sendmail program can do—in fact, the typical
installation procedure for Postfix is to replace the Sendmail binaries completely.
In this section, we install Postfix in one of two ways: either using the Red Hat Pack-
age Manager (RPM) method (recommended) or via source code.
Installing Postfix via RPM in Fedora
To install Postfix via RPM, simply use the Yum tool as follows:
[root@fedora-serverA ~]# yum -y install postfix
Once the command runs to completion, you should have Postfix installed. Since
Sendmail is the default mailer that gets installed in Fedora and Red Hat Enterprise Linux
(RHEL) distros, you will need to disable it using the chkconfig command and then
enable Postfix.
[root@fedora-serverA ~]# chkconfig sendmail off
[root@fedora-serverA ~]# chkconfig postfix on
Finally, we can flip the switch and actually start the Postfix process. With a default
configuration, it won’t do much, but it will confirm whether the installation worked as
expected.
[root@fedora-serverA ~]# service sendmail stop
[root@
fedora-serverA ~]# service postfix start
Installing Postfix via APT in Ubuntu
Postfix can be installed in Ubuntu by using Advanced Packaging Tool (APT). Ubuntu,
unlike other Linux distributions, does not ship with any MTA software preconfigured
and running out of the box. You need to explicitly install and set one up. To install the
Postfix MTA in Ubuntu, run the command
yyang@ubuntu-serverA:~$ sudo apt-get -y install postfix
The install process will offer a choice of various Postfix configuration options during
the install process. The choices are
? No configuration This option will leave the current configuration unchanged.
? Internet site Mail is sent and received directly using SMTP.
? Internet with smarthost Mail is received directly using SMTP or by running a
utility such as fetchmail. Outgoing mail is sent using a smarthost.
? Satellite system All mail is sent to another machine, called a smarthost, for
delivery.
? Local only The only delivered mail is the mail for local users. The system does
not need any sort of network connectivity for this option.
We will select the first option, No configuration, on our sample Ubuntu server. The
install process will create the necessary user and group accounts that Postfix needs.
With the script in place, double-check that its permissions are correct with a quick
chmod
The SMTP protocol defines the method by which mail is sent from one host to another.
That’s it. It does not define how the mail should be stored. It does not define how the
mail should be displayed to the recipient.
SMTP’s strength is its simplicity, and that is due, in part, to the dynamic nature of net-
works during the early 1980s. (The SMTP protocol was originally defined in 1982.) Back
in those days, people were linking networks together with everything short of bubble
gum and glue. SMTP was the first mail standard that was independent of the transport
mechanism. This meant people using Transmission Control Protocol/Internet Protocol
(TCP/IP) networks could use the same format to send a message as someone using two
cans and a string.
SMTP is also independent of operating systems, which means each system can use its
own style of storing mail without worrying about how the sender of a message stores his
mail. You can draw parallels to how the phone system works: Each phone service pro-
vider has its own independent accounting system. However, they all have agreed upon
a standard way to link their networks together so that calls can go from one network to
another transparently.
Rudimentary SMTP Details
Ever had a “friend” who sent you an e-mail on behalf of some government agency
informing you that you owe taxes from the previous year, plus additional penalties?
Somehow, a message like this ends up in a lot of people’s mailboxes around April
Fool’s Day. We’re going to show you how they did it and, what’s even more fun, how
you can do it yourself. (Not that we would advocate such behavior, of course.)
The purpose of this example is to show how the SMTP protocol sends a message
from one host to another. After all, more important than learning how to forge an
e-mail is learning how to troubleshoot mail-related problems. So in this example, you
are acting as the sending host, and whichever machine you connect to is the receiv-
ing host
The SMTP protocol requires only that a host be able to send straight ASCII text to
another host. Typically, this is done by contacting the SMTP port (port 25) on a mail
server. You can do this using the Telnet program. For example,
[root@serverA /root]# telnet mailserver 25
where the host mailserver is the recipient’s mail server. The 25 that follows mailserver
tells Telnet that you want to communicate with the server’s port 25 rather than the nor-
mal port 23. (Port 23 is used for remote logins, and port 25 is for the SMTP server.)
The mail server will respond with a greeting message such as this:
220 mail ESMTP Postfix
You are now communicating directly with the SMTP server.
Although there are many SMTP commands, the four worth noting are
? HELO
? MAIL FROM:
? RCPT TO:
? DATA
TheHELO command is used when a client introduces itself to the server. The param-
eter to HELO is the hostname that is originating the connection. Of course, most mail
servers take this information with a grain of salt and double-check it themselves. For
example:
HELO example.org
If you aren’t coming from the example.org domain, many mail servers will respond
by telling you that they know your real IP address, but they may or may not stop the
connection from continuing.
The MAIL FROM: command requires the sender’s e-mail address as its argument.
This tells the mail server the e-mail’s origin. For example:
MAIL FROM: suckup@example.org
means the message is from suckup@example.org.
TheRCPT TO: command requires the receiver’s e-mail address as an argument. For
example:
RCPT TO: manager@example.org
means the message is destined to manager@example.org.
Now that the server knows who the sender and recipient are, it needs to know what
message to send. This is done by using the DATA command. Once issued, the server will
expect the entire message, with relevant header information, followed by one empty line, a period, and then another empty line. Continuing the example, suckup@example.
org might want to send the following message to manager@example.org:
DATA
354 End data with
Just an FYI, boss. The project is not only on time, but it is within
budget, too!
Regards –
SuckUp_to Upper_Management
.
250 2.0.0 Ok: queued as B9E3B3C0D
And that’s all there is to it. To close the connection, enter the QUIT command.
This is the basic technique used by applications that send mail—except, of course,
that all the gory details are masked behind a nice GUI application. The underlying trans-
action between the client and the server remains mostly the same.
Security Implications
Sendmail, the mail server a majority of Internet sites use, is the same package most Linux
distributions use. Like any other server software, its internal structure and design are
complex and require a considerable amount of care during development. In recent years,
however, the developers of Sendmail have taken a paranoid approach to their design to
help alleviate these issues. The Postfix developers took it one step further and wrote the
server from scratch with security in mind. Basically, they ship the package in a tight secu-
rity mode and leave it to us to loosen it up as much as we need to for our site. This means
the responsibility falls to us for making sure we keep the software properly configured
(and thus not vulnerable to attacks).
These are some issues to keep in mind when deploying any mail server:
? When an e-mail is sent to the server, what programs will it trigger?
? Are those programs securely designed?
? If they cannot be made secure, how can you limit their damage?
? Under what permissions do those programs run?
In Postfix’s case, we need to back up and examine its architecture.
Mail service has three distinct components. The mail user agent (MUA) is what the user
sees and interacts with, such as the Eudora, Outlook, Evolution, and Mutt programs. An
MUA is responsible only for reading mail and allowing users to compose mail. The mail
transport agent (MTA) handles the process of getting the mail from one site to another;
Sendmail and Postfix are MTAs. Finally, the mail delivery agent (MDA) is what takes the
message, once received at a site, and gets it to the appropriate user mailbox.
Many mail systems integrate these components. For example, Microsoft Exchange
Server integrates the MTA and MDA functionalities into a single system. (If you consider
the Outlook Web Access interface to Exchange Server, it is also an MUA.) Lotus Domino
also works in a similar fashion. Postfix, on the other hand, works as an MTA only, pass-
ing the task of performing local mail delivery to another external program. This allows
each operating system or site configuration to use its own custom tool, if necessary (that
is, to be able to use a special mailbox store mechanism).
In most straightforward configurations, sites prefer using the Procmail program to
perform the actual mail delivery (MDA). This is because of its advanced filtering mecha-
nism, as well as its secure design from the ground up. Many older configurations have
stayed with their default /bin/mail program to perform mail delivery.
INSTALLING THE POSTFIX SERVER
In this section, we will cover the installation of the Postfix mail server. We chose it for its
ease of use and because it was written from the ground up to be simpler than Sendmail.
(The author of Postfix also argues that the simplicity has led to improved security.) Post-
fix can perform most of the things that the Sendmail program can do—in fact, the typical
installation procedure for Postfix is to replace the Sendmail binaries completely.
In this section, we install Postfix in one of two ways: either using the Red Hat Pack-
age Manager (RPM) method (recommended) or via source code.
Installing Postfix via RPM in Fedora
To install Postfix via RPM, simply use the Yum tool as follows:
[root@fedora-serverA ~]# yum -y install postfix
Once the command runs to completion, you should have Postfix installed. Since
Sendmail is the default mailer that gets installed in Fedora and Red Hat Enterprise Linux
(RHEL) distros, you will need to disable it using the chkconfig command and then
enable Postfix.
[root@fedora-serverA ~]# chkconfig sendmail off
[root@fedora-serverA ~]# chkconfig postfix on
Finally, we can flip the switch and actually start the Postfix process. With a default
configuration, it won’t do much, but it will confirm whether the installation worked as
expected.
[root@fedora-serverA ~]# service sendmail stop
[root@
fedora-serverA ~]# service postfix start
Installing Postfix via APT in Ubuntu
Postfix can be installed in Ubuntu by using Advanced Packaging Tool (APT). Ubuntu,
unlike other Linux distributions, does not ship with any MTA software preconfigured
and running out of the box. You need to explicitly install and set one up. To install the
Postfix MTA in Ubuntu, run the command
yyang@ubuntu-serverA:~$ sudo apt-get -y install postfix
The install process will offer a choice of various Postfix configuration options during
the install process. The choices are
? No configuration This option will leave the current configuration unchanged.
? Internet site Mail is sent and received directly using SMTP.
? Internet with smarthost Mail is received directly using SMTP or by running a
utility such as fetchmail. Outgoing mail is sent using a smarthost.
? Satellite system All mail is sent to another machine, called a smarthost, for
delivery.
? Local only The only delivered mail is the mail for local users. The system does
not need any sort of network connectivity for this option.
We will select the first option, No configuration, on our sample Ubuntu server. The
install process will create the necessary user and group accounts that Postfix needs.
With the script in place, double-check that its permissions are correct with a quick
chmod
Apache Web Server
INSTALLING THE APACHE HTTP SERVER
Most modern Linux distributions come with the binary package for the Apache HTTP
server software in Red Hat Package Manager (RPM) format, so installing the software is
usually as simple as using the package management tool on the system. This section walks
you through the process of obtaining and installing the program via RPM and Advanced
Packaging Tool (APT). Mention is also made of installing the software from source code,
if you choose to go that route. The actual configuration of the server covered in later sec-
tions applies to both classes of installation (from source or from a binary package).
On a Fedora system, there are several ways to obtain the Apache RPM. Here are some
of them:
? Download the Apache RPM (e.g., httpd-*.rpm) for your operating system from
your distribution’s software repository. For Fedora, you can obtain a copy of
the program from http://download.fedora.redhat.com/pub/fedora/linux/
releases/9/Fedora/i386/os/Packages/.
? You can install from the install media, from the /Packages/ directory on the
media.
? You can pull down and install the program directly from a repository using the
Yum program. This is perhaps the quickest method if you have a working con-
nection to the Internet. And this is what we’ll do here.
To use Yum to install the program, type
[root@fedora-serverA ~]# yum -y install httpd
To confirm that the software is installed, type
[root@fedora-serverA vsftpd]# rpm -q httpd
httpd-2.*
And that’s it! You now have Apache installed on the Fedora server.
For a Debian-based Linux distribution like Ubuntu, you can use APT to install
Apache by running
yyang@ubuntu-serverA:~$ sudo apt-get -y install apache2
The web server daemon is automatically started after you install using apt-get on
Ubuntu systems
Installing Apache from Source
Just in case you are not happy with the built-in defaults that the binary Apache
package forces you to live with and you want to build your web server software
from scratch, you can always obtain the latest stable version of the program
directly from the apache.org web site. The procedure for building from source is
discussed here.
We’ll download the latest program source into the /usr/local/src/ directory from
the apache.org web site. You can use the wget program to do this. Type
[root@serverA src]# wget http://www.apache.org/dist/httpd/httpd-2.2.8.tar.gz
Extract the tar archive. And then change to the directory that is created during
the extraction.
[root@serverA src]# tar xvzf httpd-2.2.8.tar.gz
[root@serverA src]# cd httpd-2.2.8
Assuming we want the web server program to be installed under the /usr/local/
httpd/ directory, we’ll run the configure script with the proper prefix option.
[root@serverA httpd-2.2.8]# ./configure --prefix=/usr/local/httpd
Runmake.
[root@serverA httpd-2.2.8]# make
Create the program’s working directory (i.e., /usr/local/httpd/), and then run
make install.
[root@serverA httpd-2.2.8]# make install
Once the install command completes successfully, a directory structure will
be created under /usr/local/httpd/ that will contain the binaries, the configuration
files, the log files, etc. for the web server.
Apache Modules
Part of what makes Apache so powerful and flexible is that its design allows extensions
through modules. Apache comes with many modules by default and automatically
includes them in the default installation.
If you can imagine “it,” you can be almost certain that somebody has probably
already written a module for “it” for the Apache web server. The Apache module appli-
cation programming interface (API) is well documented, so if you are so inclined (and
know how to), you can probably write your own module for Apache to provide a func-
tionality that you want.
To give you some idea of what kinds of things people are doing with modules, visit
http://modules.apache.org. There you will find information on how to extend Apache’s
capabilities using modules. Some common Apache modules are
? mod_cgi Allows the execution of CGI scripts on the web server
? mod_perl Used to incorporate a Perl interpreter into the Apache web server
? mod_aspdotnet Provides an ASP.NET host interface to Microsoft’s ASP.NET
engine
? mod_authz_ldap Provides support for authenticating users of the Apache
HTTP server against a Lightweight Directory Access Protocol (LDAP) database
? mod_ssl Provides strong cryptography for the Apache web server via the
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols
? mod_ftpd Allows Apache to accept FTP connections
? mod_userdir Allows user content to be served from user-specific directories
on the web server via HTTP
If you know the name of a particular module that you want (and if the module is
popular enough), you might find that the module has already been packaged in an
RPM format, and so you can install it using the usual RPM methods. For example, if
you want to include the SSL module (mod_ssl) in your web server setup, on a Fedora
system, you can issue this Yum command to automatically download and install the
module for you:
[root@serverA ~]# yum install mod_ssl
Alternatively, you can go to the Apache modules project web site and search for,
download, compile, and install the module that you want.
STARTING UP AND SHUTTING DOWN APACHE
Starting up and shutting down Apache on most Linux distributions is easy. To start
Apache on a Fedora system or any other Red Hat–like system, use this command:
[root@serverA ~]# service httpd start
To shut down Apache, enter this command:
[root@serverA ~]# service httpd stop
After making a configuration change to the web server that requires you to restart
Apache, type
[root@serverA ~]# service httpd restart
Starting Apache at Boot Time
After installing the web server, if you find that the web service is one that you want the
system to provide at all times, you will need to configure the system to automatically
start the service for you between system reboots. It is easy to forget to do this on a sys-
tem that has been running for a long time without requiring any reboots, because if you
ever had to shut down the system due to an unrelated issue, you might be baffled as to
why the web server that has been running perfectly without incident failed to start up
after starting the box. So it is good practice to take care of this during the early stages of
configuring the service.
Most Linux flavors have the chkconfig utility available, which can be used for
controlling which system services start up at what runlevels.
To view the runlevels the web server is configured to start up in, type
[root@fedora-serverA ~]# chkconfig --list httpd
httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
This output shows that the web server is not configured to start up in any runlevel
in its out-of-the-box state. To change this and make Apache start up automatically in
runlevels 2, 3, 4, and 5, type
[root@fedora-serverA ~]# chkconfig httpd on
In Ubuntu, you can use either the sysv-rc-conf or the update-rc.d utility to
manage the runlevels in which Apache starts up
TESTING YOUR INSTALLATION
You can perform a quick test of your Apache installation using its default home page.
To do this, first confirm that the web server is up and running using the following
command:
[root@serverA httpd-2.2.8]# service httpd status
httpd (pid 31090 31089 31084 31083 31081) is running...
On our sample Fedora system, Apache comes with a default page that gets served to
visitors in the absence of a default home page (e.g., index.html or index.htm). The file
that gets displayed to visitors when there is no default home page is /var/www/error/
noindex.html.
To find out if your Apache installation went smoothly, start a web browser and tell
it to visit the web site on your machine. To do this, simply type http://localhost (or the
Internet Protocol Version 6 [IPv6] equivalent, http://[::1]/) in the address bar of your web
browser. You should see a page stating something to the effect that “your Apache HTTP
server is working properly at your site.” If you don’t, retrace your Apache installation
steps and make sure you didn’t encounter any errors in the process.
CONFIGURING APACHE
Apache supports a rich set of configuration options that are sensible and easy to follow.
This makes it a simple task to set up the web server in various configurations.
This section walks through a basic configuration. The default configuration is actu-
ally quite good and (believe it or not) works right out of the box, so if the default is
acceptable to you, simply start creating your Hypertext Markup Language (HTML) doc-
uments! Apache allows several common customizations. After we step through creating
a simple web page, we’ll show how you can make those common customizations in the
Apache configuration files.
Creating a Simple Root-Level Page
If you like, you can start adding files to Apache right away in the /var/www/html direc-
tory for top-level pages (for a source install, the directory would be /usr/local/httpd/
htdocs). Any files placed in that directory must be world-readable.
As mentioned earlier, Apache’s default web page is index.html. Let’s take a closer
look at creating and changing the default home page so that it reads “Welcome to
serverA.example.org.” Here are the commands:
[root@serverA ~]# cd /var/www/html/
[root@serverA html]# echo "Welcome to serverA.example.org" >> index.html
[root@serverA html]# chmod 644 index.html
You could also use an editor such as vi, pico,or emacs to edit the index.html file and
make it more interesting.
Apache Configuration Files
The configuration files for Apache are located in the /etc/httpd/conf/ directory on a
Fedora or Red Hat Enterprise Linux (RHEL) system, and for our sample source install,
the path will be /usr/local/httpd/conf/. The main configuration file is usually named
httpd.conf on Red Hat–like distributions like Fedora. On Debian-like systems, the main
configuration file for Apache is named /etc/apache2/apache2.conf.
The best way to learn more about the configuration files is to read the httpd.conf file.
The default configuration file is heavily commented, explaining each entry, its role, and
the parameters you can set.
Common Configuration Options
The default configuration settings work just fine right out of the box, and for basic needs,
may require no further modification. Nevertheless, site administrators may need to cus-
tomize their web server or web site further.
This section discusses some of the common directives or options that are used in
Apache’s configuration file.
ServerRoot
This is used for specifying the base directory for the web server. On Fedora, RHEL,
and Centos distributions, this value, by default, is the /etc/httpd/ directory. The default
value for this directive in Ubuntu, OpenSuSE, and Debian Linux distributions is /etc/
apache2/.
Syntax: ServerRoot directory-path
Listen
This is the port(s) on which the server listens for connection requests. It can also be used
to specify the particular IP addresses over which the web server accepts connections. The
default value for this directive is 80 for nonsecure web communications.
Syntax: Listen [IP-address:] portnumber
For example, to set Apache to listen on its IPv4 and IPv6 interfaces on port 80, you
would set the Listen directive to read
Listen 80
To set Apache to listen on a specific IPv6 interface (e.g., fec0::20c:dead:beef:11cd) on
port 8080, you would set the Listen directive to read
Listen [fec0::20c:dead:beef:11cd]:8080
ServerName
This directive defines the hostname and port that the server uses to identify itself. At
many sites, servers fulfill multiple purposes. An intranet web server that isn’t getting
heavy usage, for example, should probably share its usage allowance with another ser-
vice. In such a situation, a computer name such as “www” (fully qualified domain name,
or FQDN=www.example.org) wouldn’t be a good choice, because it suggests that the
machine has only one purpose.
It’s better to give a server a neutral name and then establish Domain Name System
(DNS) Canonical Name (CNAME) entries or multiple hostname entries in the /etc/hosts
file. In other words, you can give the system several names for accessing the server,
but it needs to know only about its real name. Consider a server whose hostname is
dioxin.eng.example.org that is to be a web server as well. You might be thinking of
giving it the hostname alias www.sales.example.org. However, since dioxin will know
itself only as dioxin, users who visit www.sales.example.org might be confused by see-
ing in their browsers that the server’s real name is dioxin.
Apache provides a way to get around this through the use of the ServerName direc-
tive. This works by allowing you to specify what you want Apache to return as the host-
name of the web server to web clients or visitors.
Syntax: ServerName fully-qualified-domain-name[: port]
ServerAdmin
This is the e-mail address that the server includes in error messages sent to the client.
It’s often a good idea, for a couple of reasons, to use an e-mail alias for a web site’s
administrator. First, there may be more than one administrator. By using an alias, it’s
possible for the alias to expand out to a list of other e-mail addresses. Second, if the current administrator leaves, you don’t want to have to make the rounds of all those web
pages and change the name of the site administrator.
Syntax: ServerAdmin e-mail_address
DocumentRoot
This defines the primary directory on the web server from which HTML files will be
served to requesting clients. On Fedora distros and other Red Hat–like systems, the
default value for this directive is /var/www/html/. On OpenSuSE and SEL distributions,
the default value for this directive is /srv/www/htdocs.
Most modern Linux distributions come with the binary package for the Apache HTTP
server software in Red Hat Package Manager (RPM) format, so installing the software is
usually as simple as using the package management tool on the system. This section walks
you through the process of obtaining and installing the program via RPM and Advanced
Packaging Tool (APT). Mention is also made of installing the software from source code,
if you choose to go that route. The actual configuration of the server covered in later sec-
tions applies to both classes of installation (from source or from a binary package).
On a Fedora system, there are several ways to obtain the Apache RPM. Here are some
of them:
? Download the Apache RPM (e.g., httpd-*.rpm) for your operating system from
your distribution’s software repository. For Fedora, you can obtain a copy of
the program from http://download.fedora.redhat.com/pub/fedora/linux/
releases/9/Fedora/i386/os/Packages/.
? You can install from the install media, from the /Packages/ directory on the
media.
? You can pull down and install the program directly from a repository using the
Yum program. This is perhaps the quickest method if you have a working con-
nection to the Internet. And this is what we’ll do here.
To use Yum to install the program, type
[root@fedora-serverA ~]# yum -y install httpd
To confirm that the software is installed, type
[root@fedora-serverA vsftpd]# rpm -q httpd
httpd-2.*
And that’s it! You now have Apache installed on the Fedora server.
For a Debian-based Linux distribution like Ubuntu, you can use APT to install
Apache by running
yyang@ubuntu-serverA:~$ sudo apt-get -y install apache2
The web server daemon is automatically started after you install using apt-get on
Ubuntu systems
Installing Apache from Source
Just in case you are not happy with the built-in defaults that the binary Apache
package forces you to live with and you want to build your web server software
from scratch, you can always obtain the latest stable version of the program
directly from the apache.org web site. The procedure for building from source is
discussed here.
We’ll download the latest program source into the /usr/local/src/ directory from
the apache.org web site. You can use the wget program to do this. Type
[root@serverA src]# wget http://www.apache.org/dist/httpd/httpd-2.2.8.tar.gz
Extract the tar archive. And then change to the directory that is created during
the extraction.
[root@serverA src]# tar xvzf httpd-2.2.8.tar.gz
[root@serverA src]# cd httpd-2.2.8
Assuming we want the web server program to be installed under the /usr/local/
httpd/ directory, we’ll run the configure script with the proper prefix option.
[root@serverA httpd-2.2.8]# ./configure --prefix=/usr/local/httpd
Runmake.
[root@serverA httpd-2.2.8]# make
Create the program’s working directory (i.e., /usr/local/httpd/), and then run
make install.
[root@serverA httpd-2.2.8]# make install
Once the install command completes successfully, a directory structure will
be created under /usr/local/httpd/ that will contain the binaries, the configuration
files, the log files, etc. for the web server.
Apache Modules
Part of what makes Apache so powerful and flexible is that its design allows extensions
through modules. Apache comes with many modules by default and automatically
includes them in the default installation.
If you can imagine “it,” you can be almost certain that somebody has probably
already written a module for “it” for the Apache web server. The Apache module appli-
cation programming interface (API) is well documented, so if you are so inclined (and
know how to), you can probably write your own module for Apache to provide a func-
tionality that you want.
To give you some idea of what kinds of things people are doing with modules, visit
http://modules.apache.org. There you will find information on how to extend Apache’s
capabilities using modules. Some common Apache modules are
? mod_cgi Allows the execution of CGI scripts on the web server
? mod_perl Used to incorporate a Perl interpreter into the Apache web server
? mod_aspdotnet Provides an ASP.NET host interface to Microsoft’s ASP.NET
engine
? mod_authz_ldap Provides support for authenticating users of the Apache
HTTP server against a Lightweight Directory Access Protocol (LDAP) database
? mod_ssl Provides strong cryptography for the Apache web server via the
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols
? mod_ftpd Allows Apache to accept FTP connections
? mod_userdir Allows user content to be served from user-specific directories
on the web server via HTTP
If you know the name of a particular module that you want (and if the module is
popular enough), you might find that the module has already been packaged in an
RPM format, and so you can install it using the usual RPM methods. For example, if
you want to include the SSL module (mod_ssl) in your web server setup, on a Fedora
system, you can issue this Yum command to automatically download and install the
module for you:
[root@serverA ~]# yum install mod_ssl
Alternatively, you can go to the Apache modules project web site and search for,
download, compile, and install the module that you want.
STARTING UP AND SHUTTING DOWN APACHE
Starting up and shutting down Apache on most Linux distributions is easy. To start
Apache on a Fedora system or any other Red Hat–like system, use this command:
[root@serverA ~]# service httpd start
To shut down Apache, enter this command:
[root@serverA ~]# service httpd stop
After making a configuration change to the web server that requires you to restart
Apache, type
[root@serverA ~]# service httpd restart
Starting Apache at Boot Time
After installing the web server, if you find that the web service is one that you want the
system to provide at all times, you will need to configure the system to automatically
start the service for you between system reboots. It is easy to forget to do this on a sys-
tem that has been running for a long time without requiring any reboots, because if you
ever had to shut down the system due to an unrelated issue, you might be baffled as to
why the web server that has been running perfectly without incident failed to start up
after starting the box. So it is good practice to take care of this during the early stages of
configuring the service.
Most Linux flavors have the chkconfig utility available, which can be used for
controlling which system services start up at what runlevels.
To view the runlevels the web server is configured to start up in, type
[root@fedora-serverA ~]# chkconfig --list httpd
httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
This output shows that the web server is not configured to start up in any runlevel
in its out-of-the-box state. To change this and make Apache start up automatically in
runlevels 2, 3, 4, and 5, type
[root@fedora-serverA ~]# chkconfig httpd on
In Ubuntu, you can use either the sysv-rc-conf or the update-rc.d utility to
manage the runlevels in which Apache starts up
TESTING YOUR INSTALLATION
You can perform a quick test of your Apache installation using its default home page.
To do this, first confirm that the web server is up and running using the following
command:
[root@serverA httpd-2.2.8]# service httpd status
httpd (pid 31090 31089 31084 31083 31081) is running...
On our sample Fedora system, Apache comes with a default page that gets served to
visitors in the absence of a default home page (e.g., index.html or index.htm). The file
that gets displayed to visitors when there is no default home page is /var/www/error/
noindex.html.
To find out if your Apache installation went smoothly, start a web browser and tell
it to visit the web site on your machine. To do this, simply type http://localhost (or the
Internet Protocol Version 6 [IPv6] equivalent, http://[::1]/) in the address bar of your web
browser. You should see a page stating something to the effect that “your Apache HTTP
server is working properly at your site.” If you don’t, retrace your Apache installation
steps and make sure you didn’t encounter any errors in the process.
CONFIGURING APACHE
Apache supports a rich set of configuration options that are sensible and easy to follow.
This makes it a simple task to set up the web server in various configurations.
This section walks through a basic configuration. The default configuration is actu-
ally quite good and (believe it or not) works right out of the box, so if the default is
acceptable to you, simply start creating your Hypertext Markup Language (HTML) doc-
uments! Apache allows several common customizations. After we step through creating
a simple web page, we’ll show how you can make those common customizations in the
Apache configuration files.
Creating a Simple Root-Level Page
If you like, you can start adding files to Apache right away in the /var/www/html direc-
tory for top-level pages (for a source install, the directory would be /usr/local/httpd/
htdocs). Any files placed in that directory must be world-readable.
As mentioned earlier, Apache’s default web page is index.html. Let’s take a closer
look at creating and changing the default home page so that it reads “Welcome to
serverA.example.org.” Here are the commands:
[root@serverA ~]# cd /var/www/html/
[root@serverA html]# echo "Welcome to serverA.example.org" >> index.html
[root@serverA html]# chmod 644 index.html
You could also use an editor such as vi, pico,or emacs to edit the index.html file and
make it more interesting.
Apache Configuration Files
The configuration files for Apache are located in the /etc/httpd/conf/ directory on a
Fedora or Red Hat Enterprise Linux (RHEL) system, and for our sample source install,
the path will be /usr/local/httpd/conf/. The main configuration file is usually named
httpd.conf on Red Hat–like distributions like Fedora. On Debian-like systems, the main
configuration file for Apache is named /etc/apache2/apache2.conf.
The best way to learn more about the configuration files is to read the httpd.conf file.
The default configuration file is heavily commented, explaining each entry, its role, and
the parameters you can set.
Common Configuration Options
The default configuration settings work just fine right out of the box, and for basic needs,
may require no further modification. Nevertheless, site administrators may need to cus-
tomize their web server or web site further.
This section discusses some of the common directives or options that are used in
Apache’s configuration file.
ServerRoot
This is used for specifying the base directory for the web server. On Fedora, RHEL,
and Centos distributions, this value, by default, is the /etc/httpd/ directory. The default
value for this directive in Ubuntu, OpenSuSE, and Debian Linux distributions is /etc/
apache2/.
Syntax: ServerRoot directory-path
Listen
This is the port(s) on which the server listens for connection requests. It can also be used
to specify the particular IP addresses over which the web server accepts connections. The
default value for this directive is 80 for nonsecure web communications.
Syntax: Listen [IP-address:] portnumber
For example, to set Apache to listen on its IPv4 and IPv6 interfaces on port 80, you
would set the Listen directive to read
Listen 80
To set Apache to listen on a specific IPv6 interface (e.g., fec0::20c:dead:beef:11cd) on
port 8080, you would set the Listen directive to read
Listen [fec0::20c:dead:beef:11cd]:8080
ServerName
This directive defines the hostname and port that the server uses to identify itself. At
many sites, servers fulfill multiple purposes. An intranet web server that isn’t getting
heavy usage, for example, should probably share its usage allowance with another ser-
vice. In such a situation, a computer name such as “www” (fully qualified domain name,
or FQDN=www.example.org) wouldn’t be a good choice, because it suggests that the
machine has only one purpose.
It’s better to give a server a neutral name and then establish Domain Name System
(DNS) Canonical Name (CNAME) entries or multiple hostname entries in the /etc/hosts
file. In other words, you can give the system several names for accessing the server,
but it needs to know only about its real name. Consider a server whose hostname is
dioxin.eng.example.org that is to be a web server as well. You might be thinking of
giving it the hostname alias www.sales.example.org. However, since dioxin will know
itself only as dioxin, users who visit www.sales.example.org might be confused by see-
ing in their browsers that the server’s real name is dioxin.
Apache provides a way to get around this through the use of the ServerName direc-
tive. This works by allowing you to specify what you want Apache to return as the host-
name of the web server to web clients or visitors.
Syntax: ServerName fully-qualified-domain-name[: port]
ServerAdmin
This is the e-mail address that the server includes in error messages sent to the client.
It’s often a good idea, for a couple of reasons, to use an e-mail alias for a web site’s
administrator. First, there may be more than one administrator. By using an alias, it’s
possible for the alias to expand out to a list of other e-mail addresses. Second, if the current administrator leaves, you don’t want to have to make the rounds of all those web
pages and change the name of the site administrator.
Syntax: ServerAdmin e-mail_address
DocumentRoot
This defines the primary directory on the web server from which HTML files will be
served to requesting clients. On Fedora distros and other Red Hat–like systems, the
default value for this directive is /var/www/html/. On OpenSuSE and SEL distributions,
the default value for this directive is /srv/www/htdocs.
CUSTOMIZING THE FTP SERVER
CUSTOMIZING THE FTP SERVER
The default out-of-the-box behavior of vsftpd is probably not what you want for your
production FTP server. So in this section we will walk through the process of custom-
izing some of the FTP server’s options to suit certain scenarios.
Setting Up an Anonymous-Only FTP Server
First we’ll set up our FTP server so that it does not allow access to users that have regular
user accounts on the system. This type of FTP server is useful for large sites that have
files that they want to make available to the general public via FTP. In such a scenario, it
is, of course, impractical to create an account for every single user when users can poten-
tially number into the thousands.
Fortunately for us, vsftpd is ready to serve as an anonymous FTP server out of the
box. But we’ll examine the configuration options in the vsftpd.conf file that ensure this
and also disable the options that are not required.
With any text editor of your choice, open up the /etc/vsftpd/vsftpd.conf file for edit-
ing. Look through the file and make sure that, at a minimum, the directives listed next
are present (if the directives are present but commented out, you might need to remove
the comment symbol [#] or change the value of the option).
listen=YES
xferlog_enable=YES
anonymous_enable=YES
local_enable=NO
write_enable=NO
You will find that the options in the preceding listing are sufficient to enable your
anonymous-only FTP server, and so you may choose to overwrite the existing /etc/ vsftpd/
vsftpd.conf file and enter just the options shown. This will help keep the configuration
file simple and uncluttered.
[root@serverA ~]# getent passwd ftp
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
If you don’t get output similar to this, you can quickly create the FTP system account with the
useradd command. To create a suitable ftp user, type
[root@serverA ~]# useradd -c "FTP User" -d /var/ftp -r -s /sbin/nologin ftp
If you had to make any modifications to the /etc/vsftpd/vsftpd.conf file, you need to
restart the vsftpd service. Type
[root@fedora-serverA ~]# service vsftpd restart
If the service command is not available on your Linux distribution, you may be
able to control the service by directly executing its run control script. For example, you
may be able to restart vsftpd by issuing the command
[root@serverA ~]# /etc/init.d/vsftpd restart
Setting Up an FTP Server with Virtual Users
Virtual users are users that do not actually exist; i.e., these users do not have any privi-
leges or functions on the system besides those for which they were created. This type of
FTP setup serves as a midway point between enabling users with local system accounts
access to the FTP server and enabling only anonymous users. If there is no way to guaran-
tee the security of the network connection from the user end (FTP client) to the server end
(FTP server), it will be foolhardy to allow users with local system accounts to log into the
FTP server. This is because the FTP transaction between both ends usually occurs in plain
text. Of course, this is only relevant if the server contains any data of value to its owners!
The use of virtual users will allow a site to serve content that should be accessible
to untrusted users, but still make the FTP service accessible to the general public. In the
event that the credentials of the virtual user(s) ever become compromised, one can at
least rest assured that only minimal damage can occur.
In this section we are going to create two sample virtual users named “ftp-user1”
and “ftp-user2.” These users will not exist in any form in the system’s user database (the
/etc/passwd file). These steps detail the process:
1. First we’ll create a plain-text file that will contain the username and password
combinations of the virtual users. Each username with its associated password
will be on alternating lines in the file. For example, for the user ftp-user1, the
password will be “user1,” and for the user ftp-user2, the password will be
“user2.” We’ll name the file plain_vsftpd.txt. Use any text editor of your choice
to create the file. Here we use vi:
[root@serverA ~]# vi plain_vsftpd.txt
2. Enter this text into the file:
ftp-user1
user1
ftp-user2
user2
3. Save the changes to the file, and exit the text editor.
4. Convert the plain-text file that was created in Step 2 into a Berkeley DB format
(db) that can be used with the pam_userdb.so library. The output will be saved
in a file called hash_vsftpd.db stored under the /etc directory. Type
[root@serverA ~]# db_load -T -t hash -f plain_vsftpd.txt /etc/hash_vsftpd.db
5. Restrict access to the virtual users database file by giving it more restrictive
permissions. This will ensure that it cannot be read by any casual user on the
system. Type
[root@serverA ~]# chmod 600 /etc/hash_vsftpd.db
6. Next we need to create a PAM file that the FTP service will use as the new vir-
tual users database file. We’ll name the file virtual-ftp and save it under the
/etc/pam.d/ directory. Use any text editor to create the file.
[root@serverA ~]# vi /etc/pam.d/virtual-ftp
7. Enter this text into the file:
auth required /lib/security/pam_userdb.so db=/etc/hash_vsftpd
account required /lib/security/pam_userdb.so db=/etc/hash_vsftpd
These entries tell the PAM system to authenticate users using the new database
stored in the hash_vsftpd.db file.
8. Save the changes into a file named virtual-ftp under the /etc/pam.d/ directory.
9. Let’s create a home environment for our virtual FTP users. We’ll cheat and use
the existing directory structure of the FTP server to create a subfolder that will
store the files that we want the virtual users to be able to access. Type
[root@serverA ~]# mkdir -p /var/ftp/private
10. Now we’ll create our custom vsftpd.conf file that will enable the entire setup.
With any text editor of your choice, open the /etc/vsftpd/vsftpd.conf file for edit-
ing. Look through the file and make sure that, at a minimum, the directives
listed next are present (if the directives are present but commented out, you may
need to remove the comment sign or change the value of the option). Comments
have been added to explain the less-obvious directives.
listen=YES
#We do NOT want to allow users to log in anonymously
anonymous_enable=NO
xferlog_enable=YES
#This is for the PAM service that we created that was named virtual-ftp
pam_service_name=virtual-ftp
#Enable the use of the /etc/vsftpd.user_list file
userlist_enable=YES
#Do NOT deny access to users specified in the /etc/vsftpd.user_list file
userlist_deny=NO
userlist_file=/etc/vsftpd.user_list
tcp_wrappers=YES
local_enable=YES
#This activates virtual users.
guest_enable=YES
#Map all the virtual users to the real user called "ftp"
guest_username=ftp
#Make all virtual users root ftp directory on the server to be /var/ftp/
private/local_root=/var/ftp/private/
11. We’ll need to create (or edit) the /etc/vsftpd.user_list file that was referenced in
the configuration in Step 10. To create the entry for the first virtual user, type
[root@serverA ~]# echo ftp-user1 > /etc/vsftpd.user_list
12. To create the entry for the second virtual user, type
[root@serverA ~]# echo ftp-user2 >> /etc/vsftpd.user_list
13. We are ready to fire up or restart the FTP server now. Type
[root@serverA ~]# service vsftpd restart
14. We will next verify that the FTP server is behaving the way we want it to by con-
necting to it as one of the virtual FTP users. Connect to the server as ftp-user1
(remember that the FTP password for that user is “user1”).
[root@serverA vsftpd]# ftp localhost
Connected to localhost (127.0.0.1).
220 (vsFTPd 2.0.8)
Name (localhost:root): ftp-user1
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -l
227 Entering Passive Mode (127,0,0,1,94,124).
150 Here comes the directory listing.
226 Directory send OK.
ftp> pwd
257 "/"
ftp> cd /boot
550 Failed to change directory.
ftp> bye
221 Goodbye.
15. We’ll also test to make sure that anonymous users cannot log into the server.
[root@serverA vsftpd]# ftp localhost
Connected to localhost (127.0.0.1).
220 (vsFTPd 2.0.8)
Name (localhost:root): ftp
530 Permission denied.
Login failed.
16. We’ll finally verify that local users (e.g., the user Ying Yang) cannot log into the
server.
[root@serverA vsftpd]# ftp localhost
Connected to localhost (127.0.0.1).
220 (vsFTPd 2.0.8)
Name (localhost:root): yyang
530 Permission denied.
Login failed.
Everything looks fine
The default out-of-the-box behavior of vsftpd is probably not what you want for your
production FTP server. So in this section we will walk through the process of custom-
izing some of the FTP server’s options to suit certain scenarios.
Setting Up an Anonymous-Only FTP Server
First we’ll set up our FTP server so that it does not allow access to users that have regular
user accounts on the system. This type of FTP server is useful for large sites that have
files that they want to make available to the general public via FTP. In such a scenario, it
is, of course, impractical to create an account for every single user when users can poten-
tially number into the thousands.
Fortunately for us, vsftpd is ready to serve as an anonymous FTP server out of the
box. But we’ll examine the configuration options in the vsftpd.conf file that ensure this
and also disable the options that are not required.
With any text editor of your choice, open up the /etc/vsftpd/vsftpd.conf file for edit-
ing. Look through the file and make sure that, at a minimum, the directives listed next
are present (if the directives are present but commented out, you might need to remove
the comment symbol [#] or change the value of the option).
listen=YES
xferlog_enable=YES
anonymous_enable=YES
local_enable=NO
write_enable=NO
You will find that the options in the preceding listing are sufficient to enable your
anonymous-only FTP server, and so you may choose to overwrite the existing /etc/ vsftpd/
vsftpd.conf file and enter just the options shown. This will help keep the configuration
file simple and uncluttered.
[root@serverA ~]# getent passwd ftp
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
If you don’t get output similar to this, you can quickly create the FTP system account with the
useradd command. To create a suitable ftp user, type
[root@serverA ~]# useradd -c "FTP User" -d /var/ftp -r -s /sbin/nologin ftp
If you had to make any modifications to the /etc/vsftpd/vsftpd.conf file, you need to
restart the vsftpd service. Type
[root@fedora-serverA ~]# service vsftpd restart
If the service command is not available on your Linux distribution, you may be
able to control the service by directly executing its run control script. For example, you
may be able to restart vsftpd by issuing the command
[root@serverA ~]# /etc/init.d/vsftpd restart
Setting Up an FTP Server with Virtual Users
Virtual users are users that do not actually exist; i.e., these users do not have any privi-
leges or functions on the system besides those for which they were created. This type of
FTP setup serves as a midway point between enabling users with local system accounts
access to the FTP server and enabling only anonymous users. If there is no way to guaran-
tee the security of the network connection from the user end (FTP client) to the server end
(FTP server), it will be foolhardy to allow users with local system accounts to log into the
FTP server. This is because the FTP transaction between both ends usually occurs in plain
text. Of course, this is only relevant if the server contains any data of value to its owners!
The use of virtual users will allow a site to serve content that should be accessible
to untrusted users, but still make the FTP service accessible to the general public. In the
event that the credentials of the virtual user(s) ever become compromised, one can at
least rest assured that only minimal damage can occur.
In this section we are going to create two sample virtual users named “ftp-user1”
and “ftp-user2.” These users will not exist in any form in the system’s user database (the
/etc/passwd file). These steps detail the process:
1. First we’ll create a plain-text file that will contain the username and password
combinations of the virtual users. Each username with its associated password
will be on alternating lines in the file. For example, for the user ftp-user1, the
password will be “user1,” and for the user ftp-user2, the password will be
“user2.” We’ll name the file plain_vsftpd.txt. Use any text editor of your choice
to create the file. Here we use vi:
[root@serverA ~]# vi plain_vsftpd.txt
2. Enter this text into the file:
ftp-user1
user1
ftp-user2
user2
3. Save the changes to the file, and exit the text editor.
4. Convert the plain-text file that was created in Step 2 into a Berkeley DB format
(db) that can be used with the pam_userdb.so library. The output will be saved
in a file called hash_vsftpd.db stored under the /etc directory. Type
[root@serverA ~]# db_load -T -t hash -f plain_vsftpd.txt /etc/hash_vsftpd.db
5. Restrict access to the virtual users database file by giving it more restrictive
permissions. This will ensure that it cannot be read by any casual user on the
system. Type
[root@serverA ~]# chmod 600 /etc/hash_vsftpd.db
6. Next we need to create a PAM file that the FTP service will use as the new vir-
tual users database file. We’ll name the file virtual-ftp and save it under the
/etc/pam.d/ directory. Use any text editor to create the file.
[root@serverA ~]# vi /etc/pam.d/virtual-ftp
7. Enter this text into the file:
auth required /lib/security/pam_userdb.so db=/etc/hash_vsftpd
account required /lib/security/pam_userdb.so db=/etc/hash_vsftpd
These entries tell the PAM system to authenticate users using the new database
stored in the hash_vsftpd.db file.
8. Save the changes into a file named virtual-ftp under the /etc/pam.d/ directory.
9. Let’s create a home environment for our virtual FTP users. We’ll cheat and use
the existing directory structure of the FTP server to create a subfolder that will
store the files that we want the virtual users to be able to access. Type
[root@serverA ~]# mkdir -p /var/ftp/private
10. Now we’ll create our custom vsftpd.conf file that will enable the entire setup.
With any text editor of your choice, open the /etc/vsftpd/vsftpd.conf file for edit-
ing. Look through the file and make sure that, at a minimum, the directives
listed next are present (if the directives are present but commented out, you may
need to remove the comment sign or change the value of the option). Comments
have been added to explain the less-obvious directives.
listen=YES
#We do NOT want to allow users to log in anonymously
anonymous_enable=NO
xferlog_enable=YES
#This is for the PAM service that we created that was named virtual-ftp
pam_service_name=virtual-ftp
#Enable the use of the /etc/vsftpd.user_list file
userlist_enable=YES
#Do NOT deny access to users specified in the /etc/vsftpd.user_list file
userlist_deny=NO
userlist_file=/etc/vsftpd.user_list
tcp_wrappers=YES
local_enable=YES
#This activates virtual users.
guest_enable=YES
#Map all the virtual users to the real user called "ftp"
guest_username=ftp
#Make all virtual users root ftp directory on the server to be /var/ftp/
private/local_root=/var/ftp/private/
11. We’ll need to create (or edit) the /etc/vsftpd.user_list file that was referenced in
the configuration in Step 10. To create the entry for the first virtual user, type
[root@serverA ~]# echo ftp-user1 > /etc/vsftpd.user_list
12. To create the entry for the second virtual user, type
[root@serverA ~]# echo ftp-user2 >> /etc/vsftpd.user_list
13. We are ready to fire up or restart the FTP server now. Type
[root@serverA ~]# service vsftpd restart
14. We will next verify that the FTP server is behaving the way we want it to by con-
necting to it as one of the virtual FTP users. Connect to the server as ftp-user1
(remember that the FTP password for that user is “user1”).
[root@serverA vsftpd]# ftp localhost
Connected to localhost (127.0.0.1).
220 (vsFTPd 2.0.8)
Name (localhost:root): ftp-user1
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -l
227 Entering Passive Mode (127,0,0,1,94,124).
150 Here comes the directory listing.
226 Directory send OK.
ftp> pwd
257 "/"
ftp> cd /boot
550 Failed to change directory.
ftp> bye
221 Goodbye.
15. We’ll also test to make sure that anonymous users cannot log into the server.
[root@serverA vsftpd]# ftp localhost
Connected to localhost (127.0.0.1).
220 (vsFTPd 2.0.8)
Name (localhost:root): ftp
530 Permission denied.
Login failed.
16. We’ll finally verify that local users (e.g., the user Ying Yang) cannot log into the
server.
[root@serverA vsftpd]# ftp localhost
Connected to localhost (127.0.0.1).
220 (vsFTPd 2.0.8)
Name (localhost:root): yyang
530 Permission denied.
Login failed.
Everything looks fine
Subscribe to:
Posts (Atom)