# vim ~/.fluxbox/init
Den Wert unter session.screen0.edgeSnapThreshold: von 0 auf etwa 10 anpassen.
Freitag, 26. Dezember 2008
"Klebende Raender" in Fluxbox
Den Wert unter session.screen0.edgeSnapThreshold: von 0 auf etwa 10 anpassen.
Tomcat 6 mit Apache Connector und ohne VirtualHosts auf Lenny
1. Java einrichten
1.1 Installation:
Zuerst installieren wir das Sun JDK aus den non-free Quellen. Alternativ kann auch OpenJDK verwendet werden, dann muss man aber bei den Pfadangaben in den Configs aufpassen (Paket: java6-runtime).
Dieses Howto beschreibt die Installation mit dem Sun JDK:
# aptitude install sun-java6-jdk
Die Java Version noch ueber
# update-alternatives --config javaauswaehlen.
1.2 Umgebungsvariablen:
# vim /etc/profile
Am Anfang der Datei folgendes hinzufuegen (bei OpenJDK entsprechend abaendern):
JAVA_HOME="/usr/lib/jvm/java-6-sun"
Am Ende der Datei bei "export" muss nun folgendes stehen:
export PATH JAVA_HOME PS1
2. Tomcat einrichten
2.1 Installation
Tomcat 6 von der Homepage herunterladen.
# wget http://apache.eu.lucid.dk/tomcat/tomcat-6/v6.0.18/bin/apache-tomcat-6.0.18.tar.gz
entpacken, und nach /usr/local/ kopieren:
# tar -xzvf apache-tomcat-6.0.18.tar.gz
# mv apache-tomcat-6.0.18 /usr/local
Einen Symlink nach /usr/local/tomcat erstellen
# ln -s /usr/local/apache-tomcat-6.0.18 /usr/local/tomcat
2.2 Initskripte
Die Datei /etc/init.d/tomcat mit folgendem Inhalt fuellen und ausfuehrbar machen:
#!/bin/sh
case $1 in
start)
sh /usr/local/tomcat/bin/startup.sh
;;
stop)
sh /usr/local/tomcat/bin/shutdown.sh
;;
restart)
sh /usr/local/tomcat/bin/shutdown.sh
sh /usr/local/tomcat/bin/startup.sh
;;
esac
exit 0
# chmod +x /etc/init.d/tomcat
# update-rc.d tomcat defaults
3. TomCat Manager
3.1 User anlegen
# vim /usr/local/tomcat/conf/tomcat-users.xml
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="manager"/>
<role rolename="admin"/>
<user username="admin" password="gas" roles="admin,manager"/>
</tomcat-users>
3.2 Testen
# /etc/init.d/tomcat start
Nun sollte man mit ueber http://ip:8080/manager/html auf den Tomcat Manager zugreifen koennen.
4. Apache einrichten
# aptitude install apache2 libapache2-mod-jk
Die Datei /etc/apache2/workers.properties mit folgendem Inhalt erstellen:
workers.tomcat_home=/usr/local/tomcat
workers.java_home=/usr/lib/jvm/java-6-sun
ps=/
worker.list=default
worker.default.port=8009
worker.default.host=localhost
worker.default.type=ajp13
worker.default.lbfactor=1
und die eine Datei /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/tomcat restart
# /etc/init.d/apache2 start
5. Sonstiges
5.1 Apache-Einstellungen
Die Datei /etc/apache2/sites-available/default im <VirtualHost *:80> Block um folgende Zeile ergaenzen:
JkMount /*.jsp defaultDadurch werden alle *.jsp Files an den Tomcat uebergeben.
Man kann das auch auf Unterordner einschraenken - wie man will (Bsp: /bla/*.jsp)
# /etc/init.d/apache2 reload
5.2 Tomcat-Einstellungen
Die Datei /usr/local/tomcat/conf/server.xml ganz unten, jedoch noch im Host-Tag um folgende Zeilen ergaenzen:
<host name="servername" appBase="/var/www/" unpackWARs="true" autoDeploy="true">
<context path="" docBase="." debug="0" reloadable="true"/>
<valve className="org.apache.catalina.valves.AccessLogValve"
directory="/var/www/logs" prefix="tomcat_access_" suffix=".log"
pattern="common" resolveHosts="false"/>
</host>
Tomcat neustarten
/etc/init.d/tomcat restart
5.3 Sonstiges
Will man, dass man beim Aufrufen eines Ordners direkt die index.jsp (wie bei index.html, index.php) gezeigt bekommt muss man die /etc/apache2/httpd.conf wie folgt erweitern:
<IfModule dir_module>
DirectoryIndex index.html index.php index.jsp
</IfModule>
6. Hello World
6.1 Skript
# vim /var/www/helloworld.jsp
<head>
<title>Hello World JSP</title>
</head>
<body>
<h1>
<%
out.println("Hello World");
%>
</h1>
</body>
</html>
6.2 Skript mit Tomcat Manager deployen
Im TomCat Manager unter "Deploy":
Context Path (optional): /xyz
WAR or Directory URL: /var/www/
Anschliessend den Deploy-Button druecken
Die Hello World Seite sollte nun unter http://ip/xyz/helloworld.jsp zu sehen sein.
Statt xyz kann man natuerlich auch nur / angeben, dann lautet die Adresse halt http://ip/helloworld.jsp
Dienstag, 23. Dezember 2008
Timeserver mit NTP
NTP (Network-Time-Protocol) basiert auf dem Client/Server-Prinzip. Ein oder mehrere Server bieten im Netzwerk die Uhrzeit an, und beliebig viele Clients synchronisieren sich damit. komm laber.
Server einrichten:
Die Konfigurationsfile /etc/ntp.conf:
Clients:
Configfile /etc/ntp.conf:
Gebamte Timeserver kann man hiermit angucken:
Server einrichten:
apt-get install ntp ntpdate
Die Konfigurationsfile /etc/ntp.conf:
driftfile /var/lib/ntp/ntp.drift
# Timeserver der physikalisch-Technischen Bundesanstalt
server ptbtime1.ptb.de
server ptbtime2.ptb.de
restrict ptbtime1.ptb.de
restrict ptbtime2.ptb.de
restrict 127.0.0.1
restrict 10.2.2.0 mask 255.255.255.0
restrict default notrust nomodify nopeer
/etc/init.d/ntp start
Clients:
apt-get install ntp ntp-simple ntpdate
Configfile /etc/ntp.conf:
driftfile /var/lib/ntp/ntp.drift
server 10.2.2.1
restrict 10.2.2.1
restrict 127.0.0.1
restrict default notrust nomodify nopeer
/etc/init.d/ntp restart
Gebamte Timeserver kann man hiermit angucken:
ntpq -p
ntpdc -p
Sonntag, 21. Dezember 2008
OpenVPN Server mit Firehol
Es gibt zwei Moeglichkeiten eine VPN Verbindung herzustellen. Einmal uber eine Bridge und einmal ueber Routing. Eine Bridge ist sinnvoll, wenn der Client und das LAN auf der Serverseite im gleichen Subnetz sind, sodass man nur eine Verbindung zwischen den beiden Netzen herstellt.
Beim Routing wird jeder Gegenstelle eine virtuelle IPAdresse eines beliebigen subnetzes zugewiesen. Eine Verbindung zum dahinterliegenenden LAN ist grundsaetzlich erstmal nicht moeglich. Es besteht ausschliesslich eine Verbindung von Client zu Server. Der Rest wird ueber Routingtabellen festgelegt.
Hier geht es aber nur ueber OpenVPN mittels Routing.
Damit OpenVPN funktioniert muss das Kernelmodul "tun" geladen sein. GGf mit
Bei virtuellen Systemen tritt oft der Fehler auf, dass das Tunnelinterface nicht korrekt erstellt wird. Deshalb ggf. folgendes ausfuehren:
1. Methode: PreShared Keys
nicht so sicher; einfachste Variante; fuer jeden Teilnehmer wird ein Key erstellt, mit dem der Tunnel verschluesselt wird. Server und Client muss der Key bekannt sein. Bei mehreren Usern, fuer jeden User einen eigenen Key. Bekommt jemand anderes den key, kann der Datenverkehr entschluesselt werden.
Den Key auch auf den Client kopieren (am besten home-Verzeichnis)
Fuer jeden Client muss eine eigene Configfile angelegt werden. Ein Client benoetigt einen eigenen Port!
Konfiguration:
Auf dem Server:
Auf dem Client:
VPN Verbindung herstellen:
Bevor man eine Verbindung herstellen kann, muss sichergestellt sein, dass der Port in der Firewall offen ist. Bei Firehol muss die /etc/firehol/firehol.conf folgendermassen ergaenzt werden:
auf dem Server:
Es wird fuer jede .conf file im /etc/openvpn/ Ordner ein VPN Server gestartet.
Auf dem Client:
Spaeter lieber mit network-manager oder aehnliches.
Nun muessten sich Server und Client gegenseitig pingen koennen 10.0.0.1 <-> 10.0.0.2
Damit der Client jetzt auch auf das LAN vom Server zugreifen kann, muss Routing eingefuhert werden:
Auf derm Server in der /etc/firehol/firehol.conf:
Soll der Client auch ins Internet duerfen (sinnvoll wenn man irgendwo is,es sind viele nette Seiten geblockt, VPN geht aber, dann kann man ueber das Internet des Servers auf die Seiten ;) o.a.)
Auf Clientseite wird das Routing ueber die openvpn config geregelt:
Fuer das LAN auf der anderen Seite:
/etc/openvpn/servername.conf
Fuer Internet muss zusaetzlich folgendes Routing erstellt werden:
/etc/openvpn/servername.conf
Der Client geht nun ueber die Internet Verbindung des Servers.
Unter Windows: Route hinzufügen in der Konsole
2. Methode: Authentifizerung mit Zertifikaten
Prinzip:
Ein Client startet eine Verbindung zum OpenVPN Server. Der Server uebermittelt sein X.509 Zertifikat, was vom Client auf echtheit ueberprueft wird. Ueberpruefung anhand des public keys.War das erfolgreich authentifiziert sich der Client mit seinem X.509 Zertifikat. jetzt prueft der Server auch ahnhang des public keys der CA ob dieser guelitg ist. Zusaetzlich wird ueberprueft ob der Client in der CRL ist oder nicht. In der CRL (Certificate Revokation List) befinden sich alle zurueckgezogenen Zertifikate. Ist das Clientzertifikat also enthalten (client wurde gesperrt), kann keine Verbindung hergestellt werden. Ist der Client nicht enthalten werden mit ssl/tls keys ausgehandelt um die verbindung zu verschluesseln.
Hat man schon eine eigene RootCA kann man diese einfach verwenden. Man muss lediglich ein Zertifikat fuer den Server und eins fuer den Client erstellen. Dann unten bei Konfiguration fortfahren. sonst bam:
Grobe Einstellungen kann man in der /etc/ssl/openssl.cnf vornhemen:
wenn man will kann man ein paar sachen bzgl Struktur/Name der CA im Block [CA_default] vornehmen, muss aber nicht sein.
Die Anzahl der Bits fuer ein Zertifikat sollte man von 1024 auf 2048 stellen (paranoide nerds 4096, aber achtung. das dauert spaeter noch ewig. also lieber 2048 ;-).
Dh. also im Block [ req ] den Wert von default_bits auf 2048 setzen.
Die CA kann man selbst erstellen, muss aber nciht sein, weil es schon ein Skript gibt was das macht. das liegt in /usr/lib/ssl/misc/CA.sh
dort gegebenfalls den Wert von CATOP=./demoCA auf den gleichen Wert aendern, der in der openssl.cnf im Block [CA_default] angegeben wurde.
Nun kann man eine neue CA mit
Das Passwort was man dort eingibt is immer wieder wichtig, um Zertifikate zu erstellen, zu revoken etc...
Falls gewuenscht, eine CRL (Certificate Revokation List) erstellen:
Achtung: name muss so heissen wie in der openssl.cnf, sonst funzt spaeter garnix. Standardmaessig ist das crl.pem.
Es kann sein, dass ein Fehler bzgl einer CRLNumber kommt.. Dann einfach im Ordner der CA eine Datei "crlnumber" erstellen, welche "00" gefolgt von einer Leerzeile als Inhalt hat.
Diffie Hellman parameter erstellen (wird benoetigt damit Server und Client einen gemeinsamen schluessel erzeugen koennen):
Server Zertifikat erstellen:
Sign request:
Zertifikat signieren:
Ich habe mir im Order der CA einen unterordner "csr" gemacht wo alle Sign requests rein kommen.
Die keys die hier mit keyout erzeugt werden gehoeren in den private-Ordner und die Zertifkate gehoeren in newcerts. Ist nicht notewendig, aber Ordnung muss sein.
Client Zertifikat analog erzeugen.
Es ist darauf zu achten das bei der Zertifikatserstellung bei CommonName immer etwas anderes steht. Am besten Server oder Benutzer/Client-Name, da sonst spaeter garnix geht.
Konfigurationsfiles fuer OpenVPN:
wie bei Methode 1 eine config in /etc/openvpn/ anlegen und wie folgt fuellen:
Client konfigurieren:
Im "debug" Mode am besten auf erst auf Server dann auf Client
Durch "verb 3" in den configs sieht man ob alles mit den Zertifikaten geklappt hat.
War das alles erfolgreich, kann man openvpn auf dem Server als deamon starten
Auf dem Client ginge es genauso, nur is das evlt unguenstig, wenn der Client bei jedem Booten sofort automatisch die VPN Verbindung herstellt. Deshalb entweder die config aus dem /etc/openvpn ordner rausholen oder den openvpn dienst beim systemstart dekativieren und manuell starten.
Zertifikat revoken:
Moechte man, dass ein User/Client keinen Zugriff mehr auf den Server erhalten hat, muss man lediglich sein Zertifikat zurueckziehen.
Ein zurueckgenommenes Zertifikat kann nie wieder benutzt werden, auch nicht durch neu signieren oder aehnliches... Will man einem User also wieder Zugriff geben, muss ein komplett neues Zertifikat erzeugt werden.
Damit der OpenVPN Server auch ueberprueft, ob ein Zertifikat zurueckgezogen wurde oder nicht, ist folgende Zeile in der openvpn config File des Servers unbedingt notwendig:
"Tuning":
Datenkompression
Um den Datendurchfluss zu erhoehen, kann man LZO-Kompression aktivieren.(ist ressourcenschonend, trotzdem nicht bei uralt kisten)
Dazu einfach in den Configs folgendes ergaenzen:
Damit das funktioniert, muss OpenVPN mit LZO-Kompression kompiliert worden sein (ist bei etch schon der fall).
DoS Attacken vermeiden
Nur eine zusaetzliche Authentifizierung. Keine extra Verschluesselung; es werden nur die tlspakete signiert. damit kann der Server vor dem Handshake einen nicht berechtigten client erkennen und die verbindung trennen.
dieser Key muss auf Client und Server vorhanden sein, und durch folgenden Eintrag in der config aktiviert werden:
Sessionkeys regelmaessig erneuern
Sessionkeys für die Verschlüsselung werden halbstuendlich erneuern. nicht zu oft sonst verbindungsabbruch.
Zusaetzliche AUthentifizierung durch Username/passwort
Es gibt noch viele moeglichkeiten einer zusaetzlichen Authentifizierung. Authentifizierung gegen ActiveDirector, LDAPVerzeichnis uvm. OpenVPN kann davon ueberhaupt nichts. Es kann nur Skripte starten mit folgendem Eintrag in der server-config:
gibt das skript den exit-code 0 zurueck, so war die authentifizierung erfolgreich, ansonsten nicht.
Wie das Script aussieht, bleibt jedem selbst ueberlassen.
Die einfachste Variante waere sowas:
Beim Routing wird jeder Gegenstelle eine virtuelle IPAdresse eines beliebigen subnetzes zugewiesen. Eine Verbindung zum dahinterliegenenden LAN ist grundsaetzlich erstmal nicht moeglich. Es besteht ausschliesslich eine Verbindung von Client zu Server. Der Rest wird ueber Routingtabellen festgelegt.
Hier geht es aber nur ueber OpenVPN mittels Routing.
# aptitude install openvpn
Damit OpenVPN funktioniert muss das Kernelmodul "tun" geladen sein. GGf mit
# modprobe tunnachladen bzw in die /etc/modules eintragen.
Bei virtuellen Systemen tritt oft der Fehler auf, dass das Tunnelinterface nicht korrekt erstellt wird. Deshalb ggf. folgendes ausfuehren:
# sudo mkdir -p /dev/net
# sudo mknod /dev/net/tun c 10 200
# sudo chmod 600 /dev/net/tun
1. Methode: PreShared Keys
nicht so sicher; einfachste Variante; fuer jeden Teilnehmer wird ein Key erstellt, mit dem der Tunnel verschluesselt wird. Server und Client muss der Key bekannt sein. Bei mehreren Usern, fuer jeden User einen eigenen Key. Bekommt jemand anderes den key, kann der Datenverkehr entschluesselt werden.
# cd /etc/openvpn
Key erstellen:
# openvpn --genkey --secret name.key
# chmod go-rwx name.key
Den Key auch auf den Client kopieren (am besten home-Verzeichnis)
Fuer jeden Client muss eine eigene Configfile angelegt werden. Ein Client benoetigt einen eigenen Port!
Konfiguration:
Auf dem Server:
# vim /etc/openvpn/name.conf
dev tun
ifconfig 10.0.0.1 10.0.0.2
secret ./name.key
port 1194
proto udp
Auf dem Client:
# vim /etc/openvpn/servername.conf
remote servername.domain.de
dev tun
ifconfig 10.0.0.2 10.0.0.1
secret /home/username/name.key
port 1194
proto udp
VPN Verbindung herstellen:
Bevor man eine Verbindung herstellen kann, muss sichergestellt sein, dass der Port in der Firewall offen ist. Bei Firehol muss die /etc/firehol/firehol.conf folgendermassen ergaenzt werden:
interface eth0 internet
...
server custom openvpn "tcp/1194 udp/1194" default accept
auf dem Server:
# /etc/init.d/openvpn restart
Es wird fuer jede .conf file im /etc/openvpn/ Ordner ein VPN Server gestartet.
Auf dem Client:
# openvpn --config /etc/openvpn/servername.conf
Spaeter lieber mit network-manager oder aehnliches.
Nun muessten sich Server und Client gegenseitig pingen koennen 10.0.0.1 <-> 10.0.0.2
Damit der Client jetzt auch auf das LAN vom Server zugreifen kann, muss Routing eingefuhert werden:
Auf derm Server in der /etc/firehol/firehol.conf:
Fuer LAN (vorausgesetzt tun0 ist das Tunnelinterface und eth1 das Interface zum LAN)
router vpn2lan inface tun0 outface eth1
# client all accept
# server all accept
masquerade
route all accept
Soll der Client auch ins Internet duerfen (sinnvoll wenn man irgendwo is,es sind viele nette Seiten geblockt, VPN geht aber, dann kann man ueber das Internet des Servers auf die Seiten ;) o.a.)
router vpn2internet inface tun0 outface eth0
# Wenn nicht alles erlaubt sein soll, dann ggf. wie gewohnt erlauben/blocken
masquerade
route all accept
Auf Clientseite wird das Routing ueber die openvpn config geregelt:
Fuer das LAN auf der anderen Seite:
/etc/openvpn/servername.conf
# neues gateway
route-gateway 10.0.0.1
# Netz und Maske des entfernten LANs
route 192.168.0.0 255.255.255.0
Fuer Internet muss zusaetzlich folgendes Routing erstellt werden:
/etc/openvpn/servername.conf
# bisheriges Standardgateway erstetzen
redirect-gateway
# Saemtliche Adressen ueber den VPN Server routen
route 0.0.0.0 0.0.0.0
Der Client geht nun ueber die Internet Verbindung des Servers.
Unter Windows: Route hinzufügen in der Konsole
route add 192.168.99.0 mask 255.255.255.0 10.0.0.1 metric 1 -p
2. Methode: Authentifizerung mit Zertifikaten
Prinzip:
Ein Client startet eine Verbindung zum OpenVPN Server. Der Server uebermittelt sein X.509 Zertifikat, was vom Client auf echtheit ueberprueft wird. Ueberpruefung anhand des public keys.War das erfolgreich authentifiziert sich der Client mit seinem X.509 Zertifikat. jetzt prueft der Server auch ahnhang des public keys der CA ob dieser guelitg ist. Zusaetzlich wird ueberprueft ob der Client in der CRL ist oder nicht. In der CRL (Certificate Revokation List) befinden sich alle zurueckgezogenen Zertifikate. Ist das Clientzertifikat also enthalten (client wurde gesperrt), kann keine Verbindung hergestellt werden. Ist der Client nicht enthalten werden mit ssl/tls keys ausgehandelt um die verbindung zu verschluesseln.
Hat man schon eine eigene RootCA kann man diese einfach verwenden. Man muss lediglich ein Zertifikat fuer den Server und eins fuer den Client erstellen. Dann unten bei Konfiguration fortfahren. sonst bam:
aptitude install openssl
Grobe Einstellungen kann man in der /etc/ssl/openssl.cnf vornhemen:
wenn man will kann man ein paar sachen bzgl Struktur/Name der CA im Block [CA_default] vornehmen, muss aber nicht sein.
Die Anzahl der Bits fuer ein Zertifikat sollte man von 1024 auf 2048 stellen (paranoide nerds 4096, aber achtung. das dauert spaeter noch ewig. also lieber 2048 ;-).
Dh. also im Block [ req ] den Wert von default_bits auf 2048 setzen.
Die CA kann man selbst erstellen, muss aber nciht sein, weil es schon ein Skript gibt was das macht. das liegt in /usr/lib/ssl/misc/CA.sh
dort gegebenfalls den Wert von CATOP=./demoCA auf den gleichen Wert aendern, der in der openssl.cnf im Block [CA_default] angegeben wurde.
Nun kann man eine neue CA mit
# cd /etc/ssl/erstellen.
# /usr/lib/ssl/misc/CA.sh -newca
Das Passwort was man dort eingibt is immer wieder wichtig, um Zertifikate zu erstellen, zu revoken etc...
Falls gewuenscht, eine CRL (Certificate Revokation List) erstellen:
openssl ca -gencrl -out name
Achtung: name muss so heissen wie in der openssl.cnf, sonst funzt spaeter garnix. Standardmaessig ist das crl.pem.
Es kann sein, dass ein Fehler bzgl einer CRLNumber kommt.. Dann einfach im Ordner der CA eine Datei "crlnumber" erstellen, welche "00" gefolgt von einer Leerzeile als Inhalt hat.
Diffie Hellman parameter erstellen (wird benoetigt damit Server und Client einen gemeinsamen schluessel erzeugen koennen):
openssl dhparam -out dh2048.pem 2048(Das dauert ewig)
Server Zertifikat erstellen:
Sign request:
openssl req -nodes -new -keyout servername.key -out servername.csr
Zertifikat signieren:
openssl ca -out servername.crt -in servername.csr
Ich habe mir im Order der CA einen unterordner "csr" gemacht wo alle Sign requests rein kommen.
Die keys die hier mit keyout erzeugt werden gehoeren in den private-Ordner und die Zertifkate gehoeren in newcerts. Ist nicht notewendig, aber Ordnung muss sein.
Client Zertifikat analog erzeugen.
Es ist darauf zu achten das bei der Zertifikatserstellung bei CommonName immer etwas anderes steht. Am besten Server oder Benutzer/Client-Name, da sonst spaeter garnix geht.
Konfigurationsfiles fuer OpenVPN:
wie bei Methode 1 eine config in /etc/openvpn/ anlegen und wie folgt fuellen:
dev tun
ifconfig 10.0.0.1 10.0.0.2
tls-server
dh /etc/ssl/FBCA/dh2048.pem
ca /etc/ssl/FBCA/cacert.pem
cert /etc/ssl/FBCA/newcerts/fblxfw0.pem
key /etc/ssl/FBCA/private/fblxfw0.key
crl-verify /etc/ssl/FBCA/crl.pem
port 1194
proto udp
verb 3
Client konfigurieren:
remote servername.bla.de
dev tun
ifconfig 10.0.0.2 10.0.0.1
tls-client
ca /home/username/cacert.pem
cert /home/username/username.pem
key /home/username/username.key
port 1194
proto udp
verb 3
// Routing wie bei Methode 1. je nach dem was man will.
Im "debug" Mode am besten auf erst auf Server dann auf Client
openvpn --config pfadzurconfigstarten.
Durch "verb 3" in den configs sieht man ob alles mit den Zertifikaten geklappt hat.
War das alles erfolgreich, kann man openvpn auf dem Server als deamon starten
/etc/init.d/openvpn start.
Auf dem Client ginge es genauso, nur is das evlt unguenstig, wenn der Client bei jedem Booten sofort automatisch die VPN Verbindung herstellt. Deshalb entweder die config aus dem /etc/openvpn ordner rausholen oder den openvpn dienst beim systemstart dekativieren und manuell starten.
Zertifikat revoken:
Moechte man, dass ein User/Client keinen Zugriff mehr auf den Server erhalten hat, muss man lediglich sein Zertifikat zurueckziehen.
openssl ca -revoke /etc/ssl/CABLA/newcerts/certifikateTorevoke.pem
Ein zurueckgenommenes Zertifikat kann nie wieder benutzt werden, auch nicht durch neu signieren oder aehnliches... Will man einem User also wieder Zugriff geben, muss ein komplett neues Zertifikat erzeugt werden.
Damit der OpenVPN Server auch ueberprueft, ob ein Zertifikat zurueckgezogen wurde oder nicht, ist folgende Zeile in der openvpn config File des Servers unbedingt notwendig:
crl-verify /etc/ssl/FBCA/crl.pem
"Tuning":
Datenkompression
Um den Datendurchfluss zu erhoehen, kann man LZO-Kompression aktivieren.(ist ressourcenschonend, trotzdem nicht bei uralt kisten)
Dazu einfach in den Configs folgendes ergaenzen:
comp-lzo
Damit das funktioniert, muss OpenVPN mit LZO-Kompression kompiliert worden sein (ist bei etch schon der fall).
DoS Attacken vermeiden
Nur eine zusaetzliche Authentifizierung. Keine extra Verschluesselung; es werden nur die tlspakete signiert. damit kann der Server vor dem Handshake einen nicht berechtigten client erkennen und die verbindung trennen.
openvpn --genkey --secret tlsauth.key
dieser Key muss auf Client und Server vorhanden sein, und durch folgenden Eintrag in der config aktiviert werden:
tls-auth tlsauth.key
Sessionkeys regelmaessig erneuern
reneg-sec 1800
Sessionkeys für die Verschlüsselung werden halbstuendlich erneuern. nicht zu oft sonst verbindungsabbruch.
Zusaetzliche AUthentifizierung durch Username/passwort
Es gibt noch viele moeglichkeiten einer zusaetzlichen Authentifizierung. Authentifizierung gegen ActiveDirector, LDAPVerzeichnis uvm. OpenVPN kann davon ueberhaupt nichts. Es kann nur Skripte starten mit folgendem Eintrag in der server-config:
auth-user-pass-verify skript.sh via-env
gibt das skript den exit-code 0 zurueck, so war die authentifizierung erfolgreich, ansonsten nicht.
Wie das Script aussieht, bleibt jedem selbst ueberlassen.
Die einfachste Variante waere sowas:
#!/bin/sh
USER="bam"
PASSWD="gas"
if [ "$username" == "$USER" ] && [ "$password" == "$PASSWD" ]
then exit 0
fi
exit 1
DNS Server
# aptitude install bind9
alle Anfragen die der DNS Server nicht auswerten kann, muessen an einen anderen DNS Server weitergeleitet werden. dazu folgendes in die /etc/bind/named.conf.options:
forwarders {
IP1;
IP2; ...
};// das mit den zonen kommt spaeter ;)
DHCP Server
# aptitude install dhcp3-server
unter /etc/default/dhcp3-server einstellen, auf welchen interfaces der DHCP-Server arbeiten soll.
das wichtigste fuer die /etc/dhcp3/dhcpd.conf:
ddns-update-style none;
option domain-name-servers 192.168.0.1;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.3 192.168.0.100;
option routers 192.168.0.1;
}
damit eine bestimmte MAC-Adresse immer die selbe IP bekommt um folgendes ergaenzen:
host server1 {
hardware ethernet 00:11:22:33:44:5;
fixed-address 192.168.0.2;
}
Sonntag, 14. Dezember 2008
Window tiling mit whaw
aptitude install libpopt-dev libxmu-dev libxinerama-dev
wget http://repetae.net/computer/whaw/drop/whaw-0.1.2.tar.gz
tar -xzf whaw-0.1.2.tar.gz
cd whaw-0.1.2
./configure
make
make install
whaw &
Cursor in die obere linke ecke
cursor nach rechts bewegen am oberen bildschirmrand
nun alle fenster anklicken die man tilen möchte
dann linke maus rechteck ziehen in dem die fenster sein sollen
Montag, 8. Dezember 2008
Freitag, 5. Dezember 2008
TrueType font in xterm
Download Courir New
Neu einlsen ...
list
~/.Xdefaults
Mit jedem X start ausführen:
/usr/share/fonts/truetype/
~/.fonts/
Neu einlsen ...
fc-cache -fv
list
fc-list | col | sort | less
~/.Xdefaults
XTerm*background: Black
XTerm*foreground: White
XTerm*locale: true
XTerm*utf8: 1
XTerm*faceName: Courier New
XTerm*faceSize: 7
Mit jedem X start ausführen:
xrdb ~/.Xdefaults
Mittwoch, 3. Dezember 2008
Volume mit amixer und xosd
aptitude install xosd-bin
Folgendes Script benutzen mit:
script_name.sh toggle
script_name.sh up
script_name.sh down
#!/bin/bash
ACTION="$1"
MIXER="Master"
VALUE="1"
FONT="-adobe-helvetica-bold-*-*-*-34-*-*-*-*-*-*-*"
[ -z "${ACTION}" ] && echo "Usage: $0 [up|down|toggle]"
if [ "${ACTION}" == "up" ]; then
amixer sset ${MIXER} ${VALUE}+ unmute
elif [ "${ACTION}" == "down" ]; then
amixer sset ${MIXER} ${VALUE}- unmute
elif [ "${ACTION}" == "toggle" ]; then
amixer -q set ${MIXER} toggle
fi
killall osd_cat > /dev/null 2>&1
if [ "$(amixer sget $MIXER,0 | grep "off")" == "" ]; then
PERCENT=$(amixer sget $MIXER,0 | grep "Front Left:" | cut -d "[" -f2 | cut -d "%" -f1)
osd_cat -p bottom -A center -o 30 -b percentage -P ${PERCENT} -d 1
else
echo "MUTE" | osd_cat -f ${FONT} -p bottom -A center -o -120 -d 1
fi
Abonnieren
Posts (Atom)