Compiling a new kernel
1) We must have installed the following packages:
- kernel-package
- libncurses5-dev
- fakeroot
- wget
- bzip2
- build-essential
If not, try to useapt-get [package name]after aapt-get update
2) Move to /usr/src/ path. To do this, usecd /usr/src
3) Get the Kernel. To this, open your browser and go tohttp://www.kernel.org and download the latest, or you needed.
You can use “wget” to this. For example if we want to use the 2-6-25 Kernel, we type this in the consolewget http://www.eu.kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.5.tar.gz
4) When the kernel have been downloaded. Unpack the ‘tar.gz’, usingtar xvf [tar.gz package name]
5) Make a simbolic link to the original folder which contains the (Just unpacked) Kernel. Typeln -s [Kernel folder name] linux.
Why we do this? The folder we created with “ln -s” it’s a simply link to the original folder. This folder it’s only to facilitate the work.
6) Move to the symnolic link folder “linux”. Just typecd linux
7) Make sure you’re in /usr/src/linux folder, and now typemake clean && make mrproper
8 ) Now, typemake menuconfigNOTE: There’s other kinds of compile, but i ever use this. It’s the most easy and secure, i think.
A screen like that will be loaded
In this, you must select the things you need to run your system and the modules you want.
Before this, you must save a configuration file with the settings you’ve selected.
9) Then, you must type the following:
make all
make modules_install
make install
10) We’ve installed out Kernel, but now we should say the system where’s the new Kernel.
To this, type:
depmod [number of kernel]Example -> depmod 2.6.21.5
apt-get install yaird
mkinitrd.yaird -o /boot/initrd.img-[Number of kernel] [Number of kernel]
update-grub
After all, we’ve compiled our own Kernel 
. To load it, just reboot the computer.
How to install mod_security for Apache
What is mod_security or modsecurity?
ModSecurity is an open source intrusion detection and prevention engine for web applications. It operates embedded into the web server, acting as a powerful umbrella - shielding applications from attacks. ModSecurity supports Apache web server.
Short explanation of how to embedd:
Installation
ModSecurity installation consists of the following steps:
1. ModSecurity 2.x works with Apache 2.0.x or better.
2. Make sure you have mod_unique_id installed.
mod_unique_id is packaged with Apache httpd.
3. Install the latest version of libxml2, if it isn't already installed on the server.
http://xmlsoft.org/downloads.html
4. Optionally install the latest version of Lua in the 5.1.x branch, if it isn't already installed on the
server and you will be using the new Lua engine.
http://www.lua.org/download.html
Note that ModSecurity requires the dynamic libraries. These are not built by default in the
source distribution, so the binary distribution is recommended.
5. Stop Apache httpd
6. Unpack the ModSecurity archive
7. Building differs for UNIX (or UNIX-like) operating systems and Windows.
• UNIX
a. Run the configure script to generate a Makefile. Typically no options are needed.
./configure
Options are available for more customization (use ./configure --help for a full
list), but typically you will only need to specify the location of the apxs command in-
stalled by Apache httpd with the --with-apxs option.
./configure --with-apxs=/path/to/httpd-2.x.y/bin/apxs
b. Compile with: make
c. Optionally test with: make test
NOTE: This is step is still a bit experimental. If you have problems, please send the
full output and error from the build to the support list. Most common issues are related
to not finding the required headers and/or libraries.
d. Optionally build the ModSecurity Log Collector with: make mlogc
e. Optionally install mlogc: Review the INSTALL file included in the
apache2/mlogc-src directory in the distribution.
f. Install the ModSecurity module with: make install
• Windows (MS VC++ )
a. Edit Makefile.win to configure the Apache base and library paths.
b. Compile with: nmake -f Makefile.win
c. Install the ModSecurity module with: nmake -f Makefile.win install
d. Copy the libxml2.dll and lua5.1.dll to the Apache bin directory. Alternat-
ively you can follow the step below for using LoadFile to load these libraries.
8. Edit the main Apache httpd config file (usually httpd.conf)
On UNIX (and Windows if you did not copy the DLLs as stated above) you must load libxml2
and lua5.1 before ModSecurity with something like this:
LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so
Load the ModSecurity module with:
LoadModule security2_module modules/mod_security2.so
9. Configure ModSecurity
10. Start Apache httpd
11. You should now have ModSecurity 2.x up and running.
Note
If you have compiled Apache yourself you might experience problems compiling ModSecurity
against PCRE. This is because Apache bundles PCRE but this library is also typically provided
by the operating system. I would expect most (all) vendor-packaged Apache distributions to be
configured to use an external PCRE library (so this should not be a problem).
You want to avoid Apache using the bundled PCRE library and ModSecurity linking against the
one provided by the operating system. The easiest way to do this is to compile Apache against the
PCRE library provided by the operating system (or you can compile it against the latest PCRE
version you downloaded from the main PCRE distribution site). You can do this at configure time
using the --with-pcre switch. If you are not in a position to recompile Apache, then, to com-
pile ModSecurity successfully, you'd still need to have access to the bundled PCRE headers (they
are available only in the Apache source code) and change the include path for ModSecurity (as
you did in step 7 above) to point to them (via the --with-pcre ModSecurity configure op-
ion).
Do note that if your Apache is using an external PCRE library you can compile ModSecurity with
WITH_PCRE_STUDY defined,which would possibly give you a slight performance edge in regu-
ar expression processing.
Latest release here!
QOS and IP Accounting with BGP under linux
At NSP we’ve go a fibre connection into the building, and a 10MBit feed from our ISP, and over that we’re allowed 10MBit of national and 3 Mbit PIR of international traffic. Note that this adds up to more than 10Mbit in total! This can cause annoying problems, like someone doing a lot of national or APE traffic at 10MBit, and closing out real international traffic. For a long time I’ve wanted to separate this out, but have not had the time to look into it
This week I finally organised a BGP from my ISP, and had a look at what my options were. I’d seen the Route-based QOS mini-HOWTO a while back, and it looked like it would work ok, but had a few problems. There’s no current way it to apply tc or iptables rules selectively based on a routing decision, or even on a route table. You can match on a route realm, however. The mini-HOWTO suggests copying your BGP routes into a separate table and into a realm at the same time, and then using tc and iptable’s realm matching code.
A quick aside: route realms are best described as a collection of routes. The decision as to which realm a route is placed is made by the local administrator, and each realm can contain routes from a mix of origins. Realms are used to allow administrators to perform bulk operations on large groups of routes in an easy manner. From the iproute command reference:
The main application of realms is the TC route classifier [7], where they are used to help assign packets to traffic classes, to account, police and schedule them according to this classification.
After a bit of digging, I found a link to a patch for quagga to provide route realms support. It’s even still maintained! After a bit of battling with autotools[1], and a bit of battling with linux capabilities[2], I had it up and running.
The route realms patch page covered off the BGP configuration I needed, and now I have a set of iptables counters for national, international and total traffic (for completeness). The only bit it doesn’t cover off is graphing, but we already have a set of perl scripts which pull information from interface totals or iptables FWMARK counters, so I modified that to pull from these counters as well, and set up RRD graphs. I was previously graphing interface totals out the external nic, and it’s interesting to note that the iptables “total” traffic, while adding up to the sum of national and international, does not correspond to the interface totals.
It’s worth pointing out that, as seen in iproute command reference, the rtacct tool will grab realm counts for you without needing iptables, so if you just want to something to graph things quickly, rtacct might do the job:
Realm BytesTo PktsTo BytesFrom PktsFrom
BPSTo PPSTo BPSFrom PPSFrom
unknown 5949K 57188 15839K 61776
0 0 0 0
national 15839K 61776 5949K 57188
0 0 0 0
rtacct has a naive limit of 256 realms however, where as the actual implementation supports a 16 bit number, so if you have a large number of realms, or you autoclassify your inbound BGP into realms based on the AS number, you will have to use iptables only
I’m currently only accounting for traffic using this mechanism, but I can also do QOS on it - tc will match directly on realm tags, and any iptables based match systems you may have can be adapted to match on a realm as well.
[1] The realms patch touched configure.ac, which then required the autotools chain to rebuild everything, but it needed a very particular combination of autoconf and automake. Because it took me an hour or so to get this right, I’ll record it here:
aclocal-1.7
autoheader
autoconf
autoconf2.50
libtoolize -c
automake-1.7 –gnu –add-missing –copy
./configure –enable-realms –enable-user=quagga –enable-group=quagga –enable-vty-group=quaggavty –enable-vtysh –localstatedir=/var/run/quagga –enable-configfile-mask=0640 –enable-logfile-mask=0640
autoheader and autoconf above are version 2.13. I have no idea why I had to run autoconf2.13 then autoconf2.50, but it seems that this actually worked.
[2] I initially tried building against quagga-0.98.6, because the quaggarealms patch site implied this was the “stable” verson, but it seems that quagga drops priviledges too soon. This works out fine if you have “capabilities” support in your kernel, which mine didn’t. They’ve changed this behaviour in 0.99.5, and incidentally this is the version in debian etch.