Auf der http://www.modsecurity.org website findet man den Link zu den mod_security Debian Paketen. (Community-Produced Binary packages)

Bemerkung: Man sollte auf der Webseite nach den neusten Versionen schauen und die Beispiel “wget” Befehle in dieser Anleitung anpassen.

1. Herrunterladen der Pakete und Installation mit dpkg:

wget http://etc.inittab.org/~agi/debian/libapache-mod-security2/2.5.x/etch/libapache2-mod-security2_2.5.5-1~etch1_amd64.deb
wget http://etc.inittab.org/~agi/debian/libapache-mod-security2/2.5.x/etch/mod-security2-common_2.5.5-1~etch1_all.deb

dpkg -i mod-security2-common_2.5.5-1~etch1_all.deb libapache2-mod-security2_2.5.5-1~etch1_amd64.deb

Bemerkung: Man benötigt ggf. ein anderes Paket als amd64 !!!

2. Unterverzeichnis für die mod_security Regeln im Apache Konfigurationsverzeichnis anlegen:

mkdir /etc/apache2/modsecurity2
chmod 600 /etc/apache2/modsecurity2

3. Herrunterladen der Regeln von http://www.modsecurity.org/download/direct.html

wget http://www.modsecurity.org/download/modsecurity-core-rules_2.5-1.6.1.tar.gz

anschließend entpacken und die conf-Dateien in das angelegte Verzeichnis verschieben:

tar vfx modsecurity-core-rules_2.5-1.6.1.tar.gz
mv *.conf /etc/apache2/modsecurity2/

4. Außerdem muss man einen Symlink anlegen um das Apache Log-Verzeichnis an das von Debian anzupassen.

(Oder man passt alle Regeln an )

ln -s /var/log/apache2 /etc/apache2/logs

5. Modsecurity aktivieren

a2enmod mod-security

6. Konfiguration

Bearbeiten de Datei “/etc/apache2/conf.d/mod_security”:

        # mod_security configuration directives
        # ...
        # Turn the filtering engine On or Off
        SecFilterEngine On

        # Some sane defaults
        #Check if URL characters where encoded
        SecFilterCheckURLEncoding On
        #Check UTF-8 encoding
        SecFilterCheckUnicodeEncoding Off

        #Allow 1 byte characters
        # Accept almost all byte values
        SecFilterForceByteRange 0 255

        # Server masking is optional
        # SecServerSignature "Microsoft-IIS/0.0"

        SecAuditEngine RelevantOnly
        # The name of the audit log file
        SecAuditLog /var/log/apache2/audit_log

        # You normally won't need debug logging
        # Debug level set to a minimum
        SecFilterDebugLog /var/log/apache2/modsec_debug_log
        SecFilterDebugLevel 0

        # Should mod_security inspect POST payloads
        SecFilterScanPOST On

        # By default log and deny suspicious requests
        # with HTTP status 500
        SecFilterDefaultAction "deny,log,status:500"

7. Nun nur noch den Apache Webserver neu starten:

/etc/init.d/apache2 restart

8. Links:

http://www.modsecurity.org
http://www.howtoforge.com/apache_mod_security
http://www.debuntu.org/2006/08/13/86-secure-your-apache2-with-mod-security

1. Installieren von apcupsd

aptitude install apcupsd

2. Konfiguration

vim /etc/apcupsd/apcupsd.conf

Wenn die Verbindung mit einem USB Kabel hergestellt werden soll:

# USB configuration
UPSCABLE usb
UPSTYPE usb

Wenn die Verbindung über das Netzwerk hergestellt werden soll:

# Network configuration
UPSCABLE ether
UPSTYPE snmp
DEVICE IP_OF_THE_UPS:161:APC:private

Die Optionen “MINUTES” und “TIMEOUT” sollte man sich genauer anschauen. MINUTES=3 bedeutet, das sich der Server herrunterfährt, wenn die USV eine Restlaufzeit von 3 Minuten erreicht hat. TIMEOUT=0 deaktiviert das herrunterfahren des Servers nach X Sekunden im Batteriebetrieb.

3. Konfiguration aktivieren

vim /etc/default/apcupsd

ISCONFIGURED=yes

4. apcupsd starten

/etc/init.d/apcupsd start
apcaccess status

Dies sollte einige Informationen zur USB ausgeben. (Siehe Screenshots)

5. Installation Webinterface

aptitude install apcupsd-cgi

http://IP_OF_YOUR_SERVER/cgi-bin/apcupsd/multimon.cgi

[Show as slideshow]

6. Verwendung von CACTI

Im Cacti Forum http://forums.cacti.net/about15908.html finden sich templates mit denen die APC UPS sehr einfach überwacht werden kann.

Falls eine USB Verbindung verwendet wird, sollte man sich das apcupsd Template ansehen. http://forums.cacti.net/about14481.html
Damit können verschiedene apcupsd über das Netzwerk oder auf dem lokalem Server abgefragt werden. Man sollte die Installationsanleitung lesen, sowie die Kommentare im Cacti Forum. Die Pfade im check Skript müssen angepasst werden und ich musste die “content” Zeilen aus den beiden Skripts entfernen.

Der bereits erwähnte Debian Router soll nun um einen OpenVPN Server erweitert werden.

Um nicht noch ein weiteres Subnetz für die VPN-Clients aufbauen zu müssen, wird der so genannte Bridging-Modus verwendet. Dabei handelt es sich um einen Tunnel auf Ethernetebene, der die Clients vollständig in das Netzwerk integriert.

Installation:

aptitude install openvpn bridge-utils iproute openssl

Zuerst muss man mit Hilfe von openssl die benötigten Schlüssel für die “Pre-shared Key Authentication” anlegen:

cd /usr/share/doc/openvpn/examples/easy-rsa/2.0

. ./vars 
./clean-all 
./build-ca 

./build-key-server server 
./build-key vpnclient 
./build-dh 

mv keys /etc/openvpn/

Die Dateien ca.crt, vpnclient.key sowie vpnclient.crt müssen auf den VPN Client übertragen werden.

Als nächstes muss ein Bridgeinterface angelegt werden, um den oben genannten Bridgemodus zu realisieren. Dazu muss man die Datei /etc/network/interfaces bearbeiten und folgendes am Ende einfügen:

# # # # # # # # # # # # # # # # # # # # # # # # # # # # 
# VPN Bridge 
auto br0 
iface br0 inet static 
        address 192.168.0.1 
        netmask 255.255.255.0 
        pre-up /usr/sbin/openvpn --mktun --dev tap0 
        pre-up /sbin/ip link set tap0 up 
        pre-up /sbin/ip link set eth1 up 
        pre-up /usr/sbin/brctl addbr br0 
        pre-up /usr/sbin/brctl addif br0 eth1 
        pre-up /usr/sbin/brctl addif br0 tap0 
        pre-up /sbin/ifconfig eth1 0.0.0.0 promisc up 
        pre-down /usr/sbin/brctl delif br0 eth1 
        pre-down /sbin/ip link set eth1 down 
        pre-down /usr/sbin/brctl delif br0 tap0 
        pre-down /sbin/ip link set tap0 down 
        post-down /usr/sbin/brctl delbr br0 
        post-down /usr/sbin/openvpn --rmtun --dev tap0
# # # # # # # # # # # # # # # # # # # # # # # # # # # # 

Dabei ist die IP Adresse 192.168.0.1 die Adresse des Interfaces, in dessen Subnetz man die Bridge aufbauen will. Dabei wird die Adresse vom eth1 Device auf das neu angelegte br0 Device übertragen. Außerdem ein tap0 Interface für OpenVPN vorbereitet. Anpassen an seine eigene Konfiguration muss man hier also eth1, address und ggf. die netmask.

Wichtig ist nun natürlich, das die beiden neuen Netzwerkinterfaces in die IPTables (Firewall) aufgenommen werden:

iptables -A INPUT   -i tap0 -j ACCEPT
iptables -A INPUT   -i br0  -j ACCEPT
iptables -A OUTPUT  -i tab0 -j ACCEPT
iptables -A OUTPUT  -i br0  -j ACCEPT
iptables -A FORWARD -i tap0 -j ACCEPT
iptables -A FORWARD -i br0  -j ACCEPT

Nun kann der VPN Server konfiguriert werden. Dazu sollte man zuerst die Beispiel Server Konfigurationsdateien entpacken und diese in das OpenVPN Verzeichnis kopieren:

cd /usr/share/doc/openvpn/examples/sample-config-files
gzip -d server.conf.gz
cp server.conf /etc/openvpn/networkVPN.conf

Anschließend muss man diese Datei bearbeiten und folgende Änderungen vornehmen:

dev tap
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pm
server-bridge 192.168.0.1 255.255.255.0 192.168.0.201 192.168.0.250
client-to-client
push "redirect-gateway"
push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DEFAULT_GATEWAY 192.168.0.1"
push "dhcp-option DNS 192.168.0.1"
push "dhcp-option DOMAIN network.lan"
push "dhcp-option WINS 192.168.0.1"

Dabei ist zu beachten das “dev tap” “dev tun” ersetzt und “server-bridge” ersetzt “server” diese Einträge müssen also auskommentiert werden. Außerdem muss natürlich der Port des OpenVPN Servers (Default: 1194 UDP) in der Firewall freigegeben werden, damit die Clients den Server errreichen können.

Anschließend kann der OpenVPN Server neu gestartet werden:

/etc/init.d/openvpn start

Der VPN Server sollte nun laufen, und man kann die Clients konfigurieren. Auf jedem Client müssen die Dateien ca.crt, vpnclient.key und vpnclient.crt vorhanden sein. Man kann dabei entweder für jeden Client eigene Zertifikate und Schlüssel erzeugen, oder man aktiviert in der Server Konfiguration zusätzlich die Option “duplicate-cn”. Damit kann ein Clientzertifikat für mehrere Verbindungen von verschiedenen Clients benutzt werden.

Unter Ubuntu kann die VPN Verbindung direkt über den Netzwerkmanager hinzugefügt werden.

Bekannt sind diese eventuell von den weit verbreiteten DS1820 Temperatursensoren. Erhältlich sind sie hier: www.hobby-boards.com

Nachdem ich den Bausatz für Temperatur, Licht und Luftfeuchtigkeit (Humidity/Temp/Solar Kit) zusammengebaut hatte, musste ich diese noch gut geschützt draußen montieren.
Zwar ist die Platine auch im dazu erhältlichen Gehäuse bereits gut untergebracht, ich wollte jedoch noch einen kleinen zusätzlichen Schutz vor Wind und Wetter.

[Show as slideshow]

Dieses kleine Gehäuse befindet sich an der süd-ostlichen Seite des Hauses in ca. 1,5 m Höhe. Außerdem befindet sich so das Gehäuse noch unter der Überdachung des Hauses. Es besteht aus Sperrholz sowie einer massiven Holzplatte als Rückwand. Als Schutz habe ich das ganze noch zweimal mit einer Holzlasur gestrichen.

Angeschlossen ist das ganze über ein normales Netzwerkkabel mit RJ-45 Stecker.

Das andere Ende des Kabels folgt im nächsten Teil …

Nach dieser Anleitung soll OpenBlueDragon mit Tomcat 5.5 unter Debian Etch installiert werden. Anschließend soll Tomcat mit mod_jk mit dem Apache2 verbunden werden.

Natürlich kann diese Anleitung auch verwendet werden, um nur den Tomcat zusammen mit Apache einzurichten. In diesem Fall müssen nur die OpenBlueDragon Abschnitte ausgelassen werden.

Es gibt verschiedene Gründe warum man Tomcat zusammen mit Apache einsetzt. Der Apache kann langsame Verbindugen Buffern, man kann mit weitere Funktionen benutzen wie PHP oder Perl, Apache Module stehen zur Verfügung wie mod_rewrite außerdem können die Virtuellen Hosts so konfiguriert werden, dass sie eigene Tomcat Instanzen benutzen.
.

Für die Installation von Tomcat wird jedoch zuerst noch das Sun Java JDK gebraucht. Um diese zu installieren mussen in der /etc/apt/sources.list die “non-free” Pakete hinzugefügt werden:

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

Anschließend kann mit

# aptitude update
# aptitude install sun-java5-jdk

das Sun Java JDK installiert werden.

Nun kann Apache Tomcat installiert werden:

# aptitude install tomcat5.5 tomcat5.5-admin tomcat5.5-webapps

Um zu überprüfen ob Tomcat läuft, kann man folgende URL im Browser aufrufen: http://SERVER:8180

Als nächstes muss ein Benutzer konfiguriert werden, mit dem Tomcat verwaltet werden soll.

# /etc/init.d/tomcat5.5 stop
# vim /var/lib/tomcat5.5/conf/tomcat-users.xml

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="admin"/>
<role rolename="manager"/>
<role rolename="tomcat"/>
<user username="admin"
password="foobar"
roles="tomcat,admin,manager"/>
</tomcat-users>

# vim /etc/default/tomcat5.5
TOMCAT5_SECURITY=no

# /etc/init.d/tomcat5.5 start

Natürlich sollte das Passwort durch ein eigenes ersetzt werden ! Das deaktivieren von TOMCAT5_SECURITY ist notwendig um Zugriff auf die Administration zu erhalten. Sollte man die Administration nicht benötigen kann diesen Schritt natürlich weglassen oder nach dem festlegen der Einstellungen wieder aktivieren.

Nun kann man sich in den Tomcat Manager einloggen http://SERVER:8180/manager/html sowie in den Administrator http://SERVER:8180/admin

Dort kann im Abschnitt “Deploy” das openbluedragon.war Paket hochgeladen werden.

Nach dem Neustart von Tomcat “/etc/init.d/tomcat5.5 restart” findet man openbluedragon in der Applications List im Tomcat Manager.

Installation Apache2 mit Tomcat-Connector

Tomcat besitzt zwar einen eingebauten Webserver, jedoch ist der Apache2 Webserver wesentlich Leistungsfähiger.

Installation:

# aptitude install apache2 libapache2-mod-jk
# vim /etc/apache2/workers.properties

workers.tomcat_home=/usr/share/tomcat5.5
workers.java_home=/usr/lib/jvm/java-1.5.0-sun-1.5.0.14
ps=/
worker.list=default
worker.default.port=8009
worker.default.host=localhost
worker.default.type=ajp13
worker.default.lbfactor=1
JK Konfigurationsdatai
# vim /etc/apache2/conf.d/jk.conf
<IfModule mod_jk.c>
    JkWorkersFile /etc/apache2/workers.properties
    JkLogFile /var/log/apache2/mod_jk.log
    JkLogLevel error
</IfModule>

# /etc/init.d/apache2 stop
# /etc/init.d/tomcat5.5 restart
# /etc/init.d/apache2 start

Nun soll ein neuer VirtualHost angelegt werden. Dieser muss im Apache und im Tomcat angelegt werden.

Verzeichnise vorbereiten:

# mkdir /var/www/vhost1
# mkdir /var/www/vhost1/htdocs
# mkdir /var/www/vhost1/logs

WEB-INF kopieren:

# cp /var/lib/tomcat5.5/webapps/openbluedragon/WEB-INF /var/www/vhost1/htdocs/

VirtualHost im Apache anlegen:

# vim /etc/apache2/sites-available/vhost1

<VirtualHost www.testsrv.local>
    JkMount /*.cfm default
    JkMount /*.cfc default
    JkMount /*.jsp default
    ServerName www.testsrv.local
    ServerAdmin servermaster@testsrv.local
    DocumentRoot /var/www/vhost1/htdocs
    ErrorLog /var/www/vhost1/logs/error.log
    CustomLog /var/www/vhost1/logs/access.log common
    <Location /WEB-INF/ >
      AllowOverride None
      deny from all
    </Location>
</VirtualHost>

# a2ensite vhost1
# /etc/init.d/apache2 reload

Bemerkung: Man könnte auch alle Dateien an den Tomcat weiterleiten “JkMount /*” oder alle Dateien innerhalb eines Verzeichnisses “JkMount /folder/*“.

Host im Tomcat anlegen:

# vim /etc/tomcat5.5/server.xml

<!-- www.testsrv.local -->
<Host name="www.testsrv.local" appBase="/var/www/vhost1"
      unpackWARs="true" autoDeploy="true">
      <Context path="" docBase="htdocs" debug="0" reloadable="true"/>
      <Valve className="org.apache.catalina.valves.AccessLogValve"
             directory="/var/www/vhost1/logs"  prefix="tomcat_access_" suffix=".log"
             pattern="common" resolveHosts="false"/>
</Host>

Zum Schluss muss man den Tomcat sowie den Apache Server neu starten:

# /etc/init.d/tomcat5.5 restart
# /etc/init.d/apache2 restart

[UPDATE]

Von diesen Artikel ist eine neue Version Verfügbar Tomcat 6 mit Lenny und OpenBlueDragon auf Tomcat 6

Installation:

aptitude install fail2ban

Die fehlgeschlagenen Loginversuche werden von Fail2ban durch Filterregeln ermittelt. Für ssh existiert bereits eine Filterregel, für webmin muss man selbst eine anlegen. Dazu kopiert man zuerst die Filterregel für ssh

cp /etc/fail2ban/filter.d/sshd.conf /etc/fail2ban/filter.d/webmin.conf
vim /etc/fail2ban/filter.d/webmin.conf

und tauscht anschließend die Zeile mit der “failregex” durch diese aus

failregex = (?:(?:Invalid login|Non-existent login) as(?: [iI](?:llegal|nvalid) user)
?|[Ii](?:llegal|nvalid) user|ROOT LOGIN REFUSED) .*(?: from|FROM) <HOST>

Nun kann man die fail2ban Konfiguration anpassen:

touch /etc/fail2ban/jail.local
vim /etc/fail2ban/jail.local

und dort folgenden Inhalt einfügen:

[ssh]
enabled = true
port    = 22
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 3

[webmin]
enabled = true
port    = 10000
filter  = webmin
logpath  = /var/log/auth.log
maxretry = 3

Anschließend muss Fail2ban neu geladen werden, damit die Konfiguration übenommen wird.

fail2ban-client reload

Fail2ban legt für jeden Service eine eigene Chain in den INPUT IPTables an. In diesem Fall also “Run chain fail2ban-webmin” und “Run chain fail2ban-ssh“. In diesen Chains werdem alle IP Adressen vermerkt, welche die maximale Anzahl von Loginversuchen überschritten haben, und damit ausgesperrt sind. Wenn die “bantime” vorüber ist, werden die Einträge wieder entfernt. Man sperrt sich also selbst nicht für immer aus, wenn man mal selbst zuoft ein falsches Passwort eingegeben hat.

Natürlich kann man auf diese Weise noch weitere Dienste wie Apache usw. entsprechend absichern. Fail2ban liefert dafür bereits einige entsprechende Filter mit.

Bei der Installation des Debian Routers habe ich bereits Erfahrungen mit dem Software RAID unter Linux gemacht. Dort wurde das RAID jedoch gleich bei der Installation angelegt, dies geht durch die Installationsroutine relativ leicht.

Nachdem ich nun meinen Fileserver schon vor einiger Zeit auf Debian umgestellt habe, war das Problem, dass das SATA RAID 5 des Gigabyte Mainboards nicht unter Linux läuft, da es sich leider dabei um kein echtes RAID handelt. Aus diesem Grund soll es durch ein Linux Software RAID ersetzt werden.

Installation:
aptitude install mdadm

In dieser Konfiguration sollen die Festplatten sda sdb sdc sdd zu einem RAID 5 verbunden werden.
Auf jeder Platte muss eine leere Primäre Partition angelegt sein.

fdisk /dev/sda
Bevor man eine Partition anlegen kann, muss man zuerst eine neue DOS Partitionstabelle erzeugen. Dies geschieht mit “o“.
Danach “n” auswählen um eine neue Partition anzulegen. Danach “p” für eine primäre Partition sowie “1” als Partitionsnummer. Die Frage nach dem Ersten und Letzten Zylinder sollte man auf den Standardeinstellungen belassen.
Mit “w” werden die Änderungen übernommen und fdisk wieder verlassen (kann etwas dauern). Mit “q” wird fdisk verlassen ohne die Änderungen zu speichern.
Dies wird nun für sdb, sde und sdd wiederholt, bzw. auf einer anderen Konsole parallel ausgeführt.

Nun sollte “ls /dev/sd*” für jede Festplatte auch eine Partiton anzeigen. Dies sieht man daran das für /dev/sda nun auch /dev/sda1 vorhanden ist. Für sdb,sdc und sdd natürlich analog.

Als nächstes wird nun das RAID angelegt. Dazu öffnet man die Konfigurationsdatei /etc/mdadm/mdadm.conf und fügt die folgenden beiden Zeilen an:

DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
ARRAY /dev/md0 level=raid5 devices=/dev/sda1,/dev/sdb1,/dev/sdc1,/dev/sdd1

Danach kann man das Software RAID starten:

mdadm -As /dev/md0

Nun kann man sich mit:

mdadm –detail /dev/md0

Den Status und einige andere Informationen des RAIDs anzeigen lassen. Unter anderem ist folgende Zeile wichtig:

Rebuild Status : 2% complete

Das RAID wird also im Hintergrund gerade aufgebaut. Es kann aber bereits verwendet werden. Außerdem:

Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

Zeigt an, dass alle 4 Festplatten arbeiten und keine ausgefallen ist.

Nun kann die Raid Festplatte md0 wie jede andere Formatiert werden zum Beispiel mit EXT3:

mke2fs -j /dev/md0

Danach kann man die Partiton mounten

mount /dev/md0 /media/raid

bzw. zur /etc/fstab hinzufügen:

/dev/md0 /media/raid ext3 suid,dev,exec  0  0

Der bereits erwähnte Debian Router soll nun um einen DHCP Server erweitert werden. Der DNS Server wurde bereits im ersten Teil der Debian Router Installation installiert. Er muss nun noch konfiguriert werden.

Dabei sollen 2 Subnetze angelegt werden, ein sicheres (192.168.0.0) sowie ein Subnetz für Gäste (192.168.1.0)

Die Konfiguration des DHCP und DNS Servers erfolgt am einfachsten mit Webmin. Leider ist das Standard Webmin DNS Modul dafür nur bedingt geeignet. Man sollte sich das Bind9 Webmin Modul herrunterladen und installieren. (http://sourceforge.net/projects/b9ddns)

Nun kann man unter Webmin im Menü “Server” den DNS Server unter “BIND 9 dynamic DNS Server” den DNS Server konfigurieren:

Zuerst müssen drei neue “Master Zones” angelegt werden:

Zone type:                      Forward
Domain name / IP subnet:        network.lan
Master server:                  ROUTER.
Email address:                  root@localhost

Zone type:                      Reverse
Domain name / IP subnet:        192.168.0
Master server:                  ROUTER.
Email address:                  root@localhost

Zone type:                      Reverse
Domain name / IP subnet:        192.168.1
Master server:                  ROUTER.
Email address:                  root@localhost

Nun muss man diese Zonen in dynamische Zonen umwandeln. Dies ist notwendig, damit der DHCP Server die Informationen des DNS Servers aktualisieren kann. Dazu wird unter “Access Controll List” eine neue “ACL” angelegt.

Name:                   dhcp
Matching addresses:     127.0.0.1
                        192.168.0.1
                        192.168.1.1

In jeder Zone kann man nun unter “Edit Zone Options” dhcp in das Feld “Allow updates from …” eintragen. Der Titel “Static Master Zone” sollte sich nun in “Dynamic Master Zone” geändert haben.

Nun kann man die /etc/resolv.conf Datei anpassen. Dort sollten aktuell die Nameserver des Providers eingetragen sein, diese können entfernt werden und durch diesen Eintrag ersetzt werden:

nameserver 127.0.0.1
search network.lan

Jetzt muss natürlich verhindert werden, das bei der nächsten ppp Einwahl wieder die Nameserver des Providers eingetragen werden. Dazu editiert man die Datei /etc/ppp/peers/dsl-provider und kommentiert den Eintrag “usepeerdns” aus.

Da der Router selbst natürlich seine IP Adressen nicht dynamisch vom DHCP Server bezieht (lokal), muss er manuell im DNS Server hinterlegt werden. Dazu bearbeitet man die “Master Zone” “network.lan”. Unter dem Menüpunkt “Address” kann man manuell einen “Address Record” hinzufügen:

Name:                   ROUTER
Address:                192.168.0.1
Create reverse record?: Yes or update existing  

Damit wäre der DNS Server soweit konfiguriert und man kann sich nun den DHCP Server vornehmen.

Installation:

aptitude install dhcp3-server

Die Konfiguration erfolgt nun wieder mit Hilfe von Webmin. Diese ist in Webmin unter “Servers – > DHCP Server” zu finden.

Wie bereits erwähnt, soll das Subnetz 192.168.0.0 als sicheres Subnetz dienen. Das heißt es sollen nur bekannte Clients und Server eine IP Adresse vom DHCP Server erhalten. Jeder dieser bekannten Clients und Server muss unter “Hosts” einzeln angelegt werden:

Hostname: TESTCLIENT
Hardware : XX:XX:XX:XX:XX:XX

Als nächstes müssen die entsprechenden Subnetze angelegt werden:

Network address:                              192.168.0.0
Netmask:                                      255.255.255.0
Address ranges:                               192.168.0.100 - 192.168.0.200
Dynamic DNS enabled?:                         Yes
Dynamic DNS reverse domain:                   0.168.192.in-addr.arpa
Dynamic DNS domain name:                      network.lan
Server is authoritative for this subnet?:     Yes
Allow unknown clients?:                       Ignore
Hosts directly in this subnet:                TESTCLIENT

Network address:                              192.168.1.0
Netmask:                                      255.255.255.0
Address ranges:                               192.168.1.100 - 192.168.1.200
Dynamic DNS enabled?:                         Yes
Dynamic DNS reverse domain:                   1.168.192.in-addr.arpa
Dynamic DNS domain name:                      network.lan
Server is authoritative for this subnet?:     Yes
Allow unknown clients?:                       Allow

Außerdem muss man die globalen Clienteinstellungen unter “Edit Client Options” anpassen:

Domain name: network.lan
DNS servers: 192.168.0.1 192.168.1.1
Dynamic DNS enabled? Yes
Dynamic DNS update style: Interim
Allow unknown clients?: Ignore

Zum Schluß müssen noch die entsprechenden dynamischen Zonen, welche im DNS Server angelegt wurden, im DHCP Server eingetragen werden. Dies geschieht über “Add a new DNS zone”:

Name of zone:           network.lan
IP of primary NS:       127.0.0.1

Name of zone:           0.168.192.in-addr.arpa
IP of primary NS:       127.0.0.1

Name of zone:           1.168.192.in-addr.arpa
IP of primary NS:       127.0.0.1

Unter “Configfile” kann man sich nun die entsprechend erzeugten Einträge ansehen. Hier muss man die “zone” Einträge suchen und die “key ;” Zeilen auskommentieren. Auf diese Einträge werden wir später noch eingehen.

Jetzt fehlen nur noch die entsprechenden Rechte und man kann DNS und DHCP Server mit der neuen Konfiguration starten:

chmod g+w /etc/bind
/etc/init.d/bind9 restart
/etc/init.d/dhcp3-server restart

Mit “dhclient eth0″ kann man nun auf dem Testclient eine IP-Adresse vom DHCP Server anfordern. Diese sollte man auch im Webmin unter “DHCP Leases” einsehen können. Zusätzlich sollte im DNS Server auch in jeder der drei angelegten Zonen unter “Address” ein Eintrag mit dem Namen und der Adresse des Testclients angelegt worden sein.

Nun wollen wir auf die “key” Einträge zurückkommen. Diese dienen dazu die Verbindung zwischen DNS und DHCP Server weiter abzusichern. Im Syslog findet man aktuell noch Einträge dieser Art:

named[30576]: zone 'network.lan' allows updates by IP address, which is insecure
named[30576]: zone '0.168.192.in-addr.arpa' allows updates by IP address, which is insecure
named[30576]: zone '1.168.192.in-addr.arpa' allows updates by IP address, which is insecure

Dies liegt daran, dass die Authentifizierung anhand einer ACL, welche beim DNS Server eingerichtet wurde funktioniert. (siehe Beginn des Artikels) Diese Methode ist einfacher, und ist für die ersten Funktionstests ausreichend. Nun soll sie durch eine RNDC-Key Authentifizierung ersetzt werden. Der dafür notwendige Schlüssel wurde bereits bei der “bind9″ installation automatisch erzeugt und in der Datei /etc/bind/rndc.key gespeichert. Zuerst muss dieser Key nun kopiert werden:

cp /etc/bind/rndc.key /etc/rndc.conf

Danach wird die Datei /etc/rndc.conf bearbeitet, sodass sie folgendes Aussehen hat:

key "rndc-key" {
    algorithm hmac-md5;
    secret "HERE_IS_YOUR_OWN_KEY";
};
options {
    default-server localhost;
    default-key "rndc-key";
};

Nun muss dieser Schlüssel in die Datei /etc/bind/named.conf eingebunden werden. Dazu muss zuerst der entsprechende ACL-Eintrag

acl dhcp {
    127.0.0.1;
    192.168.0.1;
    192.168.1.1;
};

entfernt werden und durch den Schlüsseleintrag ersetzt werden.

include "/etc/bind/rndc.key";
controls {
    inet 127.0.0.1 allow {localhost;} keys {rndc-key;};
};

Danach muss bei jeder Zone im DNS Server der Eintrag

allow-update { dhcp; };

durch diesen ersetzt werden

allow-update { key "rndc-key"; };

Nun kann man auch den DHCP Server auf die neue authentifizierung anpassen indem man folgende Zeile in der Datei /etc/dhcp3/dhcpd.conf hinzufügt:

include "/etc/bind/rndc.key";

Die vorher auskommentierten “key ;” Einträge werden nun durch

key rndc-key ;

ersetzt.

Zum Schluss muss man nur noch DHCP und DNS Server neu starten

/etc/init.d/bind9 restart
/etc/init.d/dhcp3-server restart

Links:

http://www.linux-home-server.de
http://wiki.slashconcept.com/index.php/BIND_9_DNS_Server_unter_Debian_GNU_Linux_4.0_Etch_Howto_(LAN)
http://linuxwiki.de/debian-dhcp
http://www.howtoforge.com/dhcp_server_linux_debian_sarge
http://www.schoki.org/ddns/ddns.html

In diesem Beispiel ist das DSL-Modem an eth0 angeschlossen. An eth1 und eth2 befindet sich das interne Netzwerk.

Zuerst benötigt man die zur DSL Verbindung notwendigen Pakete sowie den DNS Server bind9:

aptitude install bind9 ppp pppoe 

Als nächstes müssen die DSL Zugangsdaten in die Datei “/etc/ppp/pap-secrets” eingetragen werden. Im Falle von T-Online sieht dies ca. so aus:

"11111111111111111111111100001@t-online-com.de" * "DSL_PASSWORD"

Die Nummer setzt sich zusammen aus “T-Online-Nummer” “Anschlusskennung” “00001″ jeweils ohne Leerzeichen hintereinander geschrieben. Bei einem anderen Provider müssen die Zugangsdaten entsprechend angepasst werden.

Der Benutzer muss nun auch in die Datei “/etc/ppp/peers/dsl-provider” eingetragen werden:

user "11111111111111111111111100001@t-online-com.de"

Anschließend muss noch der Eintrag:

net.ipv4.ip_forward = 1

in der Datei “/etc/sysctl.conf” eingefügt bzw. auskommentiert werden. Damit wird die Weiterleitung von IP Paketen ermöglicht.

Mit dem Befehl

sysctl -p

werden die Einstellungen übernommen.

Für die automatische Einwahl, wird die ppp Verbindung zur Netzwerkinterfacekonfiguration “/etc/network/interfaces” hinzugefügt:

# DSL Network Interface
auto t-online
iface t-online inet ppp
provider dsl-provider

Zusätzlich sind in dieser Datei noch die beiden folgenden Einträge erforderlich:

pre-up iptables-restore < /etc/iptables.up.rules
pre-down iptables-save > /etc/iptables.up.rules

Diese sorgen dafür das die IPTables gespeichert werden und beim Wiederherstellen der Netzwerkverbindungen neu geladen werden.

Nun kann man einige Basic IP-Tables einspielen. Die folgenden Befehle legen diese an und stellen damit die Grundlegende Routerfunktionalität bereit.
Desweiteren stellen sie bereits eine einfache Firewall dar. Diese sollte natürlich noch erweitert werden.

# Eingangseinstellungen
iptables -A INPUT -p ALL -i lo0 -j ACCEPT
iptables -A INPUT -p ALL -i eth0 -j ACCEPT
iptables -A INPUT -p ALL -i eth1 -j ACCEPT
iptables -A INPUT -p ALL -i eth2 -j ACCEPT
iptables -A INPUT -p ALL -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Ausgangseinstellungen
iptables -A OUTPUT -m state -p icmp --state INVALID -j DROP
iptables -A OUTPUT -p ALL -o lo -j ACCEPT
iptables -A OUTPUT -p ALL -o eth0 -j ACCEPT
iptables -A OUTPUT -p ALL -o eth1 -j ACCEPT
iptables -A OUTPUT -p ALL -o eth2 -j ACCEPT
iptables -A OUTPUT -p ALL -o ppp0 -j ACCEPT

# Routing
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

# Standardverhalten
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD ACCEPT

Als nächstes kann man nun eine DSL-Verbindung aufbauen:

pppd call dsl-provider

Bei einem Neustart des System oder durch das Neustarten des Linux Networkings “/etc/init.d/networking restart” passiert dies automatisch.

Nun sollte eine ppp0 Verbindung hergestellt worden sein (“ifconfig”) und die Routerkonfiguration ist damit abgeschlossen.

Die Hardware besteht aus einem Jetway 1,2 GHz passiv gekühlten Epia Mainboard, 2 SATA 160GB Festplatten, 1GB Arbeitsspeicher sowie einer 3x Gigabit Extension von Jetway.

Die Festplatten sind in einem Linux Softwareraid konfiguriert.

Außerdem kommt eine ISDN Karte zum Einsatz um als Fax-Funktionen zu ermöglichen, sowie um eine alternative Einwahlmöglichkeit bereitzustellen.

Das ganze wurde in einem 2HE Gehäuse von visual-data verpackt.

Auf die Konfiguration der einzelnen Softwareteile werde ich in folgenden Artikeln näher eingehen.

[Show as slideshow]