IT-Blog von Sebastian van de Meer

Schlagwort: Linux (Seite 8 von 8)

IVTV

Veraltet: Die Hauppauge PVR-250/350 und der ivtv-Treiber sind seit vielen Jahren obsolet. Aktuelle TV-Karten werden über V4L2 angesprochen.

Wer mit der PVR 350 von Hauppauge einfach nur TV schauen möchte, ohne Mythtv und ohne vdr der wird etwas länger nach einer passenden Anleitung im Internet suchen. Besonders wenn er einen Satelitenresiever oder ähnliches an seinen Composite-Anschluss seiner PVR350 anschliessen will. Folgene Einstellungen sollten im Kernel gemacht werden: Linux kernel configuration for ivtv video driver Kernel module options for Hauppauge PVR card ivtv driver successfully loaded in kernel log Ich nutze hier bei mir Gentoo und den Kernel: Linux PC-02 2.6.16-gentoo-r12 #3 PREEMPT Mon Jul 10 23:54:18 CEST 2006 i686 Pentium III (Coppermine) GNU/Linux Zuerst einmal sollte unter /etc/modules.d/ eine Datei mit dem Namen ivtv angelegt werden, sofern nicht schon vorhanden:
touch /etc/modules.d/ivtv
Der Inhalt dieser Datei sollte nun so abgeänder werden:
alias char-major-81 videodev
alias char-major-81-0 ivtv
alias char-major-61 lirc_i2c
options msp3400 once=1
add below ivtv msp3400 saa7115 saa7127 tuner
add above ivtv ivtv-fb
add above ivtv lirc_dev lirc_i2c
Das ist jetzt auch der Inhalt meiner ivtv-Datei. Diese ist mit den lirc Optionen auch schon ausgelegt auf den Einsatz zusammen mit Mythtv. Es kann aber alles so übernommen werden. Selbst wenn wir am Ende einfach nur TV schauen wollen. Jetzt sollte der Treiber installiert werden, welcher es ermöglicht den Hauppauge PVR 350 hardware MPEG-2 chip zu „aktivieren“. Das Treiberpaket nennt sich ivtv. Die offizielle Homepage zu diesem Projekt ist: http://www.ivtvdriver.org/! Mit der Version 0.4.0-r3 unter Gentoo hatte ich einige Pobleme mit einem Kernel ab Version 2.6.15 aus diesem Grund habe ich zu einer maskierten Version gegriffen. Zu dem ist f�r den Kernel ab Version 2.6.x ja auch die ivtv Version 0.6.x zuständig! Ich nutze jetzt die Version 0.6.3. Um diese unter Gentoo zu „demaskieren“ hilft folgendes:
echo "media-tv/ivtv ~x86" >> /etc/portage/package.keywords
Nun kann auch schon mit der Installation des Paketes begonnen werden:
emerge -a ivtv
Ist die installation sauber abgeschlossen kann man sein Modul auch schon laden:
modprobe ivtv
Nun sollte man am besten kurz nachschauen ob das mit dem Laden geklappt hat:
dmesg |grep ivtv
Es sollte sich in etwas so etwas in die Konsole erbrechen:
ivtv: ==================== START INIT IVTV ====================
ivtv: version 0.6.3 (tagged release) loading
ivtv: Linux version: 2.6.16-gentoo-r12 preempt PENTIUMIII REGPARM gcc-4.1
ivtv: In case of problems please include the debug info between
ivtv: the START INIT IVTV and END INIT IVTV lines, along with
ivtv: any module options, when mailing the ivtv-users mailinglist.
ivtv0: Autodetected Hauppauge WinTV PVR-350 card (cx23415 based)
tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
tda9887 1-0043: chip found @ 0x86 (ivtv i2c driver #0)
saa7115 1-0021: saa7115 found @ 0x42 (ivtv i2c driver #0)
saa7127 1-0044: saa7129 found @ 0x88 (ivtv i2c driver #0)
msp3400 1-0040: MSP4418G-B3 found @ 0x80 (ivtv i2c driver #0)
ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
ivtv0: loaded v4l-cx2341x-dec.fw firmware (262144 bytes)
ivtv0: Encoder revision: 0x02050032
ivtv0: Decoder revision: 0x02020023
ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
ivtv0: Allocate DMA encoder YUV stream: 161 x 12960 buffers (2048KB total)
ivtv0: Allocate DMA encoder VBI stream: 80 x 26208 buffers (2048KB total)
ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
ivtv0: Create encoder radio stream
ivtv0: Allocate DMA decoder MPEG stream: 16 x 65536 buffers (1024KB total)
ivtv0: Allocate DMA decoder VBI stream: 512 x 2048 buffers (1024KB total)
ivtv0: Create decoder VOUT stream
ivtv0: Allocate DMA decoder YUV stream: 20 x 51840 buffers (1024KB total)
ivtv0: loaded v4l-cx2341x-init.mpg firmware (155648 bytes)
ivtv0: Initialized Hauppauge WinTV PVR-350, card #0
ivtv: ==================== END INIT IVTV ====================
Jetzt kann man schon das erste mal probieren ob man Fernsehen schauen kann. Man braucht nur einen Videoplayer der einen mpeg2 Stream abschpielen kann. Ich nutze dazu fast immer mplayer oder kmplayer. Ein: mplayer /dev/video0 sollte nun Schnee in den Player zaubern. Nun ist es Zeit seinen Satelitenresiever (oder was auch immer) am Composite-Eingang seiner PVR350 in Gang zu setzen. Folglich müssen wir unserer Karte nur noch sagen das wir einen anderen Eingang für unser Videosignal nutzen wollen! ivtvctl -P zeigt uns den gerade genutzten Videoeingang. ivtvctl -n zeigt uns alle möglichen Video Ein- und Ausgänge. Um ihn zu ändern brauchen wir ivtvctl -p der Composite-Eingang sollte auf 5 oder 6 liegen, also:
ivtvctl -p 5
Na? ist das nicht was? Bild und Ton sollte nun den Schnee aus unserem mplayer vertrieben haben. Natürlich kann man nun auch mit der Karte ein Video aufnehmen! Einfach mal ein:
cat /dev/video0 > /ORDNERmitPASSENDENrechten/video.mpg
In die Konsole hämmern und schon wird aufgebommen. Ist man fertig mit seiner Aufnahmen kann man alles einfach mit STRG + C abbrechen. Die Datei /ORDNERmitPASSENDENrechten/video.mpg ist nun schon ein komplettes mpg Video und man kann damit machen was man will! Natürlich kann man auch wärend der Aufnahme einfach mal schauen ob alle glatt geht und mit dem mplayer live testen:
mplayer /ORDNERmitPASSENDENrechten/video.mpg
Die Aufnahme kann dabei natürlich weiter laufen. So lässt sich dann auch die „Pause-Funtion“ nutzen, wenn auch etwas umständlich! Wer Videorekorder, Teletext, TV-Zeitschrift, Pausefunktion, Netzwerkstreamen usw. usw.usw. haben will sollte sich nun doch vielleicht einmal überlegen MythTV oder VDR zu testen. tvtime xawtv und auch kdetv haben wohl zum Teil Plugins für die PVR350, diese kommen aber auch nicht ohne die ivtv-Treiber aus und mir ist noch keines unter die Nase gekommen, welches wirklich sauber Funktioniert hat.

Linux-Firewall mit iptables und Traffic Shaping: Aufbau und Konzepte

Hinweis: Dieses Script stammt aus 2009 und nutzt iptables auf einem Debian mit Kernel 2.4. Die Konzepte sind zeitlos, aber die Umsetzung ist veraltet. Heute nimmt man nftables statt iptables. Trotzdem: Wer versteht was hier passiert, versteht auch nftables.

Das Setup

Dedizierte Firewall-Maschine mit drei Netzwerkkarten. Ein Interface zum Internet (PPPoE), zwei für interne Netze mit unterschiedlichen Berechtigungen. Default-Policy auf allen Chains: DROP. Alles was nicht explizit erlaubt ist, wird verworfen.

Grundstruktur

#!/bin/bash

# Module laden
modprobe ip_tables
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

# Tabellen leeren
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X

# Default: Alles verwerfen
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Custom Chains für Logging

Eigene Chains für sauberes Logging. Jedes verworfene Paket wird mit Prefix geloggt bevor es gedroppt wird:

# MY_REJECT: Protokollieren und zurückweisen
iptables -N MY_REJECT
iptables -A MY_REJECT -p tcp -m limit --limit 7200/h -j LOG --log-prefix "REJECT TCP "
iptables -A MY_REJECT -p tcp -j REJECT --reject-with tcp-reset
iptables -A MY_REJECT -p udp -m limit --limit 7200/h -j LOG --log-prefix "REJECT UDP "
iptables -A MY_REJECT -p udp -j REJECT --reject-with icmp-port-unreachable

# MY_DROP: Portscans stillschweigend verwerfen
iptables -N MY_DROP
iptables -A MY_DROP -m limit --limit 7200/h -j LOG --log-prefix "PORTSCAN DROP "
iptables -A MY_DROP -j DROP

Stealth Scan Detection

Ungültige TCP-Flag-Kombinationen erkennen und verwerfen. Kein normaler Client setzt SYN+FIN gleichzeitig oder schickt ein Paket ohne Flags:

# Keine Flags gesetzt
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j MY_DROP
# SYN und FIN gleichzeitig
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j MY_DROP
# SYN und RST gleichzeitig
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j MY_DROP
# FIN ohne ACK
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j MY_DROP

Connection Tracking und NAT

Stateful Firewall: Bestehende und zugehörige Verbindungen durchlassen, neue nur aus dem internen Netz erlauben. NAT per MASQUERADE für den Internetzugang:

# Loopback erlauben
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Ausgehend: Alles erlauben
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# Forwarding: Neue Verbindungen nur von innen
iptables -A FORWARD -i ! ppp0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# NAT für interne Netze
iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.0.0/24 -j MASQUERADE

Traffic Shaping mit tc

Mit tc (traffic control) und iptables -t mangle lässt sich die Bandbreite pro Client oder Netz begrenzen. iptables markiert die Pakete, tc ordnet sie in Queues ein:

# HTB Queueing Discipline auf dem internen Interface
tc qdisc add dev eth2 root handle 1:0 htb default 10
tc class add dev eth2 parent 1:0 classid 1:1 htb rate 150kbit ceil 250kbit
tc filter add dev eth2 parent 1: prio 0 protocol ip handle 1 fw flowid 1:1

# Pakete per iptables markieren
iptables -t mangle -A FORWARD -s 192.168.100.0/24 -j MARK --set-mark 1

Kernel-Hardening

Am Ende des Scripts werden Kernel-Parameter gesetzt die über die Firewall hinausgehen:

# SYN-Cookies gegen SYN-Flood
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Source-Routing deaktivieren
for i in /proc/sys/net/ipv4/conf/*; do echo 0 > $i/accept_source_route; done

# Redirects ignorieren
for i in /proc/sys/net/ipv4/conf/*; do echo 0 > $i/accept_redirects; done

# Martian-Pakete loggen
for i in /proc/sys/net/ipv4/conf/*; do echo 1 > $i/log_martians; done

# ICMP-Ping ignorieren
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

# TCP-FIN-Timeout gegen DoS
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

Die Konzepte aus diesem Script gelten unverändert: Default DROP, Stateful Tracking, Custom Chains für Logging, Stealth Scan Detection, Kernel-Hardening. Nur die Syntax hat sich geändert. Wer heute eine Linux-Firewall baut, nimmt nft statt iptables und erspart sich die Modprobe-Zeilen. Für IPv6 braucht man eine eigene Regelkette, damals mit ip6tables, heute in nftables integriert.

Fragen? Einfach melden.

Proxy Server

Alt, tot, überholt, schlecht, nicht nachmachen 🙂


Dieses soll eine kleine Beschreibung über die Gründe, die eigentliche
Installation und Einrichtung meines privaten Proxy­Servers werden. Also kein HowTo!

Sollte jemand Fragen oder Anregungen haben, freue ich mich natürlich über jede
E­Mail. Solltest du Fragen stellen achte bitte darauf deine Frage so genau wie irgend
möglich zu stellen. Beschreibe kurz dein Problem, haue mich nicht mit log und configs
zu und habe etwas Geduld. Ich bekomme nicht nur eine E­Mail am Tag. Darum werde ich ganz
sicher nur auf unfreundliche und ungenaue Fragen antworten. KEINER hat ein Recht drauf von mir
Support zu bekommen!!

Nun, die Situation bei mir schaut ca. so aus: Meine Familie, der Nachbar und ich selbst sitzen
zusammen im Netzwerk. Zu dem kommt immer mal wieder Besuch zu uns. Da wir auch etwas mehr
Platz als der normale Durchschnitt haben, finden auch oft irgendwelche LANs usw. bei uns stat.
Zu dem hängt noch eine Firma und ein geschlossenes WLAN mit drin.

Da ist ein Problem mit der Sicherheit natürlich vorprogrammiert und den überblick kann
man da so einfach auch nicht mehr behalten. Das Netzwerk ist daher in mehrere Bereiche, mit
unterschiedlichen Rechten aufgeteilt worden. Das Netzwerk ist zum Internet hin durch eine Firewall,
Proxy und MTA abgeschirmt. Zu MTA und Firewall sind andere Projektbeschreibungen zu finden.

Die Hauptgründe für die Einrichtung des Proxy­Servers sind also folgende:
­ Zentraler check der vom User angeforderten Webseiten auf z.B.: jugendgefährdende Inhalte
­ Zentraler check der vom User angeforderten Dateien auf Viren
­ Keine zusätzliche Software auf den Clients
­ Schneller Zugriff auf oft abgefragte Internetseiten

Mein Proxy­Server sollte also folgendes leisten können. Zum einen sollte er die
angeforderten Webseiten auf bestimmte Worte in dessen Text durchsuchen können. Findet er
dort Worte welche nur auf Internetseiten vorkommen sollten welche nicht….. sagen wir mal,
für die tägliche Arbeit am Rechner sinnvoll sind, sollte dieser dann den Zugriff auf
diese Seite verweigern. Bei mir bereits als „bedenkliche“ oder gefährliche Webseiten
bekannte Domains, sollte der Proxy natürlich in jedem Fall den Zugriff verweigern. Es kommt in einem
Netzwerk oft vor, dass ein und die selbe Quelle im Internet mehrmals von verschiedenen Usern angefragt wird.
Warum sollte man also diese Seite für jeden Rechner einmal und vor allem immer wieder aufs Neue vom
Webserver herunterladen? Der Proxy­Server sollte also auch in der Lage sein, Webseiten bzw. deren
Inhalte sinnvoll zu cachen. Leider kommen Viren und kleine aber sehr lästige Progämmchen nicht
nur als E­Mails oder auf Grund von Angriffen ins System, sondern leider auch sehr oft durch unbedachte
Downloads von Dateien der User. Um diese mal wieder vor sich selbst schützen zu können, müssen
alle angeforderten Daten auf Viren und der gleichen getestet werden. Ich selbst habe auf alenl meinen Systemen das
Antivirenprogramm Antivir der Firma H+BEDV Datentechnik GmbH installiert. Ich kann dieses Programm für
Unix, besonders aber für Linux Umgebungen nur empfehlen. Daher ist es logisch, dass ich dieses
Programm am liebsten auch zum Testen der Proxydaten einsetzten möchte. So erspare ich mir die Arbeit
gleich mehrere Virenprogramme zu warten.

Folgendes habe ich mir nun also eingerichtet.
Um sicher zu stellen, dass keine normalen Internetseiten mehr, ohne Zwischenspeicherung, Auswertung und
Virentest bei den User ankommt, habe ich über die Firewall alle direkten Verbindungen auf Port 80
und 21 verboten. Meine Erfahrung hat gezeigt, dass Viren und bedenkliche Webinhalte kaum über
verschlüsselte Seiten (also Port 445) gefunden werden. Diese habe ich auch weiterhin durchgelassen.

Als Proxy­Server setze ich das Programm Squid ein. Zur Weitergabe der Daten an den Virenscanner nutze
ich das Programm Squirm. Hier kann ich mir sicher sein, dass alles ohne Probleme zusammenarbeiten wird.
Das eigentliche Scannen der Daten übernimmt, wie schon angedeutet, das Programm Antivir. Das eigentliche
Handling der Daten übernimmt aber das Programm ANDURAS SurfProtect.

Nun aber zur Konfiguration des ganzen!

Beginnen wir mit der Wortfilterung. Um diese zu realisieren und auch ständig erweitern zu können
habe ich mir eine Datei mit dem namen domains.deny im Ordner /etc/squid angelegt. In diese Datei müssen
nun untereinander die Worte geschrieben werden, welche nicht erwünscht sind. Hier ein Auszug aus der Datei:

############ /etc/squid/domains.deny ## Anfang ############
gay
sex
farmsex
nutte
hure
sperma
fotze
arsch
trojaner
hacker
hackertools
crack
keygen
warez
nuke
nuketools
dildo
masturbating
fucking
slut
emule
xmule
edonkey
Kazza
arschficken
spermaschleuder
kindersex
fotzenschleim
############ /etc/squid/domains.deny ## Ende ############

Sollte sich ein User über diese „Einschränkung“ beschweren druckt man am besten die Liste
aus und klärt mit ihm im öffentlichen Gespräch warum er welches Wort denn unbedingt benötigt.
Um dieses nun in den Proxy­Server Squid einzubinden muss die Datei vom Squid­Deamon gelesen werde können.
Daher sollten noch die Rechte gesetzt werden. Jetzt muss noch folgender Eintrag in die Konfigurationsdatei squid.conf:

acl domains.deny urlpath_regex ­i "/etc/squid/domains.deny"
acl domains dstdom_regex ­i "/etc/squid/domains.deny"
http_access deny domains.deny
http_access deny domains

Hier ist aber zu beachten, dass man die Einträge jeweils VOR den anderen acl und http_access Einträgen in
der Konfigurationsdatei schreibt, da diese von oben nach unten abgearbeitet werden.

Nach dem Speichern sollte man nun Squid die neue Konfiguration „einprügeln“:

squid -k reconfigure

[als root in der Konsole]

Erledigt das für uns.

Die acl und http_access Regeln sind in der Konfigurationsdatei ganz gut beschrieben. Daher gehe ich da nicht weiter
drauf ein. Da wir aber gerade bei der Konfigurationsdatei sind… Einige Einträge können wir gleich noch machen.
Dazu gehen wir ganz an das Ende der Datei. Dort tragen wir folgendes ein:

http_port 192.168.100.1:3128
http_port 127.0.0.1:3128
cache_effective_user squid
cache_effective_group squid
visible_hostname router
unique_hostname router
cache_dir ufs /home/spool/squid 1000 16 256
cache_mgr kernel­error@kernel­error.de
emulate_httpd_log off
cache_mem 16 MB
ftp_user root@kernel­error.de

Jetzt müssen wir uns kurz vergewissern ob wir hiermit nicht gerade doppelte Einträge gemacht haben. Also schauen
wir die Konfigurationsdatei durch, ob die einzelnen Einträge nicht schon irgendwo existieren. Interessant ist
natürlich nur der erste Teil.

Unsere Einträge bewirken folgendes:
http_port 192.168.100.1:3128
http_port 127.0.0.1:3128

Hier werden die lokalen IP Adressen und Portnummern fest gelegt auf denen Squid lauschen soll. Die Adresse 127…
bla ist für den localhost, die Adresse 192.168.100.1 ist für die dritte NIC in meinem Proxy­Server
gedacht. Der TCP Port ist jeweils 3128. Wenn man all diese Einstellungen nicht setzt lauscht Squid normalerweise
auf Port 8080, dieses aber auf jeder NIC im System.

cache_effective_user squid
cache_effective_group squid
Hier wird der Username und die Gruppe festgelegt mit welchem Squid die Dateien und Ordner in seinem Cache verarbeitet.

visible_hostname router
unique_hostname router
Hier gebe ich den Computernamen an, welcher dem User angezeigt werden soll.

cache_dir ufs /home/spool/squid 1000 16 256
Hier wird nun angegeben wo genau Squid seine Daten zwischenspeichern soll. Die weitern Angaben sind die maximale
Grösse des Caches in MB, die maximale Anzahl von Ordnern in einem Ordner und die maximale Anzahl von Unterordnern
im Cache. Squid läuft bei mir nun schon seit 4 Jahren. In dieser Zeit habe ich herausgefunden, dass er mit
diesen Einstellungen schnell und stabil läuft. Auf anderen Rechnern mit anderem Dateisystem usw. kann das
natürlich auch anders aussehen. Wieder mal so eine Sache wo man etwas probieren muss.

cache_mgr kernel-error@kernel-error.de
Sollte Squid eine Seite nicht finden, den Zugriff verweigern oder sonst etwas. Sagt er dem User er könne
sich mit seinen Problemen und Sorgen an diese E­Mail Adresse wenden. Will man möglichst wenig genervt
werden sollte man diese dann gegen /dev/null linken 🙂

emulate_httpd_log off
Squid legt natürlich Logdateien an. Leider formatiert squid die standardmässig so, dass kein Mensch
diese lesen kann. Mit dieser Einstellung kann man Squid aber dazu überreden diese lesbar darzustellen.

cache_mem 16 MB
Diese Einstellung sagt Squid wie viel Arbeitsspeicher er sich maximal unter den Nagel reissen darf. Ich habe
256 MB in diesem System verbaut. Mit 16 MB für den Squid läuft das Teil immer noch schön rund
und Squid kommt auch nicht aus der Puste.

ftp_user root@kernel­error.de
Wird über Squid auf einen FTP­Server zugegriffen gibt er diese E­Mailadresse an. Ob das nötig
ist oder nicht muss man selbst entscheiden.

Nun sollte Squid normalerweise laufen und die Webseiten nach Worten filtern. Sollte noch nicht klar
sein, wie man gleich ganze Domains sperrt, sollte man sich noch mal mit dem Punkt ACLs beschäftigen. Im
Notfall antworte ich auch auf E­Mails. Tja, jetzt fehlt uns nur noch der Virenscanner, richtig?

Das Programm ANDURAS SurfProtect funktioniert folgendermassen. Wenn man im Internet surft laufen nun ja alle
Daten durch den Proxy. Dieser gibt bestimmte Dateitypen nun über Squirm weiter an SurfProtect. SurfProtect
ist selbst ein PHP Programm welches auf dem lokalen Webserver (es könnte theoretisch auch auf einem anderen
System laufen) läuft. Squirm gibt nun also die Anforderung der Datei virus.exe, von der Internetseite www.virus.com,
weiter an SurfProtect. Dieses öffnet nun ein Popupfenster auf dem Rechner des Users im welchem ihm mitgeteilt wird,
dass er kurz warten soll. Saugt dann die Datei Virus.exe von der angegebenen Quelle und speichert sie im Temp
zwischen. Nun checkt es mit dem Programm Antivir ob die Datei virenverseucht ist oder nicht. Ist sie es, wird dem
User der Zugriff auf diese Datei verwehrt (Bild 1) und diese dann gelöscht. Anderweitig wird dem User gesagt, die Datei
ist virenfrei und kann jetzt mit einem klick auf „Speichern“ abgespeichert werden (Bild 2). SurfProtect speichert
die Datei nun einen Tag lang zwischen, schaut aber bei jeder neuen Anfrage erst nach ob nicht vielleicht die Datei
auf der Quelle verändert wurde. So muss die Datei nicht bei jeder Anfrage neu heruntergeladen werden.

Um die Daten nun mit der Hilfe von Squirm weiter zu reichen muss folgendes in dessen Konfigurationsdatei eingetragen werden:

abortregexi (^http://192.168.0.200/+surfprot/+surfprot\.php.*$)

# rules to redirect certain files to SurfProtect...
regexi (^.*\.zip$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.zip\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.doc$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.doc\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.exe$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.exe\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.gz$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.gz\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.tar$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.tar\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.com$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.com\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.bat$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.bat\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.scr$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.scr\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.rar$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.rar\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.cmd$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.cmd\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.reg$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.reg\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1

# Skip all local files
abortregexi (^http://192\.168\.0\.1\.*)
abortregexi (^http://192.168.0.200.*)

Schaut etwas wüst aus? Ist es aber nicht 🙂

regexi (^.*\.reg$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1
regexi (^.*\.reg\?.*$) http://192.168.0.200/surfprotect/surfprot.php?url=|\1

Dieser Eintrag sagt: Alle Dateien mit der Endung reg sollten an http://192.168.0.200/surfprotect/surfprot.php?url=
weitergereicht werden. Tja, das ist auch schon alles. Man muss also nur für jede Datei die man scannen will so
einen Eintrag anlegen.

SurfProtect selbst liegt im Ordner /surfprotect unter dem Ordner html im www­Teil des Apache.
Dort liegen auch die Konfigurationsdateien. Ob man den Zugriff auf diese gewehrt oder nicht, ist einem selbst und den
Einstellungen des Apache überlassen. Die User könnten diese zwar nur lesen aber noch nicht mal mehr das
geht sie ja etwas an. Daher sollte man nur den Zugriff auf die Datei surfprot.php genehmigen.

In der Datei surfport.defaults sollte man nun noch unten folgendes eintragen:

define(SCANNER_INCLUDE, "surfprot_hbac.inc");

Damit wird SurfPortect gesagt es soll das Plugin zur Verwendung des Programmes AntiVir laden.

Damit sollte der Proxy nun auch nach Viren suchen.

Hier nun noch zwei Bilder, welche der User zu sehen bekommt. Das, was sich nun für die User ändert:

Proxy server configuration dialog

SurfProtect verweigert den Zugriff.

Proxy server connection status

SurfProtect erlaubt den Zugriff.

Dualhead mit KDE

Ich habe mir vor ein paar Tagen eine neue Grafikkarte geleistet. Es ist eine Gainward PowerPack Ultra /1980. Auf dieser ist ein GeForce 6600GT Chip mit 256MB DDR3 RAM verbastelt. Nun hat die Karte einen Analogen VGA Connector und einen DVI Connector. Ich selbst habe hier noch einen 17” CRT Monitor in der Ecke stehen. Da ist mir nun eine Idee gekommen…. Ich könnte ja einfach zwei Monitore an meinen Linux Rechner anschließen. An meinem Hauptrechner ist ein 19” CRT Monitor mit Analogeingang angeschlossen. Diesen einfach mit dem DVI Adapter an den DVI Connector der VGA-Karte und den 17“ CRT Monitor (auch Analogeingang) an den normalen Analog VGA Connector der VGA-Karte. Tja… einschalten und schaut selbst: KDE dual monitor desktop setup with Nvidia Beim Booten zeigen beide Monitore schon mal das gleiche an. Zumindest bis der X-Server gestartet wird. Bei mir werkelt der X.org. Ist dieser gestartet wird der zweite Monitor abgeschaltet und alles läuft weiter wie gehabt. 🙁 Also schnell STRG + ALT + F1 gedrückt als root angemeldet und direkt mit dem vi in die xorg.conf…. Hier habe ich nun folgendes eingetragen:
Section "ServerLayout"
Identifier "XFree86 Dual-Head"
Screen "Screen0"
Screen "Screen1" RightOf "Screen0"
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "PS/2 Mouse" "CorePointer"
Option "Xinerama" "on"
EndSection
Hier ist der Eintrag Option „Xinerama“ „on“hinzugekommen. Dann die Screen-Sektion! Hier sind die beiden Screens (unten steht mehr) eingetragen. Wichtig ist das RightOf… Dieses gibt an, welche Monitor wo seht. Ok und den Identifier habe ich etwas umbenannt das ist aber für die Funktion uninteressant! Die weiteren Punkte sind wie so oft selbsterklärend, finde ich zumindest.
Section "Monitor"
Identifier "Monitor0"
VendorName "AOC"
ModelName "19"
Option "DPMS"
EndSection

Section "Monitor"
Identifier "Monitor1"
VendorName "AOC"
ModelName "17"
Option "DPMS"
EndSection

Section "Device" Identifier "Card0"
Driver "nvidia"
VendorName "Nvidia Technologies Inc"
BoardName "Nvidia 6600 GT"
BusID "PCI:1:0:0"
Screen 0
Option "AGPFastWrite" "True"
EndSection

Section "Device"
Identifier "Card1"
Driver "nvidia"
VendorName "Nvidia Technologies Inc"
BoardName "Nvidia 6600 GT"
BusID "PCI:1:0:0"
Screen 1
Option "AGPFastWrite" "True"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1280x1024"
EndSubSection
EndSection

Section "Screen"
Identifier "Screen1"
Device "Card1"
Monitor "Monitor1"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1280x1024"
EndSubSection
EndSection
So schaut des ganze auf dem Desktop aus wenn es funktioniert. Der Hintergrund ist von http://www.deviantart.com Widescreen display configuration under KDE

Fragen? Einfach melden.

CAcert in Firefox

Veraltet: CAcert-Zertifikate wurden nie in die Standard-Truststores der Browser aufgenommen. Kostenlose TLS-Zertifikate gibt es bei Let’s Encrypt.

CAcert ist eine feine Sache. Leider sind deren Root-Zertifikate noch nicht in allen Browsern und Programmen integrieret.

Ich habe mir nun Gedanken dazu gemacht:

Wie schaffe ich es die CAcert-Root-Zertifikate in Anwendungen von Microsoft (Word, Outlook, Internetexplorer..) und Mozilla (Thunderbird, Firefox…) so zu integrieren das sie immer als vertrauenswürdig erkannt werden? Auch bei allen anderen Usern auf dem System und denen die später noch ein neues Konto bekommen…

Natürlich könnte ich bei jedem User die Zertifikate einzeln mit der Hand importieren und als vertrauenswürdig einstufen.  Es ist aber sehr aufwändig und bestimmte User haben damit ein, nennen wir es Problem! Es muss also automatisch gehen.

Für die Microsoftprodukte habe ich eine einfache Lösung gefunden. Mit >>dieser<< Regestrierungsdatei werden die CAcert-Root-Zertifikate automatisch ins System übernommen. Ab diesem Moment sind in allen Microsoftanwendungen, bei allen Usern (vorhandenen und neuen) eines Systems die Zertifikate gültig.

Bei Mozilla ist es nicht ganz so einfach. Hier geht es am einfachsten so:

!!Firefox sollte noch nicht auf dem System installiert sein!!

Zuerst besorgt man sich die Installationsdatei für den Firefox. Am einfachsten wohl hier:  http://www.mozilla-europe.org/de/firefox/

CAcert certificate import in Firefox, step 1

Dann installiert man den Firefox wie gewohnt, startet ihn und importiert die CAcert-Root-Zertifikate als vertrauenswürdig. Jetzt Firefox zu machen und lassen! Bisher alles klar und einfach. Aber nun…

CAcert certificate import in Firefox, step 2

Jetzt sucht man unter: Dokumente und Einstellungen\seinUsername\Anwendungsdaten\Mozilla\Firefox\Profiles\irgendwas.default\ die Datei cert8.db. Gefunden? Gut… Merken wo!

CAcert certificate import in Firefox, step 3

Jetzt das Firefoxinstallerpacket entpacken. Am einfachsten vielleicht mit WinRAR.

CAcert certificate import in Firefox, step 4

Nun kopiert man die cert8.db in den, gerade entpackten Ordner, Firefox Setup 3.0.1\localized\defaults\profile\

CAcert certificate import in Firefox, step 5

Startet man nun die Firefoxinstallation über die setup.exe sind die CAcert-Root-Zertifikate immer automatisch im Firefox integriert. Da immer wenn ein User das erste mal den Firefox startet, sein default Profile zusammengestellt wird. Es wird also immer die cert8.db mit in sein Profil kopiert. In dieser liegen die Zertifikate. Also auch unserer importierten CAcert-Root-Zertifikate. Dieses Packet könnte man nun immer für seine Installationen nutzen und vielleicht auch weitergeben. Will man allen existierenden Usern die Zertifikate unterschieben, muss man einfach nur die cert8.db in dessen Ordner packen (Dokumente und Einstellungen\seinUsername\Anwendungsdaten\Mozilla\Firefox\Profiles\irgendwas.default\).

So funktioniert es auch unter Thunderbird. Bei Linux funktioniert es auch über diese Datei.

Ich diese Infos helfen dem Einen oder Anderen. Wenn noch jemand Infos dazu hat, freue ich mich natürlich über zuschriften!

Fragen? Einfach melden.

CAcert Nokia

Veraltet: Nokia S40 und S60 gibt es nicht mehr, und CAcert hat es nie in die Browser-Truststores geschafft. Dieser Beitrag ist nur noch als Zeitdokument interessant.

CAcert.org Root Zertifikate unter Nokia S40 und S60 installieren. Ich habe ein Nokia 6300i. Dieses Gerät tut alles genau so wie ich es benötige. Nur eine Kleinigkeit hat mich gestört. Immer wenn ich versuche E-Mails von meinem IMAP-Server zu saugen oder E-Mails über meinen SMTP-Server zu verschicken, wird das jeweilige Zertifikat (SSL / TLS) als ungültig gemeldet. Was daran liegt, das ich diese beiden Zertifikate von CAcert habe unterschreiben lassen. Es müssen also die Root-Zertifikate (http://www.cacert.org/index.php?id=3) ins Mobiltelefon! Natürlich habe ich sofort versucht die Zertifikate ins Gerät zu bekommen. Leider scheiterte es immer an der Meldung: „Dateiformat nicht unterstützt“. Daraufhin habe ich viele und lange sinnlose E-Mails mit dem Nokia-Support getauscht. Leider ohne erfolg. Ich habe das weiter unten mal zusammengeschrieben, hier nun erstmal der genaue Weg die Zertifikate ins Handy zu bekommen: Zuerst auf dem Rechner eine HTML-Datei mit folgendem Namen erstellen: cert.html Der Inhalt sollte ca. so ausschauen: —– HTML-schnipp —– <?xml version=“1.0″?><!DOCTYPE html PUBLIC „-//WAPFORUM//DTD XHTML Mobile 1.0//EN“ „http://www.wapforum.org/DTD/xhtml-mobile10.dtd“><html xmlns=“http://www.w3.org/1999/xhtml“><head><title>Installing CAcerg.org<br>Root Certificate</title></head><body><p><a href=“root.cer“>Installing Class1 PKI Key</a><br><br><a href=“class3.cer“>Installing Class3 PKI Key</a><br><br><a href=“https://www.kernel-error.de“>Und nun testen..</a></p></body></html> —– HTML-schnapp —– Dann die beiden Zertifikate von CAcert.org herunterladen. Einmal das class1 und einmal das class3, jeweils im PEM format. Diese müssen nun konvertiert werden, ich nutze dafür openssl: openssl x509 –in root.crt –inform PEM –out root.cer –outform DER openssl x509 –in class3.crt –inform PEM –out class3.cer –outform DER Jetzt müssen die Dateien (cert.html, root.cer und class3.cer) ins gleiche Verzeichnis ins Mobiltelefon kopiert werden. Dort nun übers das Telefonmenu hinklicken und die cert.html öffnen. Galerie auf dem Nokia 6300i Der Ordner Empfangene Dateien auf dem Nokia 6300i Ordnerinhalt Empfangene Dateien Nokia 6300i Wenn sich diese geöffnet hat einfach die Links von oben nach unten durchklicken und die jeweiligen Zertifikate speichern. cert.html Installationsdatei der CAcert Zertifikate Das ist dann schon alles…. Fertig! CAcert im Nokia Hier nun der zusammengeschriebene Teil vom Nokiasupport. —– NokiaCare schnipp —– Wir möchten Ihnen mitteilen, dass das X.509 Zertifikat umgewandelt werden muss, bevor Sie es auf Ihr Nokia 6300i übertragen können. Ihr Nokia 6300i unterstützt .p12 Zertifikate. —– NokiaCare schnapp —– P12 klang für mich nicht sinnig, probiert habe ich es denn noch… Ohne erfolg! Daher wieder eine E-Mail an den Support, vielleicht muss es ja irgendwo gesondert hin oder sonst was… —– NokiaCare schnipp —– Bitte kopieren Sie das *.12 Zertifikat mit der PC Suite auf Ihr Mobiltelefon. Die Datei muß nicht in ein spezielles Verzeichnis kopiert werden. Die Datei wird automatisch von MfE verarbeitet. —– NokiaCare schnapp —– Alles klar… geht nicht immer noch die Meldung: „Dateiformat nicht unterstützt“ Lieber noch einmal nachfragen und mein Problem deutlicher erklären! —– NokiaCare schnipp —– Übertragen Sie die Datei auf das Mobiltelefon, gehen Sie in den Dateimanager und rufen Sie die Datei auf, dies installiert sich dann automatisch. —– NokiaCare schnapp —– Das funktioniert so nicht… Zu dem brauche ich kein Benutzerzertifikat sonder das einer CA…. Noch eine E-Mail an Nokia! —– NokiaCare schnipp —– Um private Schlüssel importieren zu können, erstellen Sie bitte eine *.p12-Datei. Diese enthält Ihren privaten Schlüssel und das Benutzerzertifikat. Diese Datei importieren Sie bitte in Ihr NOKIA Mobiltelefon. Dort wird das Zertifikat automatisch erkannt. Zur Speicherung folgen Sie bitte den Hinweisen des Telefons. Nun werden Sie zur Eingabe eines Sicherheitscodes aufgefordert. Beachten Sie bitte dabei, dass die geforderte Sicherheitseingabe ausschließlich aus Ziffern bestehen darf. Das geforderte Passwort wird durch die Zertifizierungsstelle erstellt. —– NokiaCare schnapp —– Ich scheine nicht im Stande zu sein mein Problem verständlich in eine E-Mail zu packen! Ich beschließe eine weitere E-Mail zusammen mit meiner Frau zu schreiben (diese entspricht dem durchschnittlichen PC-User)! Und hier ist Nokias Antwort: —– NokiaCare schnipp —– Scheinbar haben wir uns bei Ihrem angegebenen Telefonmodell verlesen.Ihr NOKIA 6300i ist ein Gerät der Serie 40. Die Angaben die wir Ihnen gemacht haben, beziehen sich auf S60 Geräte.Dafür möchten wir uns entschuldigen. Sie sollten das entsprechende Zertifikat im Format DER konvertieren und erneut wie angegeben auf Ihr NOKIA Mobiltelefon übertragen.Es sollte sich nun installieren lassen. Wir wünschen Ihnen viel Freude mit den Produkten aus unserem Haus. —– NokiaCare schnapp —– Verlesen? Was habe ich denn noch gleich geschrieben *nachschau* —– Meine Mail schnipp —– [Country: Germany] [Language: German] [Permission to Email: ] [Permission to SMS: ] [Permission to Letter: ] [Permission to Phone: ] [First name: van de Meer ] [Last name: Sebastian] [Street address: Alte Bergstr. 12] [ZIP: 45549] [City: Sprockhövel] [Email address: kernel-error@kernel-error.de] [Landline: +49 02324 6858622Click2Dial icon] [Mobile: +49 0177 5995900Click2Dial icon] ] [Phone model: Nokia 6300] [IMEI: ] [Shop number: ] [CID: ] [Contact topic: Nokia Mobiltelefone und Zubehör] [Message: Sehr geehrte Damen und Herren,  wie lassen sich weitere X.509 Root Zertifikate einer CA in meinem 6300i importieren? Mit besten Grüßen  S. van de Meer] [Operator: E-plus] [Operating system: Linux] —– Meine Mail schnapp —– Öhm… egal! Ich probiere es mal (auch wenn ich das natürlich schon probiert habe)! Komisch immer noch die gleiche Meldung: „Dateiformat nicht unterstützt“ —– NokiaCare schnipp —– Bezüglich Ihrer Anfrage möchten wir Ihnen mitteilen, dass Sie das DER-typ X509v3 Zertifikat für Ihr S40 Handy benötigen. Sie müssen das CER (Base64) Zertifikat ins DER (binary Format) konvertieren. —– NokiaCare schnapp —– Da ich genau das schon probierte habe ich an diesem Punkt die Zusammenarbeit mit dem Nokia Support aufgegeben! Ich habe nun begonnen herumzubasteln und zu testen! Der installierte Opera wird auf dem Gerät zum Browsen benutzt, scheint aber nicht wirklich etwas mit der Systemeigenen CA-Liste zutun zu haben (wie sein großes Vorbild halt). Daher bringt es mir auch nichts mit dem Teil auf irgendwelchen Webseiten herumzufummeln. Irgendwann habe ich mal probiert welche Formate unterstützt werden. Interessanterweise ging bei HTML nicht der Opera auf, sondern der „systemeigene“ Browser. An dieser Stelle ist mir dann die oben stehende Idee gekommen!

Fujitsu Siemens Lifebook E7110: Linux auf einem Pentium 4-M Notebook

Dieser Beitrag ist ein Zeitdokument von 2009. Das Lifebook E7110 war damals schon alt, die Tipps sind heute nur noch historisch interessant. Aber wer wissen will, wie Linux auf einem Pentium 4-M Notebook mit Gentoo, Kernel 2.6.12 und PCMCIA lief, ist hier richtig.

Ich habe mir das Fujitsu Siemens Lifebook E7110 angeschafft. Mitgeliefert wurde Windows XP Professional, was natürlich nicht lange auf dem Gerät überlebt hat. Ungefähr so lange, bis ich es in Händen gehalten habe. Installiert habe ich sofort Linux. Da ich mich vor dem Kauf über die Hardware informiert hatte, lief auch so ziemlich alles.

Hardware-Kompatibilität

StatusGerätDetails
JaProzessorIntel Mobile Pentium 4-M, 2,0 GHz
JaChipsatzIntel 845 MP
JaSpeicher1 GB DDR-RAM
JaGrafikATI Radeon M 7500, 32 MB DDR (dedicated)
JaDisplay15,1″ SXGA+ (1024×786)
JaSoundSigmaTel STAC9767, SB Pro kompatibel
JaEthernetRealtek 8139/8139C
JaWLANPrism2 (InterSil), MiniPCI
JaUSBIntel 845-MP 82801CA
JaIEEE 1394Texas Instruments TSB43AA21
JaIrDASMSC LPC47N267
JaCardBusO2Micro OZ 711 E1
JaDVD-ComboToshiba SD-R2212
JaTV-OutS-Video (über atitvout)
JaACPIPhoenix ACPI, Suspend funktioniert
TeilweiseModemV.90 Mini-PCI (nie getestet, nicht gebraucht)
NeinSondertasten5 Tasten, unter Linux nicht nutzbar

Festplatten-Tuning

Die originale Toshiba MK4018GAS (40 GB) habe ich gegen eine Hitachi Travelstar 7200 RPM (60 GB) getauscht. 40 MB/s statt 26 MB/s. Dazu noch etwas hdparm-Tuning:

hdparm -d1 -c1 -A1 -m16 -u1 -a64 -k1 /dev/hda

WLAN-Firmware

Die Prism2-Karte von InterSil kam mit einer alten Firmware (~1.4.1). Damit gab es defekte Pakete und kein Hidden ESSID. Erst ab Firmware 1.7.4 lief alles sauber. Das Flashen war etwas abenteuerlich, hat aber funktioniert.

Bluetooth und SmartCard

Bluetooth per USB-Stick (MSI BToes) lief sofort. Hauptnutzen: SMS verschicken und das Sony Ericsson T610 synchronisieren. Später kam eine 3COM Bluetooth PCMCIA-Karte, die direkt mit dem Kernel-Treiber funktionierte.

Der mitgelieferte O2Micro SmartCard Reader (PCMCIA) brauchte den MUSCLE-Treiber und pcsc-lite. Die Konfigurationsdatei musste manuell in die PCMCIA-Config kopiert werden, dann lief auch das.

Das System

Gentoo Linux mit Kernel 2.6.12 und KDE. Der Kernel war sorgfältig auf das Notebook zugeschnitten. Ab Kernel 2.6.13 gab es Probleme mit dem neuen PCMCIA-Subsystem (pcmciautils statt cardmanager), deshalb bin ich bei 2.6.12 geblieben.

Wer noch mehr mit WLAN-Hardware experimentieren will: Im Beitrag D-Link DWL-900AP+ aufbohren geht es darum, die Sendeleistung eines Access Points per Lötkolben zu erhöhen.

Fragen? Einfach melden.

DAVfs2 und GMX: WebDAV unter Linux einrichten

Mit davfs2 den 1GB großen GMX Account als Laufwerk einbinden.

Den GMX Account gibt es kostenlos und man hat die Möglichkeit ihn mit bis zu 1GB Daten zu füttern. Fast jeder Linux User hat schon in den Konqueror ein: webdavs://mediacenter.gmx.net/ getippert und dort einige Daten zwischengelagert oder sonst etwas damit angestellt!

Wäre es nicht aber eine wunderbare Sache diesen Speicherplatz zu mounten und dann so nutzen zu können wie jedes andere „normale“ Laufwerk?

Ein großer Vorteil ist die Erreichbarkeit. Denn fast alles läuft über https. Ist also fast in jeder Firewall offen und es ist verschlüsselt. Was will man mehr?

Wer es nun einrichten möchte, sollte wie folgt vorgehen:

1.
Zuerst muss das Paket „davfs2“ installiert werden. Gentoo User machen einfach mal ein emerge -a davfs2. Unter /etc/davfs2 müssen in der Datei ’secrets‘ die Accountdaten für das GMX-Mediacenter, nach folgendem Schema, gespeichert werden:

# 1. Account
https://XXXXXXXX@mediacenter.gmx.net/ XXXXXXXX „Passwort1“
# 2. Account
https://YYYYYYYY@mediacenter.gmx.net/ YYYYYYYY „Passwort2“

Die Buchstabenreihe ist hier gegen die achtstellige Kundennummer des Accounts zu ersetzten. In der Datei wird nun das Kennwort im Klartext stehen. Aus diesem Grund sollte die Datei nur vom root zu lesen sein chmod 0600!

2.
Mountpunkte setzen und User-Mount erlauben

Zuerst muss im Dateisystem für die externen Datenspeicher ein Mountpunkt angelegt werden. In diesem Beispiel werden ‚/mnt/extern1‘ resp. ‚extern2‘ verwendet.

Die Datei /etc/fstab wird sodann um die zwei Mounpunkte und den Mountparametern erweitert:

https://XXXXXXXX@mediacenter.gmx.net/ /mnt/extern1 davfs user,noauto 0 0
https://YYYYYYYY@mediacenter.gmx.net/ /mnt/extern2 davfs user,noauto 0 0

 Als root kann man nun mit mount /mnt/extern1 den externen Webdav-Datenspeicher einbinden. Damit aber ein normaler User die Mediacenter mounten kann, müssen zusätzliche Vorkehrungen getroffen werden.

Auf /usr/lib/mount-davfs-2.6 muss das SUID-Bit als root mit chmod 4755 gesetzt werden. Wer einen 2.4er-Kernel verwendet, nimmt /usr/lib/mount-davfs-2.4.

Der herkömmliche Benutzer besitzt keine Schreibrechte auf /var/run/mount.davfs. Da in diesem Verzeichnis die PID des Mountprozesses abgelegt wird, sollte man als root die Berechtigungen bspw. mit chmod auf ‚0770‘ setzen und die Gruppe des Verzeichnisses mit chgrp auf ‚users‘ (z.B.) setzen. Hier kann man verfahren wie man möchte, Hauptsache ist nur, dass der oder die Benutzer das Verzeichnis schreiben dürfen. Allerdings empfiehlt sich ein chmod 0777 nicht unbedingt.

Als letzten Schritt kopiert man die Datei /etc/davfs2/secrets in das Homeverzeichnis des entsprechenden Benutzers in den Ordner ~/.davfs2. Auch hier muss die Datei secrets die Zugriffsrechte 0600 aufweisen.

Fragen? Einfach melden.

SSH/OpenSSH

SSH (SecureShell) ist inzwischen sehr verbreitet. Es hat bzw. sollte Telnet überall ersetzt haben. SSH nutz eine Verschlüsselung um zwischen zwei Rechnern Daten auszutauschen. SSH kann aber noch vieles mehr. Z.B. kannst du mit scp einfach, schnell und sicher Dateien von einem Rechner auf einen anderen Kopieren.
scp dateien user@rechner:/pfad
Du kannst aber auch X-Weiterleitungen sehr einfach realisieren. Hierzu musst du einfach in deine sshd_config folgende Option auf yes setzten.
X11Forwarding yes
Mal angenommen du besitzt ein altes (SEHR) altes Notebook. Dieses Notebook hat gerade noch genug Leistung zum Hochfahren und starten des X-Servers. Dieses Notebook könntest du jetzt als eine Art X-Terminal benutzen. D.h.: du tipperst ein:
ssh -X rechner
in deine X-Konsole und meldest dich nun mit deinen Usernamen an einem Zweitrechner in deinem Netzwerk an, welcher etwas mehr Leistung hat und auch gleich noch die Programme installiert sind, mit denen du jetzt gerne auf dem Notebook arbeiten willst. Du tipperst nach der Anmeldung also ooffice oder was du halt gerade brauchst ein. Darauf bekommst du dann nur die GUI auf dein Notebook. Die gesamte Datenverarbeitung und Rechenleistung für das genutzte Programm kommt nun vom anderen Rechner. Bist du mal über eine sehr schwache Leitung an dein System angeschlossen kann dir die Option -C sehr helfen. Diese sorgt dafür das der gesamte Datenstrom komprimiert wird. So ist die zu übertragende Datenmenge kleiner und alles sollte flotter gehen.
ssh -C rechner

Wie sicher ist dieses SSH denn nun?

Man kann sagen, recht sicher. Es gibt natürlich keine absolute Sicherheit und es hängt auch immer ein großer Teil vom User und der Konfiguration ab. Du solltes also einige Punkte in der Konfiguration seines SSH-Servers ändern. Diese liegt fast immer unter: /etc/ssh/ und schimpft sich sshd_config! – Nur SSH2 Das SSH1 Protokoll gilt als unsicher. Programme wie z.b.: ettercap sind in der Lage hier Kennwörter und Usernamen herauszulesen. Zu dem bietet SSH2 eine ganze Stange mehr an Möglichkeiten. Daher sollte nur das Protocol 2 genutzt werden.
Protocol 2
– Root-Login is nicht Der User Root braucht keinen direkten Login. Wer wirklich von extern auf seinem Rechner administrieren will der kann als User auch su oder sudo benutzen. Da SSH2 wohl kaum zu entschlüsseln ist, wird ein Angreifer es meist mit Brute Force versuchen. Er braucht zu dem Kennwort welches er damit bekommen möchte erst mal einen Usernamen. Da er Root haben will und dieser wohl auch immer auf einer Linux-Kiste zu finden ist, wird er es auch auf diesen Account probieren. Verbieten wir jetzt aber den Login für den User Root kann der Angreifer es sehr lange Probieren.
PermitRootLogin no
– Kein User/Passwort verfahren Die Geschichte mit dem Brute Force hatten wir ja jetzt. Was aber wenn der Angreifer einen Usernamen von unserem System kennt. Dann ist es erstmal nur noch eine Frage der Zeit. Tja und da die meisten User keine „guten“ Passwörter haben….. Viel besser ist es wenn der User ein Zertifikat hat, mit welchem er sich anmelden darf. Weiter unten zeige ich wie es gemacht wird. Hier aber erstmal das User/Passwort verfahren verbieten!
PasswordAuthentication no
Das Public-Key-Verfahren (jetzt kommt die Beschreibung) ist da viel besser. Zuerst bauen wir einen schön langen Schlüssel auf dem Client:
ssh-keygen -b 4068 -t dsa
Nun tauchen im Homeverzeichniss des Users, mit dem wir den Schlüssel erstellt haben, unter: ~/.ssh/ zwei Dateien auf: id_dsa und id_dsa.pub. Den Publickey id_dsa.pub packen wir nun auf den Server. Direkt in die Datei authorized_keys (vielleicht müssen wir diese noch mit der Hilfe von touch anlegen). Die Datei sollte im Homeverzeichniss des zu autorisierenden Users im Ordner .ssh angelegt werden. Haben wir das alles so eingetragen brauchen wir kein Kennwort mehr.
Wie wäre es mit einem Tunnel durch die Firewall?
OK… klingt ja ganz nett. Aber warum sollte ich einen Tunnel in meine Firewall machen? Das kann ich dir erklären. Stell dir mal vor du sitzt mit deinem Notebook in einem Netzwerk wo du dir nicht sicher bist das keiner deine Verbindungen abhört oder gar die Verbindungen über bestimmte Ports blockiert sind. Du willst nun aber eine E-Mail schreiben! Oder bestimmte Ports sonst wie durch diese oder eine andere Firewall verschlüsselt tunneln. Um einen einfachen Tunnel zu basteln musst du jetzt nur noch folgendes machen: Computer2:
ssh -N -R 5555:localhost:22 user@erreichbarer_rechner
Jetzt passiert etwas feines 🙂 Denn nun geht am „erreichbarer_rechner“ der Port 5555 auf und der beamt dann alles durch den Tunnel an Computer2 an den Port 22 weiter. Du kannst nun also sitzen wo du willst. Sobald du versuchst dich auf Port 5555 mit dem Computer „erreichbarer_rechner“ zu verbinden, wird deine Anmeldeanfrage direkt an Computer2 weitergeleitet. So bekommst du also sofort das Login von Computer 2.
ssh erreichbarer_rechner -p 5555
Geil, was?

Siehe auch: SSH-Server mit MFA absichern

Fragen? Einfach melden.

IPv6: Adressarchitektur, Autokonfiguration und radvd unter Linux

Meine IPv6-Reise begann 2003. Damals kam IPv6 vom eigenen ISP nicht in Frage, also ging es über einen Tunnelbroker. SixXS stellte kostenlos IPv6-Tunnel bereit und vergab auf Antrag sogar ein komplettes /48 Netz. SixXS wurde 2017 eingestellt, aber die Grundlagen von IPv6 haben sich nicht geändert. Heute liefern die meisten ISPs IPv6 nativ aus.

Adressformat

IPv6-Adressen sind 128 Bit lang. Das sind 2128 mögliche Adressen, ausgeschrieben: 340.282.366.920.938.463.463.374.607.431.768.211.456. Geschrieben werden sie hexadezimal, jeweils zwei Bytes durch Doppelpunkt getrennt:

2a01:0198:0200:0945:0000:0000:0000:0002

Führende Nullen darf man weglassen. Ein zusammenhängender Block aus Nullen kann einmal durch :: ersetzt werden:

# Führende Nullen weg
2a01:198:200:945:0:0:0:2

# Ein Nullblock durch :: ersetzt
2a01:198:200:945::2

# Als Netz
2a01:198:200:945::/64

Wichtige Adressen

::1 ist der Localhost. fe80::/10 sind Link-Local-Adressen, die jedes Interface automatisch bekommt. ff02::1 erreicht alle Hosts im lokalen Netz, ff02::2 alle Router. 2001:db8::/32 ist für Dokumentation reserviert.

# Alle Hosts im lokalen Netz anpingen
ping6 -I eth0 ff02::1

# Alle Router im lokalen Netz anpingen
ping6 -I eth0 ff02::2

Adressbildung und EUI-64

Link-Local-Adressen bildet der Host selbst aus dem Prefix fe80 und der MAC-Adresse im EUI-64 Format. Die MAC-Adresse hat 48 Bit, EUI-64 erweitert sie auf 64 Bit. Zusammen mit dem 64-Bit-Prefix ergibt das die vollen 128 Bit. IPv6 ist damit bereits auf 64-Bit-MAC-Adressen vorbereitet, falls die 48-Bit-Adressen irgendwann knapp werden. Duplicate Address Detection (DAD) stellt sicher, dass keine Adresse doppelt vergeben wird.

Autokonfiguration mit radvd

ARP wurde durch Neighbor Discovery (ND) ersetzt. IPv6 ist auf Autokonfiguration ausgelegt. Ein Router Advertisement Daemon (radvd) teilt allen Hosts im Netz das IPv6-Prefix mit. Die Hosts bilden sich ihre Adresse selbst. Kein DHCP nötig für die Grundkonfiguration.

Forwarding aktivieren und radvd konfigurieren:

echo 1 > /proc/sys/net/ipv6/conf/default/forwarding
# /etc/radvd.conf
interface eth0
{
    AdvSendAdvert on;
    AdvLinkMTU 1280;
    MaxRtrAdvInterval 300;
    prefix 2a01:198:200:945::/64
    {
        AdvOnLink on;
        AdvAutonomous on;
    };
};

Nach dem Start von radvd holen sich alle Hosts im Netz automatisch eine Adresse aus dem Prefix. Prüfen mit:

ip addr show eth0

Kein NAT mehr

Mit IPv6 ist NAT nicht mehr nötig. Jedes Gerät bekommt eine eigene öffentliche Adresse. Das bedeutet aber auch: Jedes Gerät ist direkt aus dem Internet erreichbar. Eine Firewall ist Pflicht. IPv6 hat einen eigenen Paketfilter, ip6tables statt iptables. Wer iptables kennt, kann auch ip6tables.

Über die Probleme die durch fehlende IPv6-Unterstützung bei Diensteanbietern entstehen habe ich separat geschrieben.

Hurricane Electric IPv6 Zertifizierung

Hurricane Electric bietet eine kostenlose IPv6-Zertifizierung an. Man arbeitet sich durch verschiedene Levels, vom ersten Tunnel bis zum voll IPv6-fähigen Mailserver. Am Ende gibt es ein T-Shirt.

Hurricane Electric T-Shirt Sendung
Umschlag aus den USA
Hurricane Electric T-Shirt vorne
T-Shirt vorne
Hurricane Electric T-Shirt hinten
T-Shirt hinten

Fragen? Einfach melden.

Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑