[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ next ]
You should strive to keep your system secure by monitoring its usage and also the vulnerabilities that might affect it, patching them as soon as patches are available. Even though you might have installed a really secure system initially you have to remember that security in a system degrades with time, security vulnerabilities might be found for exposed system services and users might expose the system security either because of lack of understanding (e.g. accessing a system remotely with a clear-text protocol or using easy to guess passwords) or because they are actively trying to subvert the system's security (e.g. install additional services locally on their accounts).
Although most administrators are aware of security vulnerabilities affecting their systems when they see a patch that is made available you can strive to keep ahead of attacks and introduce temporary countermeasures for security vulnerabilities by detecting when your system is vulnerable. This is specially true when running an exposed system (i.e. connected to the Internet) and providing a service. In such case the system's administrators should take care to monitor known information sources to be the first to know when a vulnerability is detected that might affect a critical service.
This typically includes subscribing to the announcement mailing lists, project
websites or bug tracking systems provided by the software developers for a
specific piece of code. For example, Apache users should regularly review
Apache's lists of
security vulnerabilities and subscribe to the Apache Server
Announcements mailing list.
In order to track known vulnerabilities affecting the Debian distribution, the
Debian Testing Security Team provides a security tracker that
lists all the known vulnerabilities which have not been yet fixed in Debian
packages. The information in that tracker is obtained through different public
channels and includes known vulnerabilities which are available either through
security vulnerability databases or Debian's Bug Tracking system.
Administrators can search for the known security issues being tracked for
stable,
oldstable,
testing,
or unstable.
The tracker has searchable interfaces (by CVE name and package name) and some
tools (such as debsecan, see Automatically
checking for security issues with debsecan, Section 10.1.2.4) use that
database to provide information of vulnerabilities affecting a given system
which have not yet been addressed (i.e. those who are pending a fix).
Concious administrators can use that information to determine which security bugs might affect the system they are managing, determine the severity of the bug and apply (if available) temporary countermeasures before a patch is available fixing this issue.
Security issues tracked for releases supported by the Debian Security Team
should eventually be handled through Debian Security Advisories (DSA) and will
be available for all users (see Continuously
update the system, Section 10.1.2). Once security issues are fixed through
an advisory they will not be available in the tracker, but you will be able to
search security vulnerabilities (by CVE name) using the security cross references
table available for published DSAs.
Notice, however, that the information tracked by the Debian Testing Security Team only involves disclosed vulnerabilities (i.e. those already public). In some occasions the Debian Security Team might be handling and preparing DSAs for packages based on undisclosed information provided to them (for example, through closed vendor mailing lists or by upstream maintainers of software). So do not be surprised to find security issues that only show up as an advisory but never get to show up in the security tracker.
You should conduct security updates frequently. The vast majority of exploits
result from known vulnerabilities that have not been patched in time, as this
paper by Bill
Arbaugh (presented at the 2001 IEEE Symposium on Security and
Privacy) explains. Updates are described under Execute a security update, Section
4.2.
Debian does have a specific tool to check if a system needs to be updated but many users will just want to manually check if any security updates are available for their system.
If you have configured your system as described in Execute a security update, Section 4.2 you just need to do:
# apt-get update
# apt-get upgrade -s
[ ... review packages to be upgraded ... ]
# apt-get upgrade
# checkrestart
[ ... restart services that need to be restarted ... ]
And restart those services whose libraries have been updated if any. Note: Read Execute a security update, Section 4.2 for more information on library (and kernel) upgrades.
The first line will download the list of packages available from your configured package sources. The -s will do a simulation run, that is, it will not download or install the packages but rather tell you which ones should be downloaded/installed. From the output you can derive which packages have been fixed by Debian and are available as a security update. Sample:
# apt-get upgrade -s
Reading Package Lists... Done
Building Dependency Tree... Done
2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
In this example, you can see that the system needs to be updated with new
cvs and cupsys packages which are being retrieved
from woody's security update archive. If you want to understand why
these packages are needed, you should go to http://security.debian.org and
check which recent Debian Security Advisories have been published related to
these packages. In this case, the related DSAs are DSA-233 (for
cvs) and DSA-232 (for
cupsys).
Notice that you will need to reboot your system if there has been a kernel upgrade.
Since Debian 4.0 lenny Debian provides and installs in a default
installation update-notifier. This is a GNOME application that
will startup when you enter your Desktop and can be used to keep track of
updates available for your system and install them. It uses
update-manager for this.
In a stable system updates are only available when a security patch is available or at point releases. Consequently, if the system is properly configured to receive security updates as described in Execute a security update, Section 4.2 and you have a cron task running to update the package information you will be notified through an icon in the desktop notifcation area.
The notification is not intrusive and users are not forced to install updates. From the notification icon a desktop user (with the administrator's password) can access a simple GUI to show available updates and install them.
This application works by checking the package database and comparing the
system with its contents. If the package database is updated periodically
through a cron task then the contents of the database will be
newer than the packages installed in the system and the application will notify
you.
Apt installs such a task (/etc/cron.d/apt) which will
run based on Apt's configuration (more specifically APT::Periodic).
In the GNOME environment this configuration value can be adjusted by going to
System > Admin > Software origins > Updates, or running
/usr/bin/software-properties.
If the system is set to download the packages list daily but not download the
packages themselves your /etc/apt/apt.conf.d/10periodic should
look like this:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
You can use a different cron task, such as the one installed by
cron-apt (see Automatically checking for
updates with cron-apt, Section 10.1.2.3). You can also just manually check
for upgrades using this application.
Users of the KDE desktop environment will probably prefer to install
adept and adept-notifier instead which offers a
similar functionality but is not part of the standard installation.
Another method for automatic security updates is the use of
cron-apt. This package provides a tool to update the system at
regular intervals (using a cron job), and can also be configured to send mails
to the system administrator using the local mail transport agent. It will just
update the package list and download new packages by default but it can be
configured to automatically install new updates.
Notice that you might want to check the distribution release, as described in Per distribution release check, Section 7.5.3, if you intend to automatically updated your system (even if only downloading the packages). Otherwise, you cannot be sure that the downloaded packages really come from a trusted source.
More information is available at the Debian Administration
site.
The debsecan program evaluates the security status of by reporting
both missing security updates and security vulnerabilities. Unlike
cron-apt, which only provides information related to security
updates available, but this tool obtains information from the security
vulnerability database maintained by the Debian Security Team which includes
also information on vulnerabilities which are not yet fixed through a security
update. Consequently, it is more efficient at helping administrators track
security vulnerabilities (as described in Tracking
security vulnerabilities, Section 10.1.1).
Upon installing the Debian package debsecan, and if the
administrator consents to it, it will generate a cron task that will make it
run and send the output to a specific user whenever it finds a vulnerable
package. It will also download the information from the Internet. The
location of the security database is also part of the questions ask on
installation and are later defined /etc/default/debsecan, it can
be easily adjusted for systems that do not have Internet access so that they
all pull from a local mirror so that there is a single point that access the
vulnerability database.
Notice, however, that the Security Team tracks many vulnerabilities including
low-risk issues which might not be fixed through a security update and some
vulnerabilities initially reported as affecting Debian might, later on, upon
investigation, be dismissed. Debsecan will report on all the
vulnerabilities, which makes it a quite more verbose than the other tools
described above.
More information is available at the author's siste.
There is also the apticron, which, similarly to
cron-apt will check for updates and send mails to the
administrator. More information on apticron is available at the Debian Administration
site.
You might also want to take a look at secpack which is an
unofficial program to do security updates from security.debian.org with
signature checking written by Fruhwirth Clemens. Or to the Nagios Plugin
check_debian_updates.sh
written by Dean Wilson.
Unless you want to dedicate time to patch packages yourself when a vulnerability arises, you should not use Debian's unstable branch for production-level systems. The main reason for this is that there are no security updates for unstable (see How is security handled for testing and unstable?, Section 12.3.8).
The fact is that some security issues might appear in unstable and not in the stable distribution. This is due to new functionality constantly being added to the applications provided there, as well as new applications being included which might not yet have been thoroughly tested.
In order to do security upgrades in the unstable branch, you might have to do full upgrades to new versions (which might update much more than just the affected package). Although there have been some exceptions, security patches are usually only back ported into the stable branch. The main idea being that between updates, no new code should be added, just fixes for important issues.
Notice, however, that you can use the security tracker (as described in Tracking security vulnerabilities, Section 10.1.1) to track known security vulnerabilities affecting this branch.
If you are using the testing branch, there are some issues that you must take into account regarding the availability of security updates:
When a security fix is prepared, the Security Team backports the patch to stable (since stable is usually some minor or major versions behind). Package maintainers are responsible for preparing packages for the unstable branch, usually based on a new upstream release. Sometimes the changes happen at nearly the same time and sometimes one of the releases gets the security fix before. Packages for the stable distribution are more thoroughly tested than unstable, since the latter will in most cases provide the latest upstream release (which might include new, unknown bugs).
Security updates are available for the unstable branch usually when the package maintainer makes a new package and for the stable branch when the Security Team make a new upload and publish a DSA. Notice that neither of these change the testing branch.
If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days. The time this takes is usually ten days, although that depends on the upload priority of the change and whether the package is blocked from entering testing by its dependency relationships. Note that if the package is blocked from entering testing the upload priority will not change the time it takes to enter.
This behavior might change based on the release state of the distribution. When a release is almost imminent, the Security Team or package maintainers might provide updates directly to testing.
Additionally, the Debian Testing Security
Team can issue Debian Testing Security Advisories (DTSAs) for
packages in the testing branch if there is an inmediate need to fix a
security issue in that branch and cannot wait for the normal procedure (or the
normal procedure is being blocked by some other packages).
Users willing to take advantage of this support should add the following lines
to their /etc/apt/sources.list (instead of the lines described in
Execute a security update, Section
4.2):
deb http://security.debian.org testing/updates main contrib non-free
# This line makes it possible to donwload source packages too
deb-src http://security.debian.org testing/updates main contrib non-free
For additional information on this support please read the announcement.
This support officially started in September
2005 in a separate repository and was later integrated into the main
security archive.
First of all, automatic updates are not fully recommended, since administrators should review the DSAs and understand the impact of any given security update.
If you want to update your system automatically you should:
Configure apt so that those packages that you do not want to
update stay at their current version, either with apt's
pinning feature or marking them as hold with
dpkg or dselect.
To pin the packages under a given release, you must edit
/etc/apt/preferences (see apt_preferences(5)) and
add:
Package: *
Pin: release a=stable
Pin-Priority: 100
FIXME: verify if this configuration is OK.
Either use cron-apt as described in Automatically checking for updates with cron-apt, Section
10.1.2.3 and enable it to install downloaded packages or add a
cron entry yourself so that the update is run daily, for example:
apt-get update && apt-get -y upgrade
The -y option will have apt assume 'yes' for all the
prompts that might arise during the update. In some cases, you might want to
use the --trivial-only option instead of the
--assume-yes (equivalent to -y).[66]
Configure debconf so no questions will be asked during upgrades,
so that they can be done non-interactively. [67]
Check the results of the cron execution, which will be mailed to
the superuser (unless changed with MAILTO environment variable in
the script).
A safer alternative might be to use the -d (or
--download-only) option, which will download but not install the
necessary packages. Then if the cron execution shows that the
system needs to be updated, it can be done manually.
In order to accomplish any of these tasks, the system must be properly configured to download security updates as discussed in Execute a security update, Section 4.2.
However, this is not recommended for unstable without careful analysis, since you might bring your system into an unusable state if some serious bug creeps into an important package and gets installed in your system. Testing is slightly more secure with regard to this issue, since serious bugs have a better chance of being detected before the package is moved into the testing branch (although, you may have no security updates available whatsoever).
If you have a mixed distribution, that is, a stable installation with
some packages updated to testing or unstable, you can fiddle
with the pinning preferences as well as the --target-release
option in apt-get to update only those packages that you
have updated.[68]
Based on the baseline information you generated after installation (i.e. the snapshot described in Taking a snapshot of the system, Section 4.18), you should be able to do an integrity check from time to time. An integrity check will be able to detect filesystem modifications made by an intruder or due to a system administrators mistake.
Integrity checks should be, if possible, done offline.[69] That is, without using the operating system of the system to review, in order to avoid a false sense of security (i.e. false negatives) produced by, for example, installed rootkits. The integrity database that the system is checked against should also be used from read-only media.
You can consider doing integrity checks online using any of the filesystem integrity tools available (described in Checking file system integrity, Section 4.16.3) if taking offline the system is not an option. However, precaution should be taken to use a read-only integrity database and also assure that the integrity checking tool (and the operating system kernel) has not been tampered with.
Some of the tools mentioned in the integrity tools section, such as
aide, integrit or samhain are already
prepared to do periodic reviews (through the crontab in the first two cases and
through a standalone daemon in samhain) and can warn the
administrator through different channels (usually e-mail, but
samhain can also send pages, SNMP traps or syslog alerts) when the
filesystem changes.
Of course, if you execute a security update of the system, the snapshot taken for the system should be re-taken to accommodate the changes done by the security update.
Debian GNU/Linux includes tools for intrusion detection, which is the practice of detecting inappropriate or malicious activity on your local system, or other systems in your private network. This kind of defense is important if the system is very critical or you are truly paranoid. The most common approaches to intrusion detection are statistical anomaly detection and pattern-matching detection.
Always be aware that in order to really improve the system's security with the introduction of any of these tools, you need to have an alert+response mechanism in place. Intrusion detection is a waste of time if you are not going to alert anyone.
When a particular attack has been detected, most intrusion detection tools will
either log the event with syslogd or send e-mail to the root user
(the mail recipient is usually configurable). An administrator has to properly
configure the tools so that false positives do not trigger alerts. Alerts may
also indicate an ongoing attack and might not be useful, say, one day later,
since the attack might have already succeeded. So be sure that there is a
proper policy on handling alerts and that the technical mechanisms to implement
this policy are in place.
An interesting source of information is CERT's
Intrusion Detection Checklist
Network based intrusion detection tools monitor the traffic on a network segment and use this information as a data source. Specifically, the packets on the network are examined, and they are checked to see if they match a certain signature.
snort is a flexible packet sniffer or logger that detects attacks
using an attack signature dictionary. It detects a variety of attacks and
probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes,
and much more. snort also has real-time alerting capability. You
can use snort for a range of hosts on your network as well as for
your own host. This is a tool which should be installed on every router to
keep an eye on your network. Just install it with apt-get install
snort, follow the questions, and watch it log. For a little broader
security framework, see Prelude.
Debian's snort package has many security checks enabled by
default. However, you should customize the setup to take into account the
particular services you run on your system. You may also want to seek
additional checks specific to these services.
There are other, simpler tools that can be used to detect network attacks.
portsentry is an interesting package that can tip you off to port
scans against your hosts. Other tools like ippl or
iplogger will also detect some IP (TCP and ICMP) attacks, even if
they do not provide the kind of advanced techniques snort does.
You can test any of these tools with the Debian package idswakeup,
a shell script which generates false alarms, and includes many common attack
signatures.
Host based intrusion detection involves loading software on the system to be monitored which uses log files and/or the systems auditing programs as a data source. It looks for suspicious processes, monitors host access, and may even monitor changes to critical system files.
tiger is an older intrusion detection tool which has been ported
to Debian since the Woody branch. tiger provides checks of common
issues related to security break-ins, like password strength, file system
problems, communicating processes, and other ways root might be compromised.
This package includes new Debian-specific security checks including: MD5sums
checks of installed files, locations of files not belonging to packages, and
analysis of local listening processes. The default installation sets up
tiger to run each day, generating a report that is sent to the
superuser about possible compromises of the system.
Log analysis tools, such as logcheck can also be used to detect
intrusion attempts. See Using and
customizing logcheck, Section 4.12.1.
In addition, packages which monitor file system integrity (see Checking file system integrity, Section 4.16.3) can be quite useful in detecting anomalies in a secured environment. It is most likely that an effective intrusion will modify some files in the local file system in order to circumvent local security policy, install Trojans, or create users. Such events can be detected with file system integrity checkers.
Loadable kernel modules are files containing dynamically loadable kernel components used to expand the functionality of the kernel. The main benefit of using modules is the ability to add additional devices, like an Ethernet or sound card, without patching the kernel source and recompiling the entire kernel. However, crackers are now using LKMs for root-kits (knark and adore), opening up back doors in GNU/Linux systems.
LKM back doors are more sophisticated and less detectable than traditional
root-kits. They can hide processes, files, directories and even connections
without modifying the source code of binaries. For example, a malicious LKM
can force the kernel into hiding specific processes from procfs,
so that even a known good copy of the binary ps would not list
accurate information about the current processes on the system.
There are two approaches to defending your system against LKM root-kits, a proactive defense and a reactive defense. The detection work can be simple and painless, or difficult and tiring, depending on the approach taken.
The advantage of this kind of defense is that it prevents damage to the system
in the first place. One such strategy is getting there first, that
is, loading an LKM designed to protect the system from other malicious LKMs. A
second strategy is to remove capabilities from the kernel itself. For example,
you can remove the capability of loadable kernel modules entirely. Note,
however, that there are rootkits which might work even in this case, there are
some that tamper with /dev/kmem (kernel memory) directly to make
themselves undetectable.
Debian GNU/Linux has a few packages that can be used to mount a proactive defense:
lcap - A user friendly interface to remove capabilities
(kernel-based access control) in the kernel, making the system more secure.
For example, executing lcap CAP_SYS_MODULE [70] will remove module loading
capabilities (even for the root user).[71] There is some (old) information on capabilities at Jon
Corbet's Kernel
development section on LWN (dated December 1999).
If you don't really need many kernel features on your GNU/Linux system, you may
want to disable loadable modules support during kernel configuration. To
disable loadable module support, just set CONFIG_MODULES=n during the
configuration stage of building your kernel, or in the .config
file. This will prevent LKM root-kits, but you lose this powerful feature of
the Linux kernel. Also, disabling loadable modules can sometimes overload the
kernel, making loadable support necessary.
The advantage of a reactive defense is that it does not overload system
resources. It works by comparing the system call table with a known clean copy
in a disk file, System.map. Of course, a reactive defense will
only notify the system administrator after the system has already been
compromised.
Detection of some root-kits in Debian can be accomplished with the
chkrootkit package. The Chkrootkit program checks for signs
of several known root-kits on the target system, but is not a definitive test.
This is probably the most unstable and funny section, since I hope that some of the "duh, that sounds crazy" ideas might be realized. The following are just some ideas for increasing security — maybe genius, paranoid, crazy or inspired depending on your point of view.
Playing around with Pluggable Authentication Modules (PAM). As quoted in the Phrack 56 PAM article, the nice thing about PAM is that "You are limited only by what you can think of." It is true. Imagine root login only being possible with fingerprint or eye scan or cryptocard (why did I use an OR conjunction instead of AND?).
Fascist Logging. I would refer to all the previous logging discussion above as "soft logging". If you want to perform real logging, get a printer with fanfold paper, and send all logs to it. Sounds funny, but it's reliable and it cannot be tampered with or removed.
CD distribution. This idea is very easy to realize and offers pretty good security. Create a hardened Debian distribution, with proper firewall rules. Turn it into a boot-able ISO image, and burn it on a CDROM. Now you have a read-only distribution, with about 600 MB space for services. Just make sure all data that should get written is done over the network. It is impossible for intruders to get read/write access on this system, and any changes an intruder does make can be disabled with a reboot of the system.
Switch module capability off. As discussed earlier, when you disable the usage of kernel modules at kernel compile time, many kernel based back doors are impossible to implement because most are based on installing modified kernel modules.
Logging through serial cable (contributed by Gaby Schilders). As long as servers still have serial ports, imagine having one dedicated logging system for a number of servers. The logging system is disconnected from the network, and connected to the servers via a serial-port multiplexer (Cyclades or the like). Now have all your servers log to their serial ports, write only. The log-machine only accepts plain text as input on its serial ports and only writes to a log file. Connect a CD/DVD-writer, and transfer the log file to it when the log file reaches the capacity of the media. Now if only they would make CD writers with auto-changers... Not as hard copy as direct logging to a printer, but this method can handle larger volumes and CD-ROMs use less storage space.
Change file attributes using chattr (taken from the Tips-HOWTO,
written by Jim Dennis). After a clean install and initial configuration, use
the chattr program with the +i attribute to make
files unmodifiable (the file cannot be deleted, renamed, linked or written to).
Consider setting this attribute on all the files in /bin,
/sbin/, /usr/bin, /usr/sbin,
/usr/lib and the kernel files in root. You can also make a copy
of all files in /etc/, using tar or the like, and
mark the archive as immutable.
This strategy will help limit the damage that you can do when logged in as
root. You won't overwrite files with a stray redirection operator, and you
won't make the system unusable with a stray space in a rm -fr
command (you might still do plenty of damage to your data — but your
libraries and binaries will be safer).
This strategy also makes a variety of security and denial of service (DoS) exploits either impossible or more difficult (since many of them rely on overwriting a file through the actions of some SETUID program that isn't providing an arbitrary shell command).
One inconvenience of this strategy arises during building and installing
various system binaries. On the other hand, it prevents the make
install from over-writing the files. When you forget to read the
Makefile and chattr -i the files that are to be overwritten, (and
the directories to which you want to add files) - the make command fails, and
you just use the chattr command and rerun it. You can also take
that opportunity to move your old bin's and libs out of the way, into a .old/
directory or tar archive for example.
Note that this strategy also prevents you from upgrading your system's
packages, since the files updated packages provide cannot be overwritten. You
might want to have a script or other mechanism to disable the immutable flag on
all binaries right before doing an apt-get update.
Play with UTP cabling in a way that you cut 2 or 4 wires and make the cable one-way traffic only. Then use UDP packets to send information to the destination machine which can act as a secure log server or a credit card storage system.
A honeypot is a system designed to teach system administrators how crackers probe for and exploit a system. It is a system setup with the expectation and goal that the system will be probed, attacked and potentially exploited. By learning the tools and methods employed by the cracker, a system administrator can learn to better protect their own systems and network.
Debian GNU/Linux systems can easily be used to setup a honeynet, if you dedicate the time to implement and monitor it. You can easily setup the fake honeypot server as well as the firewall[72] that controls the honeynet and some sort of network intrusion detector, put it on the Internet, and wait. Do take care that if the system is exploited, you are alerted in time (see The importance of logs and alerts, Section 4.12) so that you can take appropriate measures and terminate the compromise when you've seen enough. Here are some of the packages and issues to consider when setting up your honeypot:
The firewall technology you will use (provided by the Linux kernel).
syslog-ng, useful for sending logs from the honeypot to a remote
syslog server.
snort, to set up capture of all the incoming network traffic to
the honeypot and detect the attacks.
osh, a SETUID root, security enhanced, restricted shell with
logging (see Lance Spitzner's article below).
Of course, all the daemons you will be using for your fake server honeypot. Depending on what type of attacker you want to analyse you will or will not harden the honeypot and keep it up to date with security patches.
Integrity checkers (see Checking file
system integrity, Section 4.16.3) and The Coroner's Toolkit
(tct) to do post-attack audits.
honeyd and farpd to setup a honeypot that will listen
to connections to unused IP addresses and forward them to scripts simulating
live services. Also check out iisemulator.
tinyhoneypot to setup a simple honeypot server with fake services.
If you cannot use spare systems to build up the honeypots and the network
systems to protect and control it you can use the virtualisation technology
available in xen or uml (User-Mode-Linux). If you
take this route you will need to patch your kernel with either
kernel-patch-xen or kernel-patch-uml.
You can read more about building honeypots in Lanze Spitzner's excellent
article To
Build a Honeypot (from the Know your Enemy series). Also, the
Honeynet Project
provides valuable information about building honeypots and auditing the attacks
made on them.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ next ]
Securing Debian Manual
Version: 3.13, Sun, 08 Apr 2012 02:48:09 +0000[email protected]