As mentioned previously, Ext2 was the de facto file system for Linux. Although Ext2 lacks some of the advanced features, such as extremely large files and extent mapped files of XFS, JFS, and others, it is a reliable, stable, and still available out-of-the-box file system for all Linux distributions. The real weakness of Ext2 is fsck: the bigger the Ext2 file system, the longer it takes fsck to run. Longer fsck times translate into longer down times.
Block Allocation in the Ext2 File System
When sequentially writing to a file, Ext2 preallocates space in units of eight contiguous blocks. Unused preallocation blocks are released when the file is closed, so space isn't wasted. This method prevents or reduces fragmentation, a condition under which many of the blocks in the file are spread throughout the disk because contiguous blocks aren't available. Contiguous blocks increase performance because when files are read sequentially there is minimal disk head movement.
Fragmentation of filesthat is, the scattering of files into blocks that are not contiguousis a problem that all file systems encounter. Fragmentation is caused when files are created and deleted. The fragmentation problem can be solved by having the file system use advanced algorithms to reduce fragmentation. The problem can also be solved by using the defrag file system utility, which moves the fragmented files so that they have contiguous blocks assigned to them. A defragmentation tool available for Ext2 is called defrag.ext2.
Creating an Ext2 File System
The program that creates Ext2 and (Ext3) file systems is called mke2fs. Two additional commands can be used to create an Ext2/Ext3 file system: mkfs.ext2 and mkfs t ext2. The rest of this section looks at some of the key options that are available with the mkfs command:
• The -b block-size option specifies the block size in bytes. Valid block size values are 1024, 2048, and 4096 bytes per block.
• The -N number-of-inodes option specifies the number of inodes.
• The -T fs-type option specifies how the file system will be used. The valid options are as follows:
news creates one inode per 4KB block.
largefile creates one inode per megabyte.
largefile4 creates one inode per 4 megabytes.
For a complete listing of the options to mkfs.ext2, see the mkfs.ext2 man page.
The following example uses the default when issuing mkfs on the device /dev/hdb2. The block size defaults to 4096, and the number of inodes created is 502944.
# mkfs.ext2 /dev/hdb2
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
502944 inodes, 1004062 blocks
...
Next, set the block size to 1024 with the b 1024 option, and set the file system type with the T news option. The number of inodes created is 1005568.
# mkfs -t ext2 -b 1024 -T news /dev/hdb2
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
1005568 inodes, 4016250 blocks
...
Ext3 Extensions for the Ext2 File System
The Ext3 file system provides higher availability without impacting the robustness (at least, the simplicity and reliability) of Ext2. Ext3 is a minimal extension to Ext2 to add support for journaling. Ext3 uses the same disk layout and data structures as Ext2, and it is forward- and backward-compatible with Ext2. Migrating from Ext2 to Ext3 (and vice versa) is quite easy; it can even be done in-place in the same partition. The other three journaling file systems require the partition to be formatted with their mkfs utility.
If you want to adopt a journaling file system but don't have free partitions on your system, Ext3 could be the journaling file system to use.
Kernel Configuration Support for Ext3
You can select Ext3 options from the File Systems section of the configuration menu and enable the following option:
Ext3 journaling file system support (CONFIG_EXT3_FS=y,m,n)
Click y next to the Ext3 entry if you want to build Ext3 into the kernel. Click m next to the Ext3 entry if you want to build Ext3 as a module. The n option is used if support for Ext3 is not needed.
Other options are available in the Ext3 selection for Ext3 configuration. If you need any of these options, select them here.
Working with Ext3
There are three ways to tune an Ext3 file system:
1. When the file system is created, which is the most efficient way
2. Through the tuning utility tune2fs, which can be used to tune the file system after it has been created
3. Through options that can be used when the file system is mounted
All three of these tuning options are discussed in the next sections.
Creating an Ext3 Partition
The program that creates Ext3 file systems is called mke2fs. You can also use the mkfs.ext3 and mkfs t ext3 commands to create an Ext3 file system. The rest of this section looks at some of the key options that are available with the mkfs command:
• The -b block-size option specifies the block size in bytes. Valid block size values are 1024, 2048, and 4096 bytes per block.
• The -N number-of-inodes option specifies the number of inodes.
• The -T fs-type option specifies how the file system will be used. The valid options are as follows:
news creates one inode per 4KB block.
largefile creates one inode per megabyte.
largefile4 creates one inode per 4 megabytes.
For a complete listing of the options to mkfs.ext3, see the mkfs.ext3 man page.
The following example uses the default when issuing mkfs on the device /dev/sdb1. The block size is 1024, and the number of inodes created is 128016.
# mkfs.ext3 /dev/sdb1
mke2fs 1.28 (31-Aug-2002)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
128016 inodes, 511984 blocks
...
After the Ext3 file system is formatted, it is good practice to eliminate the automatic checking of the file system (the file system is automatically checked every 23 mounts or 180 days, whichever comes first). To eliminate the automatic checking, use the tune2fs command with the c option to set checking to 0.
# tune2fs c 0 /dev/sdb1
tune2fs 1.28(31-Aug-2002)
Setting maximal mount count to -1
Converting an Ext2 File System to Ext3
This section explains how to convert an Ext2 file system to Ext3:
1. Make a backup of the file system.
2. Add a journal file to the existing Ext2 file system you want to convert by running the tune2fs program with the -j option. You can run tune2fs on a mounted or unmounted Ext2 file system. For example, if /dev/hdb3 is an Ext2 file system, the following command creates the log:
3. # tune2fs -j /dev/hdb3
If the file system is mounted, a journal file named .journal is placed in the root directory of the file system. If the file system is not mounted, the journal file is hidden. (When you mount an Ext3 file system, the .journal file appears. The .journal file can indicate that the file system is indeed of type Ext3.)
4. Change the entry for /dev/hdb3 in the /etc/fstab file from ext2 to ext3.
5. Reboot and verify that the /dev/hdb3 partition has type Ext3 by typing mount and examining the output. The output should include an entry like the following:
6. # mount
7.
8. /dev/hdb3 on /test type ext3 (rw)
Using a Separate Journal Device on an Ext3 File System
The first thing you need to do to use an external journal for an Ext3 file system is to issue the mkfs command on the journal device. The block size of the external journal must be the same block size as the Ext3 file system. In the following example, the /dev/hda1 device is used as the external log for the Ext3 file system:
# mkfs.ext3 -b 4096 -O journal_dev /dev/hda1
# mkfs.ext3 -b 4096 -J device=/dev/hda1 /dev/hdb1
Ext2/Ext3 Utilities
The e2fsprogs package contains various utilities for use with Ext2 and Ext3 file systems. The following is a short description of each utility:
• badblocks. Searches for bad blocks on a device.
• chattr. Changes the file attributes on an Ext2 or Ext3 file system.
• compile_et. Converts a table, listing error-code names and associated messages into a C-source file that is suitable for use with the com_err library.
• debugfs. A file system debugger for examining and changing the state of an Ext2 file system.
• dumpe2fs. Prints the super block and blocks group information for the file system present on a specified device.
• e2fsck and fsck.ext2. Checks, and optionally repairs, an Ext2 file system.
• e2image. Saves critical Ext2 file system data to a file.
• e2label. Displays or changes the file system label on the Ext2 file system.
• fsck.ext3. Checks, and optionally repairs, an Ext3 file system.
• lsattr. Lists the file attributes on an Ext2 file system.
• mk_cmds. Takes a command table file as input and produces a C-source file as output, which is intended for use with the subsystem library, libss.
• mke2fs. Creates an Ext2 file system. mkfs.ext2 is the same as mke2fs.
• mkfs.ext3. Creates an Ext3 file system.
• mklost+found. Creates a lost+found directory in the current working directory on an Ext2 file system. mklost+found preallocates disk blocks to the directory to make it usable by e2fsck.
• resize2fs. Resizes Ext2 file systems.
• tune2fs. Adjusts tunable file system parameters on an Ext2 file system.
Sunday, August 24, 2008
Wednesday, August 20, 2008
FreeBSD: Automate Security Patches
Keep up-to-date with security patches.
We all know that keeping up-to-date with security patches is important. The trick is coming up with a workable plan that ensures you're aware of new patches as they're released, as well as the steps required to apply those patches correctly.
Michael Vince created quickpatch to assist in this process. It allows you to automate the portions of the patching process you'd like to automate and manually perform the steps you prefer to do yourself.
Preparing the Script
quickpatch requires a few dependencies: perl, cvsup, and wget. Use which to determine if you already have these installed on your system:
% which perl cvsup wget
/usr/bin/perl
/usr/local/bin/cvsup
wget: Command not found.
Install any missing dependencies via the appropriate port (/usr/ports/lang/perl5, /usr/ports/net/cvsup-without-gui, and /usr/ports/ftp/wget, respectively).
Once you have the dependencies, download the script from http://roq.com/projects/quickpatch and untar it:
% tar xzvf quickpatch.tar.gz
This will produce an executable Perl script named quickpatch.pl. Open this script in your favorite editor and review the first two screens of comments, up to the #Stuff you probably don't want to change line.
Make sure that the $release line matches the tag you're using in your cvs-supfile
# The release plus security patches branch for FreeBSD that you are
# following in cvsup.
# It should always be a long the lines of RELENG_X_X , example RELENG_4_9
$release='RELENG_4_9';
The next few paths are fine as they are, unless you have a particular reason to change them:
# Ftp server mirror from where to fetch FreeBSD security advisories
$ftpserver="ftp.freebsd.org";
# Path to store patcher program files
$patchdir="/usr/src/";
# Path to store FreeBSD security advisories
$advdir="/var/db/advisories/";
$advdirtmp="$advdir"."tmp/";
If you're planning on applying the patches manually and, when required, rebuilding your kernel yourself, leave the next section as is. If you're brave enough to automate the works, make sure that the following paths accurately reflect your kernel configuration file and build directories:
# Path to your kernel rebuild script for source patches that require kernel
#rebuild
$kernelbuild="/usr/src/buildkernel";
#$kernelbuild="cd /usr/src ; make buildkernel KERNCONF=GENERIC && make
#installkernel KERNCONF=GENERIC ; reboot";
# Path to your system recompile scipt for patches that require full
# operating system recompile
$buildworld="/usr/src/buildworld";
#$buildworld="cd /usr/src/ ; make buildworld && make installworld ; reboot";
#Run patch command after creation, default no
$runpatchfile="0";
# Minimum advisory age in hours. This is to make sure you don't patch
# before your local cvsup server has had a
# chance to recieve the source change update to your branch, in hours
$advisory_age="24";
Review the email accounts so the appropriate account receives notifications:
# Notify email accounts, eg: qw(billg@microsoft.com root@localhost);
@emails = qw(root);
Running the Hack
Run the script without any arguments to see the available options:
# /.quickpatch.pl
# Directory /var/db/advisories/ does not exist, creating
# Directory /var/db/advisories/tmp/ does not exist, creating
Quickpatch - Easy source based security update system
"./quickpatch.pl updateadv" to download / update advisories db
"./quickpatch.pl patch" or "./quickpatch.pl patch > big_patch_file" to
create patch files
"./quickpatch.pl notify" does not do anything but email you commands of what
it would do
"./quickpatch.pl pgpcheck" to PGP check advisories
Before applying any patches, it needs to know which patches exist. Start by downloading the advisories:
# ./quickpatch.pl updateadv
This will connect to ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories and download all of the advisories to /var/db/advisories. The first time you use this command, it will take a while. However, once you have a copy of the advisories, it takes only a second or so to compare your copies with the FTP site and, if necessary, download any new advisories.
After downloading the advisories, see if your system needs patching:
# ./quickpatch.pl notify
#
If the system is fully patched, you'll receive your prompt back. However, if the system is behind in patches, you'll see output similar to this:
# ./quickpatch.pl notify
######################################################################
####### FreeBSD-SA-04%3A02.shmat.asc
####### Stored in file /var/db/advisories/tmp/FreeBSD-SA-04%3A02.shmat
####### Topic: shmat reference counting bug
####### Hostname: genisis - 20/2/2004 11:57:30
####### Date Corrected: 2004-02-04 18:01:10
####### Hours past since corrected: 382
####### Patch Commands
cd /usr/src
# patch < /path/to/patch
### c) Recompile your kernel as described in
and reboot the
system.
/usr/src/buildkernel
## Emailed root
It looks like this system needs to be patched against the "schmat reference counting bug." While running in notify mode, quickpatch emails this information to the configured address but neither creates nor installs the patch.
To create the patch, use:
# ./quickpatch.pl patch
#########################################################
####### FreeBSD-SA-04%3A02.shmat.asc
####### Stored in file /usr/src/FreeBSD-SA-04%3A02.shmat
####### Topic: shmat reference counting bug
####### Hostname: genisis - 21/2/2004 10:41:54
####### Date Corrected: 2004-02-04 18:01:10
####### Hours past since corrected: 405
####### Patch Commands
cd /usr/src
# patch < /path/to/patch
### c) Recompile your kernel as described in
# and reboot the
#system.
/usr/src/buildkernel
# file /usr/src/FreeBSD-SA-04%3A02.shmat
/usr/src/FreeBSD-SA-04%3A02.shmat: Bourne shell script text executable
This mode creates the patch as a Bourne script and stores it in /usr/src. However, it is up to you to apply the patch manually. This may suit your purposes if you intend to review the patch and read any notes or caveats associated with the actual advisory.
Automating the Process
One of the advantages of having a script is that you can schedule its execution with cron. Here is an example of a typical cron configuration for quickpatch.pl; modify to suit your own purposes. Remember to create your logging directories and touch your log files before the first run.
# Every Mon, Wed, and Fri at 3:05 do an advisory check and download any
# newly released security advisories
5 3 * * 1,3,5 root /etc/scripts/quickpatch.pl updateadv > \
/var/log/quickpatch/update.log 2>1
# 20 minutes later, check to see if any new advisories are ready for use
# and email the patch commands to the configured email address
25 3 * * 1,3,5 root /etc/scripts/quickpatch.pl notify >> \
/var/log/quickpatch/notify.log 2>&1
# 24 hours later patch mode is run which will run the patch commands if
# no one has decided to interfere.
25 3 * * 2,4,6 root /etc/scripts/quickpatch.pl patch >> \
/var/log/quickpatch/patch.log 2>&1
We all know that keeping up-to-date with security patches is important. The trick is coming up with a workable plan that ensures you're aware of new patches as they're released, as well as the steps required to apply those patches correctly.
Michael Vince created quickpatch to assist in this process. It allows you to automate the portions of the patching process you'd like to automate and manually perform the steps you prefer to do yourself.
Preparing the Script
quickpatch requires a few dependencies: perl, cvsup, and wget. Use which to determine if you already have these installed on your system:
% which perl cvsup wget
/usr/bin/perl
/usr/local/bin/cvsup
wget: Command not found.
Install any missing dependencies via the appropriate port (/usr/ports/lang/perl5, /usr/ports/net/cvsup-without-gui, and /usr/ports/ftp/wget, respectively).
Once you have the dependencies, download the script from http://roq.com/projects/quickpatch and untar it:
% tar xzvf quickpatch.tar.gz
This will produce an executable Perl script named quickpatch.pl. Open this script in your favorite editor and review the first two screens of comments, up to the #Stuff you probably don't want to change line.
Make sure that the $release line matches the tag you're using in your cvs-supfile
# The release plus security patches branch for FreeBSD that you are
# following in cvsup.
# It should always be a long the lines of RELENG_X_X , example RELENG_4_9
$release='RELENG_4_9';
The next few paths are fine as they are, unless you have a particular reason to change them:
# Ftp server mirror from where to fetch FreeBSD security advisories
$ftpserver="ftp.freebsd.org";
# Path to store patcher program files
$patchdir="/usr/src/";
# Path to store FreeBSD security advisories
$advdir="/var/db/advisories/";
$advdirtmp="$advdir"."tmp/";
If you're planning on applying the patches manually and, when required, rebuilding your kernel yourself, leave the next section as is. If you're brave enough to automate the works, make sure that the following paths accurately reflect your kernel configuration file and build directories:
# Path to your kernel rebuild script for source patches that require kernel
#rebuild
$kernelbuild="/usr/src/buildkernel";
#$kernelbuild="cd /usr/src ; make buildkernel KERNCONF=GENERIC && make
#installkernel KERNCONF=GENERIC ; reboot";
# Path to your system recompile scipt for patches that require full
# operating system recompile
$buildworld="/usr/src/buildworld";
#$buildworld="cd /usr/src/ ; make buildworld && make installworld ; reboot";
#Run patch command after creation, default no
$runpatchfile="0";
# Minimum advisory age in hours. This is to make sure you don't patch
# before your local cvsup server has had a
# chance to recieve the source change update to your branch, in hours
$advisory_age="24";
Review the email accounts so the appropriate account receives notifications:
# Notify email accounts, eg: qw(billg@microsoft.com root@localhost);
@emails = qw(root);
Running the Hack
Run the script without any arguments to see the available options:
# /.quickpatch.pl
# Directory /var/db/advisories/ does not exist, creating
# Directory /var/db/advisories/tmp/ does not exist, creating
Quickpatch - Easy source based security update system
"./quickpatch.pl updateadv" to download / update advisories db
"./quickpatch.pl patch" or "./quickpatch.pl patch > big_patch_file" to
create patch files
"./quickpatch.pl notify" does not do anything but email you commands of what
it would do
"./quickpatch.pl pgpcheck" to PGP check advisories
Before applying any patches, it needs to know which patches exist. Start by downloading the advisories:
# ./quickpatch.pl updateadv
This will connect to ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories and download all of the advisories to /var/db/advisories. The first time you use this command, it will take a while. However, once you have a copy of the advisories, it takes only a second or so to compare your copies with the FTP site and, if necessary, download any new advisories.
After downloading the advisories, see if your system needs patching:
# ./quickpatch.pl notify
#
If the system is fully patched, you'll receive your prompt back. However, if the system is behind in patches, you'll see output similar to this:
# ./quickpatch.pl notify
######################################################################
####### FreeBSD-SA-04%3A02.shmat.asc
####### Stored in file /var/db/advisories/tmp/FreeBSD-SA-04%3A02.shmat
####### Topic: shmat reference counting bug
####### Hostname: genisis - 20/2/2004 11:57:30
####### Date Corrected: 2004-02-04 18:01:10
####### Hours past since corrected: 382
####### Patch Commands
cd /usr/src
# patch < /path/to/patch
### c) Recompile your kernel as described in
system.
/usr/src/buildkernel
## Emailed root
It looks like this system needs to be patched against the "schmat reference counting bug." While running in notify mode, quickpatch emails this information to the configured address but neither creates nor installs the patch.
To create the patch, use:
# ./quickpatch.pl patch
#########################################################
####### FreeBSD-SA-04%3A02.shmat.asc
####### Stored in file /usr/src/FreeBSD-SA-04%3A02.shmat
####### Topic: shmat reference counting bug
####### Hostname: genisis - 21/2/2004 10:41:54
####### Date Corrected: 2004-02-04 18:01:10
####### Hours past since corrected: 405
####### Patch Commands
cd /usr/src
# patch < /path/to/patch
### c) Recompile your kernel as described in
#
#system.
/usr/src/buildkernel
# file /usr/src/FreeBSD-SA-04%3A02.shmat
/usr/src/FreeBSD-SA-04%3A02.shmat: Bourne shell script text executable
This mode creates the patch as a Bourne script and stores it in /usr/src. However, it is up to you to apply the patch manually. This may suit your purposes if you intend to review the patch and read any notes or caveats associated with the actual advisory.
Automating the Process
One of the advantages of having a script is that you can schedule its execution with cron. Here is an example of a typical cron configuration for quickpatch.pl; modify to suit your own purposes. Remember to create your logging directories and touch your log files before the first run.
# Every Mon, Wed, and Fri at 3:05 do an advisory check and download any
# newly released security advisories
5 3 * * 1,3,5 root /etc/scripts/quickpatch.pl updateadv > \
/var/log/quickpatch/update.log 2>1
# 20 minutes later, check to see if any new advisories are ready for use
# and email the patch commands to the configured email address
25 3 * * 1,3,5 root /etc/scripts/quickpatch.pl notify >> \
/var/log/quickpatch/notify.log 2>&1
# 24 hours later patch mode is run which will run the patch commands if
# no one has decided to interfere.
25 3 * * 2,4,6 root /etc/scripts/quickpatch.pl patch >> \
/var/log/quickpatch/patch.log 2>&1
Tuesday, August 19, 2008
Network Access Protection (NAP)
The only truly new XP SP3 feature is Network Access Protection (NAP). NAP, which works with Windows Server 2008, is a security checkup protocol. It blocks any PC from joining a Server-based active directory (AD) unless it meets the server’s security update policy standard. For example, if the server requires a PC to have the latest patches installed, it won’t let the PC login until it has gotten those update.
Thursday, August 14, 2008
FreeBSD Hardening: Your First Steps
As you know by now, you can't just "turn on" security. System security is like a collection of switches and knobs that you must constantly adjust. Deciding which switches to flip and which knobs to turn will depend a great deal on your environment: security policies and procedures imposed upon you, your own security requirements, the nature of the data on the system, and the administrative overhead you are willing or required to tolerate.
Some steps are more important than others, and in a lot of cases, this too varies between environments.
3.3.1. Step 1: Configure sudo
We'll make this step brief since we cover sudo extensively in the next chapter. For now, all you need to do is ensure that the user account you created has fairly liberal rights when it comes to running privileged commands through sudo. In order to configure sudo to allow your account to execute any command as root, edit the sudoers(5) file by running visudo(8) without arguments while logged in as root. Append the following line to the file:
username ALL = ALL
Where of course username is the account you created for yourself during the install process. That's it! Save the file, log out, and log back in under your regular account. In order to run privileged commands from here on out, just prepend sudo to the command you'd ordinarily run as root. The first time you use sudo, it will tell you about the power you hold and ask for your (not root's!) password. Thereafter, it will periodically prompt for your password to make sure you are you.
3.3.2. Step 2: Turn Off Unnecessary Services
Your server is likely to provide one or two critical services to a local network or to visitors from the Internet. Other supporting services may also be running like sshd(8) for remote administration. All other services that listen on a network interface can be disabled. There is where knowing about preexisting vulnerabilities come in handy. With this in mind, it is a reasonable precautionary step to disable these services also.
If you've just installed FreeBSD 5.x, opted to not configure inetd during the install, and chose to enable sshd, you're in great shape. The only services you'll have listening on a newly installed 5.x system are sendmail accessible only on the loopback interface, and sshd. If you did enable inetd, make sure you edit /etc/inetd.conf and comment out all unneeded components.
If you've just installed FreeBSD 4.x, the state of your system will vary depending on the security profile you chose. If you selected the extreme security profile, you will not have any remotely accessible services enabled and your first step is complete.
A FreeBSD 4.x system configured with a medium security profile will have a variety of running processes listening on several externally accessible ports. If your network card is not plugged in, that's not much of a problem—but you are going to be online sooner or later. Sooner, really, because your second step in this process is updating your system to the latest security branch (for more information about tracking branches, see Chapter 4). So turn off those services by adjusting rc.conf(5) as appropriate, and plug in. If you didn't configure your network at all during the install, do so after these services are disabled.
FreeBSD has a handy utility called sockstat to assist you in determining what services are listening on what port. Use the command sockstat -l to list all listening services. If you want to limit the results to only IPv4 interfaces, run sockstat -4l. For more information, see the sockstat(1) manpage.
3.3.3. Step 3: Update Your System
A freshly installed system is rarely up to date. Chances are good that development has continued since you acquired your software, and numerous bugs (both security and otherwise) have been found and fixed. As we've mentioned before, make sure you're subscribed to the security notifications list, and have checked the security page on the FreeBSD web site for known vulnerabilities. In any case, it's time for your first system update.
3.3.3.1 Getting the latest sources
Once you have connectivity and are reasonably assured that your system cannot be compromised by a remote attacker, it is time to cvsup your system sources, and rebuild. But wait, in a fit of paranoia you did not install the cvsup package as part of the FreeBSD install! Why did you fail to install something of immediate use? Well, if you have no plans to install XFree86 on this machine, you need the cvsup-without-gui port, which is not available during the install. The cvsup that is available depends on X libraries that you would like to avoid installing if possible. Fortunately the acquisition of cvsup-without-gui is as simple as:
% sudo pkg_add -r cvsup-without-gui
Typically when impatient administrators use cvsup to update the source tree, they do so as root. Downloading source code shouldn't require root-level privilege. Really, the only reason this level of access is needed is because of default filesystem permissions. The cvsup program will need to store information in /var/db/sup, and will write into /usr/src. When you upgrade your system, you'll also need to write into /usr/obj. The solution here is to adjust the default permissions of these three directories (you may need to create /var/db/sup first) so that you can write to them without elevated privileges.
How you accomplish this is up to you. If you're the sole administrator in charge of performing system upgrades, you might just want to make yourself the owner of these directories as shown in Example 3-2. Otherwise, you may want to use a special administrators-only group and grant group-write access to these directories.
Example 3-2. Changing ownership of key directories for cvsup
% sudo mkdir /var/db/sup
% sudo chown -R username /var/db/sup /usr/src /usr/obj
Now that you've got permissions straight, it's time to configure cvsup. First, you will need to create an appropriate supfile. This file sets a variety of defaults and will be read in by the cvsup program when you update your sources. Begin with one of the example files in /usr/share/examples/cvsup, perhaps standard-supfile. Look for a line that specifies the release and tag, for example:
*default release=cvs tag=RELENG_5_3
The tag specifies the branch of FreeBSD you want to track. In general, most carefully administered FreeBSD servers track the security branch which includes only critical bug and security fixes. Thus if you install FreeBSD 5.3, you will always be running FreeBSD 5.3 with patches, and the appropriate tag for this is in fact RELENG_5_3.
If the supfile you're working with indicates something other than a security branch, for example RELENG_5 (that indicates -STABLE) or just . (a period, that indicates -CURRENT), adjust the tag as appropriate. After you adjust the supfile, save your working file elsewhere, perhaps /usr/local/etc/security-supfile. Finally, update your FreeBSD sources by running:
% /usr/local/bin/cvsup -L 1 -h cvsup
x
.freebsd.org \
/path/to/your/chosen/supfile
Be sure to replace the x in cvsupx.freebsd.org above with a number corresponding to a cvsup mirror close to you.
Do not directly modify any of the example supfiles. If another example cvsup configuration file better suits your needs, use it instead. If you need to make drastic changes to any of these files, save a modified copy of the file elsewhere. You do not want to accidentally lose your changes during a system upgrade.
While it is possible to track the -STABLE branch, be aware that system upgrades may include more changes than you bargained for. Some administrators have had success carefully tracking the -STABLE branch by performing upgrades to noncritical servers and subsequently upgrading other servers (using source from the exact same time) after a great deal of testing. Other administrators have been badly burned by tracking this branch. Unless vital features or fixes exist in the -STABLE branch, stick with the security branch. Finally, forget about tracking -CURRENT on production infrastructure. It is too volatile and unreliable and is better suited to systems with which you tinker but not on which you rely.
After you have successfully performed an update, you have the opportunity to save your update preferences for later use. To do this, add a block similar to the following to /etc/make.conf(5):
SUP_UPDATE= yes
SUP= /usr/local/bin/cvsup
SUPFLAGS= -L 1
SUPHOST= cvsupx.freebsd.org
SUPFILE= /path/to/your/chosen/supfile
After doing this, you may update your sources by running make update from /usr/src.
For more information about cvsup including (and especially) using refuse files to tune which files or directories you retrieve, see the FreeBSD manpage for cvsup(1) and Appendix A.5 of the FreeBSD Handbook. To learn more about tracking branches of FreeBSD, see the relevant discussion in Chapter 4.
3.3.3.2 Kernel configuration
Before upgrading your system, you will probably want to fine-tune your kernel, both for security and performance reasons. Customizing your kernel configuration is typically recommended for FreeBSD systems, and only needs to be done immediately after the system is built and when you introduce new hardware. Given an environment where there are few hardware changes and consistent hardware across an infrastructure, the one time cost of fine-tuning yields rewards over the long term.
Creating a custom kernel configuration is almost never done from scratch. Typically you start from a copy of the /sys/conf/GENERIC kernel and remove options as necessary. In some cases it may be necessary to add hardware support from /sys/arch/conf/NOTES (In FreeBSD 4.x this file was LINT). As with installing distributions and packages, the following adage holds true: if you do not need it, do not install it. In a kernel context, this means if you do not need the kernel option, delete the configuration line and it will not be compiled in. The fewer drivers and options compiled into the kernel, the less always-running code there is to exploit.
Be careful with what you remove. It may not be obvious that some options are mandatory. For many releases, the COMPAT_43 option had the somewhat vague comment "Compatible with BSD 4.3" in the GENERIC file. Few administrators understood why they would want to be compatible with BSD 4.3 and removed this option. Then they discovered that their systems would no longer boot, and the comment now includes "[KEEP THIS!]."
The process of configuring a custom kernel is exceedingly well documented in Chapter 9 of the FreeBSD Handbook. While you need not actually compile or install your kernel in this step (we will do that in a moment as part of the system upgrade), now is a good time to create a configuration file for your custom kernel. The following list of options includes some of the changes you may want to make to the generic kernel for security reasons.
BPF
The Berkeley Packet Filter option in the kernel allows packet sniffers such as tcpdump(1) to function. On many servers, the bpf pseudodevice is probably not necessary. Some key exceptions are DHCP servers/clients and IDS hosts. Access to information provided by this pseudodevice relies on the user being able to read from /dev/bpf*. If you want to restrict snooping on network interfaces, remove the bpf device from your kernel configuration.
CD9660
Removing this option from the kernel will relegate the ISO9660 filesystem drivers to a kernel module. In a securelevel of 1 or greater, this module will not load, and access to a CD will require that you bring the system to single user mode or reboot. In a hostile physical environment, this may be desirable. In other cases, the administrative hassle will probably outweigh any security benefit.
DEBUG
This option is disabled by default and should remain that way on production servers. Turning this option on would cause symbols to not be stripped after linking yielding a larger kernel, larger core dumps (unless you have disabled core dumps using sysctl as described in Chapter 2), and more information in those core dumps.
IPv6, gif, faith
Falling under the category of "if you don't need it, don't install it," if IPv6 is not being used in your environment, there is no need to compile it into your kernel. Removing this option will shrink your kernel and allow for the removal of gif and faith devices that provide tunneling and relaying support for IPv6. Compiling without this option will also ensure that ports you build on your system after installing your new kernel do not have IPv6 support compiled in by default.
KTRACE
The KtrACE option in the kernel will provide for kernel tracing using ktrace(1) and kdump(1) as described in Chapter 2. This option is enabled by default. ktrace assists with debugging and providing empirical data regarding the types of I/O operations a program is requesting and arguments to these operations. As a result, ktrace can assist in leaking sensitive information to the individual running ktrace. Unless you plan on using ktrace for one of the purposes discussed in Chapter 2, it is probably best to leave this option out of the kernel.
MSDOSFS
The MS-DOS filesystem drivers will, like the ISO 9660 filesystem drivers, be compiled into a kernel module if this option is disabled. As with CD9660, the kernel module will not load at securelevel 1 or higher. In addition, even without this kernel option, mtools (in the FreeBSD ports collection) provides a means to access MS-DOS media without the support of this filesystem.
NFS
NFS between systems is rarely used on production systems with direct exposure to the Internet. Support for NFS and NFS_ROOT can be safely removed from your kernel configuration unless you plan to provide a locally accessible and read only master jail as described in Chapter 2, or your system is on a LAN and the situation calls for it.
UCONSOLE
This option allows non-root users to own the system console device (/dev/console). On an infrastructure system, there should be no need for users whatsoever. On a workstation or other server running X however, it is likely users will want to grab the console using programs like xconsole. Your situation will determine whether you want to leave this in.
USB
USB devices are invaluable on workstations. Some servers these days ship without integrated removable media bays at all and rely on the availability of USB floppies and CD-ROM drives. Your hardware will in large part determine whether USB devices should be supported by your kernel. In an untrusted environment, automatic support of USB media may not be desirable.
Remember that just because the functionality is not compiled into your kernel, you may still have access to it. Much of the kernel is modular, so even if you do not compile it in, you can load the appropriate module later, provided your system is running in a securelevel below 1.
Once you have decided how to build your custom kernel, save the configuration file with the other files in /sys/arch/conf. Be sure not to replace the original GENERIC configuration file, but instead, save your changes into another file, e.g., MYKERNEL.
3.3.3.3 Your first upgrade
With the latest sources sitting in /usr/src and a custom kernel configuration file ready, you're prepared to upgrade the system. This entire process has been comprehensively covered in Chapter 21 of the FreeBSD Handbook, so we will not waste time with the entire process here. Instead, a few do's and don'ts of upgrading your FreeBSD system.
• Do read /usr/src/UPDATING. Failure to do so could cause you to miss a step, rendering your system in a less-than-ideal state.
• Do create make.conf(5) for your system. If you plan to run a mail transport agent or nameserver installed from ports or ask a package, you would be well advised to configure make.conf so these binaries are not replaced during a system upgrade (this is less important during your first upgrade). Example 3-3 shows values in /etc/make.conf that might be appropriate for an i386 AMD based server with DNS software installed through ports instead of in the base system.
Example 3-3. Example /etc/make.conf for FreeBSD
CPUTYPE= k6-2
CFLAGS= -O -pipe
COPTFLAGS= -O -pipe
NO_BIND= true # no BIND
NOGAMES= true # no games (games/ subdir)
NOPROFILE= true # no profiled libraries
KERNCONF= MYCONFIG
BOOTWAIT= 3000
• In addition, your make.conf can assist with updating your source tree via make update by pointing it to your supfile and cvsup binary as described previously. For a full description of the options available in make.conf, see the make.conf(5) manpage.
• At this stage, don't worry about mergemaster(8) clobbering your configuration files. You haven't made any configuration changes yet. If you've never run mergemaster before, read the manpage. Table 3-2 describes options that may be useful to you in running mergemaster.
Table 3-2. Important mergemaster options
Option Description
-i If a file does not exist in /etc (it is being introduced as part of this upgrade), automatically install it.
-p Pre-buildworld mode. Compare files essential to the success of the buildworld/installworld process. Run this before buildworld.
-v Increase verbosity, useful the first time you run mergemaster.
-t [arg] Specify an alternate temporary root from which to make comparisons.
3.3.4. Step 4: Wrapping Up
With your FreeBSD system upgraded, it's time to turn your attention to some final system lockdown activities.
Some steps are more important than others, and in a lot of cases, this too varies between environments.
3.3.1. Step 1: Configure sudo
We'll make this step brief since we cover sudo extensively in the next chapter. For now, all you need to do is ensure that the user account you created has fairly liberal rights when it comes to running privileged commands through sudo. In order to configure sudo to allow your account to execute any command as root, edit the sudoers(5) file by running visudo(8) without arguments while logged in as root. Append the following line to the file:
username ALL = ALL
Where of course username is the account you created for yourself during the install process. That's it! Save the file, log out, and log back in under your regular account. In order to run privileged commands from here on out, just prepend sudo to the command you'd ordinarily run as root. The first time you use sudo, it will tell you about the power you hold and ask for your (not root's!) password. Thereafter, it will periodically prompt for your password to make sure you are you.
3.3.2. Step 2: Turn Off Unnecessary Services
Your server is likely to provide one or two critical services to a local network or to visitors from the Internet. Other supporting services may also be running like sshd(8) for remote administration. All other services that listen on a network interface can be disabled. There is where knowing about preexisting vulnerabilities come in handy. With this in mind, it is a reasonable precautionary step to disable these services also.
If you've just installed FreeBSD 5.x, opted to not configure inetd during the install, and chose to enable sshd, you're in great shape. The only services you'll have listening on a newly installed 5.x system are sendmail accessible only on the loopback interface, and sshd. If you did enable inetd, make sure you edit /etc/inetd.conf and comment out all unneeded components.
If you've just installed FreeBSD 4.x, the state of your system will vary depending on the security profile you chose. If you selected the extreme security profile, you will not have any remotely accessible services enabled and your first step is complete.
A FreeBSD 4.x system configured with a medium security profile will have a variety of running processes listening on several externally accessible ports. If your network card is not plugged in, that's not much of a problem—but you are going to be online sooner or later. Sooner, really, because your second step in this process is updating your system to the latest security branch (for more information about tracking branches, see Chapter 4). So turn off those services by adjusting rc.conf(5) as appropriate, and plug in. If you didn't configure your network at all during the install, do so after these services are disabled.
FreeBSD has a handy utility called sockstat to assist you in determining what services are listening on what port. Use the command sockstat -l to list all listening services. If you want to limit the results to only IPv4 interfaces, run sockstat -4l. For more information, see the sockstat(1) manpage.
3.3.3. Step 3: Update Your System
A freshly installed system is rarely up to date. Chances are good that development has continued since you acquired your software, and numerous bugs (both security and otherwise) have been found and fixed. As we've mentioned before, make sure you're subscribed to the security notifications list, and have checked the security page on the FreeBSD web site for known vulnerabilities. In any case, it's time for your first system update.
3.3.3.1 Getting the latest sources
Once you have connectivity and are reasonably assured that your system cannot be compromised by a remote attacker, it is time to cvsup your system sources, and rebuild. But wait, in a fit of paranoia you did not install the cvsup package as part of the FreeBSD install! Why did you fail to install something of immediate use? Well, if you have no plans to install XFree86 on this machine, you need the cvsup-without-gui port, which is not available during the install. The cvsup that is available depends on X libraries that you would like to avoid installing if possible. Fortunately the acquisition of cvsup-without-gui is as simple as:
% sudo pkg_add -r cvsup-without-gui
Typically when impatient administrators use cvsup to update the source tree, they do so as root. Downloading source code shouldn't require root-level privilege. Really, the only reason this level of access is needed is because of default filesystem permissions. The cvsup program will need to store information in /var/db/sup, and will write into /usr/src. When you upgrade your system, you'll also need to write into /usr/obj. The solution here is to adjust the default permissions of these three directories (you may need to create /var/db/sup first) so that you can write to them without elevated privileges.
How you accomplish this is up to you. If you're the sole administrator in charge of performing system upgrades, you might just want to make yourself the owner of these directories as shown in Example 3-2. Otherwise, you may want to use a special administrators-only group and grant group-write access to these directories.
Example 3-2. Changing ownership of key directories for cvsup
% sudo mkdir /var/db/sup
% sudo chown -R username /var/db/sup /usr/src /usr/obj
Now that you've got permissions straight, it's time to configure cvsup. First, you will need to create an appropriate supfile. This file sets a variety of defaults and will be read in by the cvsup program when you update your sources. Begin with one of the example files in /usr/share/examples/cvsup, perhaps standard-supfile. Look for a line that specifies the release and tag, for example:
*default release=cvs tag=RELENG_5_3
The tag specifies the branch of FreeBSD you want to track. In general, most carefully administered FreeBSD servers track the security branch which includes only critical bug and security fixes. Thus if you install FreeBSD 5.3, you will always be running FreeBSD 5.3 with patches, and the appropriate tag for this is in fact RELENG_5_3.
If the supfile you're working with indicates something other than a security branch, for example RELENG_5 (that indicates -STABLE) or just . (a period, that indicates -CURRENT), adjust the tag as appropriate. After you adjust the supfile, save your working file elsewhere, perhaps /usr/local/etc/security-supfile. Finally, update your FreeBSD sources by running:
% /usr/local/bin/cvsup -L 1 -h cvsup
x
.freebsd.org \
/path/to/your/chosen/supfile
Be sure to replace the x in cvsupx.freebsd.org above with a number corresponding to a cvsup mirror close to you.
Do not directly modify any of the example supfiles. If another example cvsup configuration file better suits your needs, use it instead. If you need to make drastic changes to any of these files, save a modified copy of the file elsewhere. You do not want to accidentally lose your changes during a system upgrade.
While it is possible to track the -STABLE branch, be aware that system upgrades may include more changes than you bargained for. Some administrators have had success carefully tracking the -STABLE branch by performing upgrades to noncritical servers and subsequently upgrading other servers (using source from the exact same time) after a great deal of testing. Other administrators have been badly burned by tracking this branch. Unless vital features or fixes exist in the -STABLE branch, stick with the security branch. Finally, forget about tracking -CURRENT on production infrastructure. It is too volatile and unreliable and is better suited to systems with which you tinker but not on which you rely.
After you have successfully performed an update, you have the opportunity to save your update preferences for later use. To do this, add a block similar to the following to /etc/make.conf(5):
SUP_UPDATE= yes
SUP= /usr/local/bin/cvsup
SUPFLAGS= -L 1
SUPHOST= cvsupx.freebsd.org
SUPFILE= /path/to/your/chosen/supfile
After doing this, you may update your sources by running make update from /usr/src.
For more information about cvsup including (and especially) using refuse files to tune which files or directories you retrieve, see the FreeBSD manpage for cvsup(1) and Appendix A.5 of the FreeBSD Handbook. To learn more about tracking branches of FreeBSD, see the relevant discussion in Chapter 4.
3.3.3.2 Kernel configuration
Before upgrading your system, you will probably want to fine-tune your kernel, both for security and performance reasons. Customizing your kernel configuration is typically recommended for FreeBSD systems, and only needs to be done immediately after the system is built and when you introduce new hardware. Given an environment where there are few hardware changes and consistent hardware across an infrastructure, the one time cost of fine-tuning yields rewards over the long term.
Creating a custom kernel configuration is almost never done from scratch. Typically you start from a copy of the /sys/conf/GENERIC kernel and remove options as necessary. In some cases it may be necessary to add hardware support from /sys/arch/conf/NOTES (In FreeBSD 4.x this file was LINT). As with installing distributions and packages, the following adage holds true: if you do not need it, do not install it. In a kernel context, this means if you do not need the kernel option, delete the configuration line and it will not be compiled in. The fewer drivers and options compiled into the kernel, the less always-running code there is to exploit.
Be careful with what you remove. It may not be obvious that some options are mandatory. For many releases, the COMPAT_43 option had the somewhat vague comment "Compatible with BSD 4.3" in the GENERIC file. Few administrators understood why they would want to be compatible with BSD 4.3 and removed this option. Then they discovered that their systems would no longer boot, and the comment now includes "[KEEP THIS!]."
The process of configuring a custom kernel is exceedingly well documented in Chapter 9 of the FreeBSD Handbook. While you need not actually compile or install your kernel in this step (we will do that in a moment as part of the system upgrade), now is a good time to create a configuration file for your custom kernel. The following list of options includes some of the changes you may want to make to the generic kernel for security reasons.
BPF
The Berkeley Packet Filter option in the kernel allows packet sniffers such as tcpdump(1) to function. On many servers, the bpf pseudodevice is probably not necessary. Some key exceptions are DHCP servers/clients and IDS hosts. Access to information provided by this pseudodevice relies on the user being able to read from /dev/bpf*. If you want to restrict snooping on network interfaces, remove the bpf device from your kernel configuration.
CD9660
Removing this option from the kernel will relegate the ISO9660 filesystem drivers to a kernel module. In a securelevel of 1 or greater, this module will not load, and access to a CD will require that you bring the system to single user mode or reboot. In a hostile physical environment, this may be desirable. In other cases, the administrative hassle will probably outweigh any security benefit.
DEBUG
This option is disabled by default and should remain that way on production servers. Turning this option on would cause symbols to not be stripped after linking yielding a larger kernel, larger core dumps (unless you have disabled core dumps using sysctl as described in Chapter 2), and more information in those core dumps.
IPv6, gif, faith
Falling under the category of "if you don't need it, don't install it," if IPv6 is not being used in your environment, there is no need to compile it into your kernel. Removing this option will shrink your kernel and allow for the removal of gif and faith devices that provide tunneling and relaying support for IPv6. Compiling without this option will also ensure that ports you build on your system after installing your new kernel do not have IPv6 support compiled in by default.
KTRACE
The KtrACE option in the kernel will provide for kernel tracing using ktrace(1) and kdump(1) as described in Chapter 2. This option is enabled by default. ktrace assists with debugging and providing empirical data regarding the types of I/O operations a program is requesting and arguments to these operations. As a result, ktrace can assist in leaking sensitive information to the individual running ktrace. Unless you plan on using ktrace for one of the purposes discussed in Chapter 2, it is probably best to leave this option out of the kernel.
MSDOSFS
The MS-DOS filesystem drivers will, like the ISO 9660 filesystem drivers, be compiled into a kernel module if this option is disabled. As with CD9660, the kernel module will not load at securelevel 1 or higher. In addition, even without this kernel option, mtools (in the FreeBSD ports collection) provides a means to access MS-DOS media without the support of this filesystem.
NFS
NFS between systems is rarely used on production systems with direct exposure to the Internet. Support for NFS and NFS_ROOT can be safely removed from your kernel configuration unless you plan to provide a locally accessible and read only master jail as described in Chapter 2, or your system is on a LAN and the situation calls for it.
UCONSOLE
This option allows non-root users to own the system console device (/dev/console). On an infrastructure system, there should be no need for users whatsoever. On a workstation or other server running X however, it is likely users will want to grab the console using programs like xconsole. Your situation will determine whether you want to leave this in.
USB
USB devices are invaluable on workstations. Some servers these days ship without integrated removable media bays at all and rely on the availability of USB floppies and CD-ROM drives. Your hardware will in large part determine whether USB devices should be supported by your kernel. In an untrusted environment, automatic support of USB media may not be desirable.
Remember that just because the functionality is not compiled into your kernel, you may still have access to it. Much of the kernel is modular, so even if you do not compile it in, you can load the appropriate module later, provided your system is running in a securelevel below 1.
Once you have decided how to build your custom kernel, save the configuration file with the other files in /sys/arch/conf. Be sure not to replace the original GENERIC configuration file, but instead, save your changes into another file, e.g., MYKERNEL.
3.3.3.3 Your first upgrade
With the latest sources sitting in /usr/src and a custom kernel configuration file ready, you're prepared to upgrade the system. This entire process has been comprehensively covered in Chapter 21 of the FreeBSD Handbook, so we will not waste time with the entire process here. Instead, a few do's and don'ts of upgrading your FreeBSD system.
• Do read /usr/src/UPDATING. Failure to do so could cause you to miss a step, rendering your system in a less-than-ideal state.
• Do create make.conf(5) for your system. If you plan to run a mail transport agent or nameserver installed from ports or ask a package, you would be well advised to configure make.conf so these binaries are not replaced during a system upgrade (this is less important during your first upgrade). Example 3-3 shows values in /etc/make.conf that might be appropriate for an i386 AMD based server with DNS software installed through ports instead of in the base system.
Example 3-3. Example /etc/make.conf for FreeBSD
CPUTYPE= k6-2
CFLAGS= -O -pipe
COPTFLAGS= -O -pipe
NO_BIND= true # no BIND
NOGAMES= true # no games (games/ subdir)
NOPROFILE= true # no profiled libraries
KERNCONF= MYCONFIG
BOOTWAIT= 3000
• In addition, your make.conf can assist with updating your source tree via make update by pointing it to your supfile and cvsup binary as described previously. For a full description of the options available in make.conf, see the make.conf(5) manpage.
• At this stage, don't worry about mergemaster(8) clobbering your configuration files. You haven't made any configuration changes yet. If you've never run mergemaster before, read the manpage. Table 3-2 describes options that may be useful to you in running mergemaster.
Table 3-2. Important mergemaster options
Option Description
-i If a file does not exist in /etc (it is being introduced as part of this upgrade), automatically install it.
-p Pre-buildworld mode. Compare files essential to the success of the buildworld/installworld process. Run this before buildworld.
-v Increase verbosity, useful the first time you run mergemaster.
-t [arg] Specify an alternate temporary root from which to make comparisons.
3.3.4. Step 4: Wrapping Up
With your FreeBSD system upgraded, it's time to turn your attention to some final system lockdown activities.
Thursday, August 7, 2008
How to Force fsck (Filesystem check) on next boot
If you want to force fsck on the next boot, just create a file called /forcefsck . If this file is present, then during next boot - the fsck is forced.
# touch /forcefsck
Now reboot the machine and when it comes up, fsck will be forced.
# reboot
# touch /forcefsck
Now reboot the machine and when it comes up, fsck will be forced.
# reboot
Red Hat – Tuning the Network Subsystem
Preventing a decrease in performance.
Disable the following parameters will prevent a hacker from using a spoofing attack against the IP address of the server:
sysctl –w net.ipv4.conf.eth0.accept_source_route = 0
sysctl –w net.ipv4.conf.lo.accept_source_route = 0
sysctl –w net.ipv4.conf.default.accept_source_route = 0
sysctl –w net.ipv4.conf.all.accept_source_route = 0
To prevent DOS (denial of service)
sysctl –w net.ipv4.tcp_syncookies = 1
Disable the following parameters will prevent a hacker from using a spoofing attack against the IP address of the server:
sysctl –w net.ipv4.conf.eth0.accept_source_route = 0
sysctl –w net.ipv4.conf.lo.accept_source_route = 0
sysctl –w net.ipv4.conf.default.accept_source_route = 0
sysctl –w net.ipv4.conf.all.accept_source_route = 0
To prevent DOS (denial of service)
sysctl –w net.ipv4.tcp_syncookies = 1
Subscribe to:
Comments (Atom)
