Home Page
Linux Basics Debian Linux Installation Using Debian Packages Linux Modem Setup Setting Up A Network Setting Up DNS Servers Linux Internet Servers Linux LAN Servers Linux Database Server Linux Syslog Server Linux Fax Server Linux Web Cam Servers Linux Proxy/NAT Servers Linux Firewall Servers Linux Security Compiling Linux Programs Home Automation What Now?

Linux Server and Network Security

The most dangerous threat to internal networks are Internet gateways. Gateways are systems (or other hardware devices) with a minimum of two network interfaces where one interface is connected to the Internet (via an ISP connection) and at least one interface is connected to an internal LAN segment. Just as a gateway allows traffic to go out from your LAN onto the Internet, it also allows traffic from the Internet onto your LAN. The trick is to only let the traffic you want onto your LAN, and it's no easy feat.

You could be legally liable if someone hacks their way into your LAN and steals confidential data (social security numbers, credit card numbers, etc) that you maintain on your clients or customers. Worms or trojans could be planted that send passwords or other sensitive information out onto the Internet to a waiting sniffer. The risks are many and the consequences could threaten the very existance of your company. It's not uncommon for large institutions like banks and insurance firms to decline pressing charges against a hacker simply because they don't want the negative press and loss of confidence they would suffer as the result of a public prosecution by a district attorney.

"Multi-homed" (multi-connection) systems such as gateways are not the only security risk. A server that is only connected to the Internet, such as a Web server, is also at risk of being hacked. You may not care if some hacker cracks his way in and defaces your Web pages. You just reload the pages. But there are other, more hideous, attacks that are not uncommon:

Addressing security issues is one of those cases where "an ounce of prevention is worth a pound of cure". A hacker could do untold damage if they get into your system or network. And because hackers learn their trade in underground electronic communities, if one finds a way into your system you can bet that they'll let everyone else know about it.

If your company has public address space with an available IP you may want to try a little test just for grins. Do a full-boat install of Debian (including all Internet-related apps you can think of) and put the system on the Internet. It doesn't need a domain name with a DNS record, just a static public IP address. Set it up with the Apache, Sendmail, wu_ftpd, telnet, and any other services running and just leave it sit there. Check the /var/log/messages file every week or so and see how long it takes for the hackers to find it and start playing around with it. When I tried this they took all of two weeks. Since there's no way of telling what they did during their visits, you'd be wise to totally wack the partitions on the hard-drive and do an install from scratch when you do want to re-use the system as a production server.

Setting up a system like this is actually a new security tool that's emerging. It's called setting up a "honey-pot". The hackers are drawn to the the honey-pot because it's the most responsive, and are drawn away from your production servers. Before you deploy your honey-pot you may want to hang a tape drive on the system and do a full backup so you can go back to square one once it gets compromised. Again, thre's no way to really know everything that a hacker may have done to your system once they get in so the only safe thing to do is start over. Monitoring your honey-pot on a regular basis will let you know when things are happening so you can keep an even closer eye on your production servers.

Don't always assume that the "untrusted" network you're trying to protect yourself from is the Internet. If you have VPNs or other types of network connectivity established with business partners or even other divisions within the same company, you must be watchful for unauthorized access attempts from these networks as well. "Trust no one" is a good rule to follow when it comes to system and network security.

Do Your Homework Top of page

Along with the benefits of having your own Internet servers comes the responsibility of being knowledgable on how to secure those servers. Covering this subject beyond anything other than a superficial manner is beyond the scope of any single Web page. Here we only present an overview of some of the common tools used to help secure an Internet-connected server. It is by no means comprehensive and should only serve as an introduction to the topic.

Security measures can be categorized into the following four broad classifications:

  1. OS configuration - "hardening" the operating system
  2. Application configuration - making sure the server applications you do make available do only what they're supposed to do
  3. Perimeter security - configuring your network infrastructure with firewalls and DMZs
  4. Physical security - only authorized users and systems should have access to the network infrastructure
Different publications may categorize things differently but that's of little consequence. The important thing is that doing so allows you to take a "divide and conquer" approach to addressing all of the various aspects involved in securing a network, its servers, and the information contained on them.

OS Configuration

Hardening the operating system involves many things are are not only operating system-specific, but may often vary from one "flavor" of an operating system to another. Typical steps include:

There is a HOWTO on securing the OS on the Debian Web site at:


The installation routines for many Linux distributions set things wide open by default to reduce the number of technical support calls and e-mails they get. (The more wide open a system is the less likely it is that someone - or an application - will run into problems trying to perform a specific task or function.) As a result, most Linux systems are inherently insecure. Once you do make security-related changes, check to make sure that all functions of your applications still run the way they should.

Where to learn more - The best of our bookshelves:

Maximum Linux Security
More info...
    Maximum Linux Security is the best security book I've found for those who do not have a lot of Linux experience. The first four chapters cover some of the basics of Linux from a security perspective, including the fundamentals of server administration. If you are going to set up an Internet server, get this book. The book not only covers what to do, but covers the theory behind why you are doing it. It also shows you how hackers work and provides links to the tools they use to break in. You would think that a book on server security would be pretty dry, but this book is an easy read.

Application Configuration

Some applications are insecure due to the defaults used during their installations and some are just inherently insecure. Telnet and ftp are two inherently insecure applications because passwords are transmitted over the wire as clear text.

The biggest threat to many applications is their vulnerability to "buffer overflow" attacks which usually results in the hacker having access to the system with the rights of whatever user account the application was running under.

The following are some general guidelines related to applications:

If all you want to do is set up a simple Web server (running Apache) then there are quite a few "applications" (OS utilities actually) that run by default that are not needed. They open ports and since each open port is a possible entry point into your server by a hacker, you don't want them open. I disable them by renaming their 'S' (startup) symlinks in the appropriate runlevel directory. Since Debian boots into runlevel 2 by default, we want to go into the runlevel 2 startup directory with the command:

cd /etc/rc2.d

There we'll find the symlink S20ssh which opens the port for secure remote console sessions. If you'll be physically at the console (keyboard and monitor), there is no need for remote access. To stop the SSH server service from needlessly opening a port we disable it by just renaming its symlink with the command:

mv S20ssh _S20ssh

You can do the same for S20exim4, S20lpd, and S21nfs-common. Now if you reboot your system and run the netstat -a command you'll see fewer open ports. One port that does remain open though is 'sunrpc'. That's the RPC portmap service and it is notorious for being the target of exploits. If you run the netstat -ap command you'll see that '/sbin/portmap' is the application that has the sunrpc port (port 111) open. NFS and some other applications need the RPC service. Apache does not. So for our simple Web server we can disable portmap. However, this service is called from two places so we need to rename both symlinks with the commands:

mv /etc/rc2.d/S18portmap /etc/rc2.d/_S18portmap
mv /etc/rcS.d/S43portmap /etc/rcS.d/_S43portmap

Note that disabling RPC will cause the 'nfs-common' service to fail at boot-up but that's OK. You shouldn't be mounting any network drives on a Web server anyway.

Now if you again reboot your system and run the netstat -a command you'll see only port 80 open (and possibly port 25 listening on which is internal only).

Other daemons and services don't open ports but they're not needed either and they just use up memory. Two examples in the default installation that you can also rename are S89atd and, if your system isn't connected directly to a cable or DSL modem that uses PPPoE, S14ppp.

Because applications interact with the operating system, start processes, and accept input they can affect operating system security. Likewise, operating system security can affect an application's ability to function properly. Achieving maximum OS security while still retaining full application functionality is a balancing act.

This balancing act is evident when using "jails" or chroot jails. You can put any program or daemon in it's own jail. A chroot jail is a way of configuring the operating system so that the directory the application is running from appears to be the root of the entire file system. As such, the only directories the application can "see" or has access to are the ones it needs to run. That way, if an application does have a security flaw, the hacker exploiting that flaw won't have access to the entire file system.

For example, if you want to set up a DNS server be advised that BIND runs as root. As such, if a hacker exploited a security flaw in BIND they would have root access to the entire file system. By running BIND in a jail, the hacker would only have access to the BIND application directory.

The problem with jails is that they can be a pain to set up. ALL files that an application needs (library files, config files, etc.) or generates (data files, log files) have to reside within the jail. So if you were going to set up a jail for BIND in /var/lib/named you'd have to create /var/lib/named/etc (for config files) and /var/lib/named/var (for log files) directories under that directory. You also then need to create a user for the application and change ownership of the directories to that user. It may be a pain but it does isolate your file system considerably.

Securing Apache

This discussion of mod_security refers to mod_security 2.x on Apache 2.x.
mod_security 2.x only works with Apache 2.x. It is not backward compatible with Apache 1.x.

Back on our Internet Servers page we showed you how to change a couple security settings to reduce the amount of information about your server that is given out to potential hackers. However, this doesn't do anything for HTTP-targeted attacks.

If your firewall is properly configured to only allow port 80 traffic to your Web server there are still dangers that can come in on port 80, the most common being malformed URLs. There's an Apache IDS (Intrusion Detection System) module that can keep an eye out for suspicious and malformed requests and block them.

Depending on the version of Debian you have this module may already be installed and enabled. If it is, there is still one tweak you need to make. Check you enabled modules with the command:

ls /etc/apache2/mods-enabled

and look for the security2.load file (along with the .conf file). If it's there you want to fully enable the modules capabilities with the command:

mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Note that all you're doing is removing the '-recommended' from the file name so the file gets read when Apache loads. That's all you need to do (other than restarting Apache) if the module was already installed and enabled.

If you didn't have any 'security2' modules enabled above you'll need to install and enable the module manually. Enter the command:

apt-get install libapache2-mod-security2

This will not only add the module files to the /etc/apache2/mods-available directory but also adds the sym link to it in the /etc/apache2/mods-enabled directory and restarts Apache. Unfortunately that doesn't do us much good because there is no configuration file yet.

Below is a sample mod_security configuration file which you can use as is. The first part of the file configures the module's operation while the second part of the file adds the filtering rules it should use. You can copy/paste the following into a file with a name like "mod-security.conf" and then FTP that file (using ASCII mode) to your server.

Note that there are drastic differences between mod_security 1.x
configuration statements and mod_security 2.x configuration statements.
Most configuration examples available on the Web are for version 1.x.
The example below is for 2.x because that's the version available on
the package maintainer's site. If you want to customize your
configuration be sure to use the 2.x statements.

<IfModule security2_module>

  # Turn the filtering engine On
  SecRuleEngine On
  # Only log suspicious requests
  SecAuditEngine RelevantOnly
  # The name of the audit log file
  SecAuditLog /var/log/apache2/modsec_audit.log
  # Debug level set to a minimum (0) - 9 is max
  SecDebugLogLevel 0
  SecDebugLog /var/log/apache2/modsec_debug.log
  # Should mod_security inspect POST payloads
  SecRequestBodyAccess On
  # By default log and deny suspicious requests
  # with HTTP status 403
  SecDefaultAction deny,log,status:403,phase:2 

  SecRule REQUEST_URI /etc/passwd
  SecRule REQUEST_URI /bin/ls
  SecRule REQUEST_URI /bin/uname
  SecRule REQUEST_URI /usr/bin/whoami
  SecRule REQUEST_URI cd\x20/tmp
  SecRule REQUEST_URI wget\x20
  # Make sure that URL encoding is valid
  SecRule ARGS "@validateUrlEncoding"
  # Unicode encoding check
  SecRule ARGS "@validateUtf8Encoding"
  # Only allow bytes from this range
  SecRule ARGS:text "@validateByteRange 0 255"
  # Block Santy.A worm
  SecRule ARGS:highlight %27
  # Block drop table SQL injection attack
  SecRule REQUEST_URI "drop[[:space:]]table"
  # Only accept request encodings we know how to handle
  # we exclude GET requests from this because some (automated)
  # clients supply "text/html" as Content-Type
  SecRule REQUEST_METHOD "!^(GET|HEAD)$" chain
  SecRule REQUEST_HEADERS:Content-Type \
  # Do not accept GET or HEAD requests with bodies
  SecRule REQUEST_METHOD "^(GET|HEAD)$" chain
  SecRule REQUEST_HEADERS:Content-Length "!^$"
  # Require browser headers from all user agents
  # Require Content-Length to be provided with every POST request
  SecRule REQUEST_METHOD "^POST$" chain
  SecRule REQUEST_HEADERS:Content-Length "^$"
  # Don't accept transfer encodings we know we don't handle
  SecRule REQUEST_HEADERS:Transfer-Encoding "!^$"


Once you get the file FTPed up to your server copy it into the /etc/apache2/conf.d directory so that Apache reads it when it starts. Don't forget to restart Apache after getting this file in place with the command:

/etc/init.d/apache restart

You can test it out to make sure it's working by entering a URL which contains the text of one of the "SecRule REQUEST_URI" entries. For example, if your server's IP address is enter the following in a browser's address bar:

You should get the Apache "Forbidden" error page.

You can write a lot of your own rules, including only allowing certain types of traffic from certain addresses. If you want to allow for special access and get granular with your access control, check out the documentation at modsecurity.org.

Blocking Countries

You can use mod_security to also block Web site traffic from specific countries such as China and Russia. This is a lot less resource-intenstive alternative than using a .htaccess file to block such traffic. Mod_security has built-in support for using a free GeoIP database from maxmind.com. Since you'll want to update this database monthly we'll put the commands in a shell script and run that rather than entering the commands at a shell prompt.

You should still be in the /etc/modsecurity directory. Assuming you're logged in as root type in:

nano /root/geoipdb.sh

and enter the following commands:

cd /etc/modsecurity
wget -N http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
gzip -df GeoIP.dat.gz

Press Ctrl-X and 'y' to save the file and exit the editor. Then set the file as executable with the command:

chmod 700 geoipdb.sh

Later we'll show you how to run this shell script automatically to update the database on a monthly basis. For now run it manually with the command


and you should have the file GeoIP.dat in the /etc/modsecurity directory. Now we need to edit the mod_security configuration file with the command:

nano modsecurity.conf

Arrow down to the bottom of the file and add the following commands:

# Test IP address and block by country code
SecGeoLookupDb /etc/modsecurity/GeoIP.dat
SecRule REMOTE_ADDR "@geoLookup" "phase:1,chain,id:10,drop,log,msg:'Blocking Country IP Address'"

Again press Ctrl-X and 'y' to save the file and exit the editor. The CN RU KP in the last statement represents China, Russia, and North Korea. You can enter the country codes for other contries as well. To activate the new mod_security configuration reload Apache with the command:

/etc/init.d/apache restart

You can see if mod_security is active by looking at the log file with the command:

cat /var/log/apache2/modsec_audit.log

and you should see entries indicating that site access were blocked.

Perimeter Security

The most common means of protecting a network is using a firewall (or two in the case of a DMZ which was illustrated back on the Firewall page). The biggest problem with firewalls is that people think they're more than they actually are. A firewall's major strength is protecting against traffic-based attacks (DoS, etc). If you let people into your network from the outside, the firewall has no way of differentiating between a legitimate user and a hacker. A firewall is not a substitute for strong OS and application security.

If you're going to use a firewall package on a Debian system, keep in mind that the firewall is the application. As such, a system-based firewall won't offer much security if the underlying OS isn't hardened. (This is why the NetMax commercial firewall product includes the OS piece. It allows them to ensure the OS is properly configured.)

If you want to have Internet servers or provide remote access using a VPN server, be sure to use a DMZ configuration with two firewalls. In cases where critical or confidential business information is at risk, use stateful firewalls and IDS (Intrusion Detection System) software.

An IDS has been referred to as the burglar alarm of the network. See our Snort page on how to set one up.

Physical Security

Unauthorized access to your servers can occur just as easily from the inside as the outside. Perhaps even more so since the internal organization is seen as less of a threat. While that may be (somewhat) true from a user perspective, the unauthorized use of the organization's facilities and hardware is a very real threat.

To most people, physical security means locking up the server hardware and hubs/switches. However, it goes far beyond that. It involves the entire physical plant, the systems that connect to it, and the office space those systems are located in. It even extends to the notebooks carried by your company's road warriors. Notebooks and PDAs get stolen all the time. And there's no telling who has access to the computers of those who dial-in from home where users have a tendency to check the "Remember password" box on their dial-up connections.

I have seen countless instances of organizations that spend all kinds of money on fancy security systems surrounding the rooms that house servers and other IT equipment and at the same time have network jacks in locations that anyone can get to without breaking a sweat. Someone could hook up a pocket-sized packet sniffer and in less than a minute have all the IP address information and maybe even some IDs and passwords they need. With all of the foot traffic in large companies at quitting time, it wouldn't take much for someone with a notebook to slip into a secluded office or cubicle and spend hours on your network with no one but the cleaning people to bother them.

Networks, by their very nature, mean you don't need to be phsically at a server to administrate that server. While IT operations typically don't have a lot of clout with a facility's security people, there are some infrastructure-related steps you can take to try and lock things down. Unplugging unused or publically-accessible network jacks at the cross-connects is one measure. Restricting users to logging in only on certain systems, whether they be identified by MAC address or a hostname, and only during certain hours is a start. Security-minded organziations are also setting up VPNs on internal networks and requiring that all Intranet Web traffic be SSL to guard against unauthorized sniffing.

And how many users do you know have their passwords written down on Post-It Notes stuck to their monitor or on a piece of paper inside a desk drawer? Biometric devices have dropped dramatically in price in the last two years. You can buy a hardware device that reads a fingerprint in order to authenticate users for a little over $100 now (U.are.U Pro from Digital Persona). Setting up certificate servers helps ensure that only authorized systems have access to network resources. They're not just for remote systems anymore.

That's not to say physical security of the servers and wiring closets isn't important. Just don't overlook the obvious. One organization was so proud of their fire-proof file room for all of their personnel records until I pointed out the room had a wooden door. A chain is only as strong as its weakest link. Do the doors to your server room or wiring closets open out? If so, it's probably just a matter of popping the hinge pins out and a door comes right off. Crawling over the top of a wall by popping out the panels in a suspended ceiling isn't all that tough either.

There are many steps you can take to secure the physical environment. Some are electronic, some are mechanical, and others are procedural. But nothing substitutes for common sense.

Be Proactive Top of page

Security is not a "set it and forget it" proposition. Because there are no absolutes, constant monitoring is essential. New attacks are being developed every day and if you're simply going to respond once an attack is discovered it's likely too late. Hackers will use DoS attacks, log alterations (provided they can gain access), and other means to disguise other, more intrusive, exploits. In many cases simply waiting for obvious evidence that you've been hacked means you'll never know you've been hacked. The hackers will sneak in, grab what they want, and sneak back out again covering their tracks as they go.

In short, any security plan that is reactive rather than proactive is pretty lame. In addition to the security measures mentioned above, there are several things you can do to be more proactive in ensuring security:

Where to learn more - The best of our bookshelves:

Hacking Linux Exposed
More info...
    My first reaction to Hacking Linux Exposed was "Oh great, now there'll be a million more hackers trying to get into our systems". It's a veritable tutorial, including step-by-step commands, on how to use a gazillion different exploits to hack into systems. However, after further consideration we realized this book is a great resource. It not only tells you how to do things (so you can see if you can when going against your systems), but gives specific countermeasures to mitigate the risks. It also gives each exploit individual ratings for simplicity, popularity, and impact and then combines them into an overall "risk rating". Comprehensive is the one word that best describes this book. For instance, it doesn't just cover Web servers but gets into CGI and SSI threats as well. Information on how to obtain a lot of the hacking tools that are available is also given.

Patching Your System Top of page

Debian's package system makes it real easy to keep your system up-to-date. Once you get your system set up just the way you want it you'll want to apply security patches on a regular basis. We'll show you how to automate the security patching process later in this page.

The first thing you should do is check the sources.list file that apt uses to determine from where it should pull updates.
As mentioned on the Installation page, many organizations don't allow their servers to be Internet-accessible for security reasons. If this is the case with your server, you have no choice but to do point-release updates using discs and should not follow this procedure.
Open the sources.list file in the nano text editor with the command:

nano /etc/apt/sources.list

You'll see a line like the following for each DVD in your set:

deb cdrom:[name of dvd-rom]

Look further down in the file for lines that start with the following:

deb http://security.debian.org
deb-src http://security.debian.org
deb http://ftp.debian.org
deb-src http://ftp.debian.org

If there are # characters in front of these lines remove them to un-comment the lines. Then exit the editor (by pressing Ctrl-X and then, if you had to un-comment that line, press 'y' and then Enter) saving the change to the file.
The first thing you need to do us update your package library database with information on what the current versions of packages are. Do that with the command:

apt-get update

You can apply the latest security patches to your system with the following command:

apt-get upgrade -u

The -u in the above command just makes the process a little more verbose, displaying package names as they're downloaded and installed.

Note:  The above procedure only updates applications that were installed as a Debian package. If you installed applications that were not in Debian packages (such as when you download the source code files from a Web site and compile/install it yourself), it will have to be updated separately.

Automating Security Patching Top of page

Automatically applying security patches will help ensure you're protected against the latest worms and exploits. Automating the process of retreiving and applying security patches is not hard at all. The cron memory-resident scheduler is loaded by default when the system boots so it's just sitting there waiting for you to use it. Automating a process involves two steps; giving cron something to run (i.e. creating a shell script containing the commands you want to run), and then telling cron when to run it.

You create a shell script using a standard text editor. Create the new shell script with the command:

nano /usr/local/security-patches.sh

and enter the following commands:

/usr/bin/apt-get update
/usr/bin/apt-get upgrade
/sbin/shutdown -r

Note:  When cron jobs run they run as the cron user which has a very limited PATH in its environment. Be sure to preceed all commands with the paths to the commands. To find out the path to a command you can use the whereis command followed by the name of the command. For example:

whereis apt-get

Normally when you patch a daemon you'll want to restart that daemon to make sure the patches take effect. However, since you won't know which daemon got patched with this automated process there's no way to know which daemons to restart so simply restarting the system is the safest way to go.

Save the file (Ctrl-X, y, Enter) and then change the permissions to make it executable using the command:

chmod 755 /usr/local/security-patches.sh

This is a very basic script. You'll probably want to set up some 'if' statements which test to make sure you got connected and check the success of the apt-get command.

How can you check to see if apt-get executed successfully? DOS had an ERRORLEVEL environment variable you could check the value of to determine the success of a command. In Linux/UNIX it's called the "exit status" and the ? represents this environment variable. Entering the command:

echo $?

will display the exit status of the most recently run command. (Remember that you have to put the $ in front of an environment variable when referring to its value as with the echo command or the when using an 'if' statement in a shell script.) A zero indicates success (just remember "zero errors") and anything greater than a zero represents some kind of problem.


Now we tell cron when to run it.

cron is the memory-resident scheduler daemon that can execute commands and scripts at regular intervals. The jobs it runs are listed in a crontab file which is edited using the crontab utility.

The following command will list, if there is one, the contents of your current crontab file:

crontab -l

You'll want to add an entry to the crontab file for the security-patches.sh shell script. The format of the file is basically:

<when-to-run values> <what to run>

The "when to run" is a field which consists of five space-delimited values in the following order:

  • Minutes past the hour   (0 to 59)
  • Hour of the day   (0 to 23)
  • Day of the month   (1 to 31)
  • Month of the year   (1 to 12)
  • Day of the week   (0=Sunday to 6=Saturday)
You can use the asterisk (*) to specify all values for any given entry. For example, to run a job every Saturday at 11:15 pm you would use the following values:

15 23 * * 6

Be careful with these values. You'd rarely want to enter a number for the "Day of the Month" and the "Day of the Week". For example, if you entered:

15 23 3 * 6

cron would only run the job when the 3rd falls on a Saturday.

You can enter multiple values for each entry by separating them with commas. We set up cron jobs to check the logs twice a day, every weekday, at noon and again at 5 pm. This required the following values:

0 12,17 * * 1,2,3,4,5

Remember that the space is the delimiter between the five entries.

The "what to run" is what you want to cron to execute and is basically anything you can enter at a shell prompt. Any command, including pipes and redirects, shell script, etc. Since we want to run the security-patches.sh shell script, which we saved to the /usr/local directory, our crontab entry ends up looking like this:

0 3 * * 0 /usr/local/security-patches.sh

Note that only a space separates the "what to run" value from the last of the "when to run" values. The "when to run values above will run the security-patches.sh shell script every Sunday morning at 3 a.m.

So now that we know what our entry will be, we have to use crontab to enter it into the crontab file. At the shell prompt, enter:

crontab -e

If you get prompted to choose an editor select nano. The current crontab file automatically gets loaded and is most likely empty. Simply enter your new crontab entry. If you want to also create a cron job to automatically update the GeoIP database that we downloaded earlier you'll also want to add this entry to your crontab file:

0 23 10 * * /root/geoipdb.sh

An updated version of the GeoIP database gets released during the first week of every month. This entry run the batch file we created above at 11pm on the 10th of every month.

Close the editor with Ctrl-X and 'y' saving the file. You can check to make sure your entry was added to the crontab file by entering the following command at the shell prompt:

crontab -l
Note that you do not have to be logged into the console for cron jobs to run.

Security has become an ever-growing aspect of network administration and this growth shows no signs of abating. Vigilance is as important a quality as technical expertise. Exercise it like your professional life depends on it, because it may.

Did you find this page helpful ?
If so, please help keep this site operating
by using our DVD or book pages.

Site, content, documents, original images   Copyright © 2003-2016   Keith Parkansky   All rights reserved
Duplication of any portion of this site or the material contained herein without
the express written consent of Keith Parkansky, USA is strictly prohibited.

This site is in no way affiliated with the Debian Project, the debian.org Web site, or
Software In The Public Interest, Inc. No endorsement of this site by the Debian Project
or Software In the Public Interest is expressed or implied. Debian and the Debian logo
are registered trademarks of Software In The Public Interest, Inc. Linux is a registered
trademark of Linus Torvalds. The Tux penguin graphic is the creation of Larry Ewing.