-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: firewall (Seite 1 von 2)

Ist mein Netzwerk kompromittiert? Warum das kaum jemand merkt

19. Dezember 2025 / / Keine Kommentare

Ich habe ja bereits etwas zum Thema IoT-Geräte geschrieben und warum diese oft deutlich schneller gehijackt werden, als man vielleicht erwartet.

Aber woher weiß man nun als normaler Anwender, ob zu Hause oder im eigenen Netzwerk etwas sein Unwesen treibt?
Nun ja; das ist leider überhaupt nicht so einfach.

Symbolische Darstellung eines kompromittierten Netzwerks mit Warnhinweisen, IoT-Kamera und verdächtigem Datenverkehr.

Klar, man kann sich ganz tolle IPS oder IDS aufbauen. Es gibt dafür auch Open-Source-Systeme; Snort fällt mir da als einer der älteren Vertreter als erstes ein.

Aber das alles ist nichts für den normalen Anwender oder den Privathaushalt. Dann gibt es noch ganz furchtbar viele Schlangenölanbieter mit ihrer „Sicherheitssoftware“ für Windows, Android und Co. Klar, man kann dort Firewall, Virenscanner usw. installieren. Aber hilft das wirklich? Jein, würde ich dazu sagen.

Ist man auf einem aktuellen Patchstand, sollten zumindest die bekannten Löcher geschlossen sein. Dann bleiben fast nur noch Zero-Day-Lücken Ein Virenfilter kennt diese in der Regel auch nicht und lässt so etwas dann schlicht durch.

Eine Firewall-Lösung kann zumindest erkennen, ob plötzlich ungewöhnlicher Traffic unterwegs ist oder ob versehentlich gestartete Dienste nach außen offen stehen. Nur steht und fällt das Ganze oft genau in dem Moment, in dem der Anwender nach einer Entscheidung gefragt wird.

Sicherheitssoftware muss naturgemäß sehr tief im Betriebssystem eingebettet werden. Hat diese Sicherheitssoftware dann selbst Sicherheitslücken, was deutlich häufiger vorkommt, als man zunächst glauben möchte, öffnet man im Zweifel die eigene Infrastruktur über genau die Software, die das eigentlich verhindern soll. Vertraut mir da bitte einfach, wenn ich sage, dass ich das schon sehr oft gesehen habe. Zudem installiert sich so eine Sicherheitssoftware oft nicht einfach auf einer Netzwerkkamera.

Der beste Schutz sind, meiner Meinung nach, noch immer gepflegte Systeme, gute Zugangsdaten und das nötige Misstrauen. Wie kam ich jetzt darauf? Ach richtig; wie findet man eigentlich heraus, ob es überhaupt ein Problem gibt?

Klar, man kann abwarten. Irgendwann merkt man es sicher; spätestens dann, wenn die Polizei mit einer Hausdurchsuchung vor der Tür steht und wissen möchte, was man denn da so alles im Internet verteilt oder angreift.

Eine wirklich gute Lösung habe ich da leider auch nicht. Am ehesten noch Dienste wie GreyNoise (https://check.labs.greynoise.io/). Dort kann man beispielsweise gegen AbuseDB prüfen, ob die eigene IPv4-Adresse irgendwo im Internet „auffällig“ geworden ist; etwa durch Portscans, Spam-Versand oder Malware-Traffic. Ebenfalls kann man hin und wieder bei Have I Been Pwned (https://haveibeenpwned.com/) vorbei schauen, um zu prüfen, ob die eignen Zugangsdaten irgendwo gefunden wurden.

Im Allgemeinen ist aber auch das nur ein Indiz. IP-Adressen wechseln; vor allem bei privaten Anschlüssen. Die eigene IP muss erst auffallen, gemeldet werden und so weiter.

Aber hey; vielleicht hat ja noch jemand einen besseren Tipp?

Fragen? Einfach melden.

IP-Kameras: Risiken, Portfreigaben (RTSP/HTTP) & Checks

30. Oktober 2025 / / Keine Kommentare

Moin, ich mag noch einmal etwas zu IP-Überwachungskameras schreiben. Ihr erinnert euch vielleicht an meinen letzten Beitrag zu diesem Thema KLICK.

article image of ip cameras

Dort habe ich mich speziell auf den RTSP-Port bezogen und auch https://www.shodan.io/ als Beispiel genannt. Shodan scannt unaufhörlich IPv4-Adressen (bei IPv6 wäre ein flächendeckender Scan kaum praktikabel) und stellt seine Ergebnisse öffentlich zur Verfügung. Sicherheitsforscher — aber leider auch Menschen mit schlechten Absichten — bedienen sich solcher Dienste, um Informationen über Systeme hinter einer IPv4-Adresse zu bekommen, ganz ohne selbst groß zu scannen oder zu testen. Grob gesagt: Google für „Hacker“.

Dass IP-Kameras — vor allem günstige oder ältere Modelle — schnell ein Sicherheitsrisiko darstellen, habe ich schon erwähnt; wer das hier liest, weiß es in der Regel auch. Automatische Portfreigaben in Kombination mit solchen Kameras sind oft problematisch. Wenn ich über so etwas stolpere und ohne großen Aufwand den Betreiber ausfindig machen kann, versuche ich jeweils per E-Mail oder einem kurzen Anruf zu warnen. Das stößt mal auf offene Ohren, manchmal wird es komplett ignoriert (manchmal mit Abschalten des öffentlichen Zugriffs, manchmal ohne); selten kommt die Antwort „Anzeige ist raus“.

Kameras filmen oft sensible Bereiche, sowohl innen als auch außen. Das kann viele Probleme mit sich bringen, wenn diese Informationen einfach öffentlich zugänglich sind. Anders als bei Datei-Freigaben scheint bei Kamerastreams noch nicht die nötige Awareness vorhanden zu sein — genau deshalb informiere ich hier und weise darauf hin.

Es ist nicht nur der RTSP-Stream, der sich häufig per UPnP seinen Weg nach draußen „tunnelt“. Oft werden auch per DNAT / Portfreigabe / Portweiterleitung die Webinterfaces der Kameras direkt aus dem Internet erreichbar gemacht. Im schlimmsten Fall kann man also mit dem Browser direkt auf Webinterface und Stream zugreifen. Viele sichern den Zugriff mit der kameraeigenen Anmeldung — das ist schon mal ein Anfang. Leider reicht das nicht immer: Bei manchen Modellen sind Funktionen wie Snapshots oder einzelne JPEG-Endpoints weiterhin ohne Anmeldung erreichbar. Das ist auf den ersten Blick nicht sichtbar — kennt man aber die entsprechende URL, genügt ein Browseraufruf und man sieht wieder alles.

Deshalb gebe ich immer den Rat: Zugriff lieber hinter ein VPN legen und niemals direkt offen ins Internet. Gebt jedem Gerät und jedem Dienst, den ihr aus dem Internet erreichbar macht, mindestens so viel Vertrauen wie eurer Haustür. Und prüft regelmäßig, ob dieses Vertrauen noch gerechtfertigt ist.

Wer selbst prüfen möchte, ob die EIGENE Kamera trotz eingerichteter Anmeldung noch irgendwie ohne Login zugänglich ist, kann mein kurzes Python-Tool nutzen: https://github.com/Kernel-Error/cam_probe

Denkt also bitte einmal darüber nach, ob ihr allem, was ihr direkt mit dem Internet verbunden habt, mindestens das gleiche Vertrauen entgegenbringt wie eurer Haustür oder Wohnungstür. Denkt an die security.txt und daran, dass, wenn sich jemand die Mühe macht, euch über ein solches Problem zu informieren, diese Person damit wahrscheinlich den größten Aufwand und auch das größte Risiko für sich selbst aufnimmt – nur, um euch auf ein Problem hinzuweisen.
Einen solchen Fund zu ignorieren, zu verkaufen oder sonst wie auszunutzen, ist deutlich einfacher, als den Betreiber zu informieren.

Natürlich gibt es auch hier schwarze Schafe, aber die Vertrauenswürdigkeit einer solchen Nachricht lässt sich meist schnell per Google oder auch ChatGPT prüfen.
Frage? Dann fragen. 🙂

Draft zu Security Policies

6. November 2019 / / Keine Kommentare

Es gibt seit einiger Zeit einen Draft zu Security Policies. Schaut mal hier: https://tools.ietf.org/html/draft-foudil-securitytxt-07 über diesen Weg kann man für seine Domain eine Security Policie veröffentlichen. Dieses inkl. Kontaktdaten einer „Dankeschön“ Seite usw…

Die Idee ist es eine einheitliche Möglichkeit zu schaffen um freundlichen Findern von Sicherheitslücken/Problemen eine einfache und „sichere“ Anlaufstelle zu geben. Wer schon mal ein Löchlein gefunden hat, kennt das Problem. Man sucht eine Kontaktmöglichkeit, scheitert an der Human Firewall oder am technischen Verständnis von seinem Gegenüber. Gibt es es bug bounty oder wird der Informierte ~nervös~?!? Ist die Webseite vielleicht schon kompromitiert und der Hinweis wandert direkt an den Bösewicht? usw. usw. usw…

Diese Probleme soll dieser RFC möglichst einfach erschlagen. Es gibt ein textfile mit dem Namen security.txt unter der jeweiligen Domain im Pfad .well-known, diese ist nach Möglichkeit noch gpg cleartext signiert und beinhaltet alle nötigen Informationen.

Als kleine Beispiel: https://www.kernel-error.de/.well-known/security.txt

Es gibt sogar noch ein kleines Tool zum kreieren des Textfiles: https://securitytxt.org/

Da ich selbst sehr oft vor dem Problem stehe eine saubere Kontaktadresse zu finden, begrüße ich diesen RFC natürlich sehr!

Viel Spaß!

Fragen? Einfach melden.

XenServer mit Nagios überwachen

27. März 2012 / / Keine Kommentare

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Die hier beschriebene Nagios-Überwachung bezieht sich auf XenServer 6.x/7.x. Wer heute Virtualisierung überwachen will, sollte sich Proxmox VE oder XCP-ng anschauen.

Das folgende habe ich auf den Citrix XenServer in Version 5.6SP2 bis 6.2.0 anwenden können.
Im Grunde geht es darum auf dem „freien“ Citrix XenServer nrpe (Nagios Remote Plugin Executor) zu installieren um diesen mit Nagios auf einfache Weise überwachen zu können. Natürlich bietet der Cirtix XenServer ebenfalls die Möglichkeit ihn per SNMP zu überwachen und diese Version zu zu bevorzugen…. Für das eine oder andere Script ist die Ausführung per nrpe denn noch einfacher und schneller umzusetzen, als per snmp. Denn noch bitte beachten… Diese Version ist zwar absolut funktionsfähig und fast gefahrlos für das System, denn noch ist es „hereingefummelt“ und muss nach Versionsupgrade wieder (passend für die jeweilige Version) eingespielt werden. Die eigentliche Nagiosanbindung soll hier nicht Thema sein. Beispiele dazu kann man gerne bei mir erfragen.

So dann wollen wir mal:

Ich habe eine -schlechte- Angewohnheit. Ich erstelle immer gerne im Root das Verzeichnis 001 um dort meine Daten „herum zu würfeln“.

$ mkdir /001
$ cd /001

Im Grunde basiert der Citrix XenServer auf Redhat Linux/Fedora… Also können wir für diesen Fall auch die (Extra Packages for Enterprise Linux) epel nutzen.

$ wget http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
$ rpm -hiv epel-release-5-4.noarch.rpm
$ sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/epel.repo

So und schon sollten wir die zusätzlichen Pakete nutzen können. In diesen findet sich sinnigerweise auch direkt nrpe, was wir gleich installieren:

$ yum install --enablerepo=epel nrpe
$ chkconfig nrpe on

Das chkconfig nrpe on sorgt dafür dass der Service direkt beim Start des Systems mitgestartet wird. Wichtig ist nun noch die passenden Löcher in die Firewall des XenServers zu schießen. Sonst läuft zwar der Dienst, wir bekommen von außen aber keine Verbindung. Hier muss nur in der folgenden Datei eine Zeile ergänzt werden:

$ nano -w /etc/sysconfig/iptables
…..
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5666 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
….

Damit wären wir schon feritg. Natürlich sollte man nun noch die Nagios Plugins installieren, Programme und Temperaturen von Festplatten oder IPMI auszulesen.

$ yum install --enablerepo=epel nagios-plugins hddtemp ….

Für IPMI (Intelligent Platform Management Interface) müssen ggf. noch die nötigen Kernelmodule geladen werden:

$ modprobe ipmi_devintf
$ modprobe ipmi_si

Konfigurieren lässt sich nrpe nun wie bekannt über:

$ nano -w /etc/nagios/nrpe.cfg

Die Konfiguration von nrpe und Nagios ist aber unabhängig von der Installation auf dem XenServer.

Ich habe gerade den Hinweis bekommen, dass es helfen könnte wenn ich hier erwähne dass man sich die Nagios Plugins noch zusätzlich installieren muss. Dieses Stimmt natürlich. Ich habe mir mit der Zeit einen Satz recht weit „angepasste“ Nagios Plugins zusammengestellt. Diese schiebe ich mir oft (unter Berücksichtigung der Abhängigkeiten) einfach passend hin und her kopiere. Vielleicht ein Grund warum ich das -vergessen- habe zu erwähnen.

Siehe auch: Citrix XenServer Updates manuell über Bash installieren, Citrix XenServer local storage größer >2TB, XenServer Linux Softwareraid

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

20. August 2009 / / Keine Kommentare

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.

Wlan-Sicherheit

20. August 2009 / / Keine Kommentare

Veraltet: Dieser Beitrag stammt von 2009 und beschreibt WEP-Cracking mit einem Sharp Zaurus. WEP wird seit über einem Jahrzehnt nicht mehr eingesetzt, WPA2/WPA3 sind Standard. Die Konzepte (Monitoring, Deauthentication, Handshake-Capture) gelten grundsätzlich noch, die gezeigten Tools und Hardware sind aber veraltet.

Wie finde ich heraus ob mein Wlan sicher ist? (Bilder werden beim Anklicken gross.) Hier möchte ich die möglichen „Angriffsmethoden“ zu einem Wlan beschreiben. Am Ende wird jedem Sysadmin dann selbst auffallen, welche Bereiche man am besten wie schützen sollte. Es kommt immer wieder vor, dass Angestellte in der Firma einen AccessPoint aufstellen. Dieses ohne den Admin darüber zu informieren. Was natürlich ein grosses Sicherheitsproblem ist. Daher werde ich zum Anfang erst einmal beschreiben, wie es überhaupt möglich ist ein Wlan zu finden. Alle meine Beschreibungen werden sehr grob ausfallen. Wer sich wirklich mit diesem Thema beschäftigen möchte sollte sich besser selbst mit den Einzelheiten auseinandersetzen. Anhand folgender Ausrüstung, welche ich selbst besitze, werde ich die Beschreibung und meine Beispiele machen. Sharp Zaurus PDA for WLAN security testing Um mich nicht schon beim Suchen mit einem grossen und auffälligen Notebook herumschlagen zu müssen habe ich den Sharp Zaurus SL-5500G mit einer SanDisk CompactFlash 802.11b Low Power Wireless LAN Card. Die Wlan Karte braucht sehr wenig Strom und hat einen Prism II-Chip verbaut. Will man eine Wlan-Karte, welche ohne Probleme mit Linux zusammenarbeiten, sollte man auf diesen Chip achten. Mit Hilfe von meinem kleinen Zaurus kann ich nun sehr bequem und unauffällig durch die Gegend laufen und nach WLANs ausschau halten. Habe ich dort mit Hilfe vom Wellenreiter ein Funknetzwerk gefunden, bekomme ich gleich einige wichtige Informationen. Diese helfen mir dann dabei das Wlan einzuordnen. Hat man ein Netz gefunden, welches interessant ausschaut (meist schon an der SSID zu erkennen), ist es natürlich angenehmer mit einem Notebook zu arbeiten. Auch die Möglichkeiten sind hier grösser. Jetzt gibt es aber wieder Probleme. Mit einem Notebook in der Hand fällt man auf. Man muss sich also in eine Ecke verdrücken. Meist leidet der Empfang darunter. Sitzt man im Auto schirmt das Metall sofort alles ab. Darum gibt es so etwas: WLAN antenna for extended signal reception Links ist ein Standfuss mit Magnet. Dieser hält auch bei 50km/h noch auf dem Autodach. Auf diesen wird nun die Antenne (Mitte) geschraubt. Dieses kann man nun ohne Probleme in die Orinoco Gold PCMCIA-Karte (rechts) stecken, hier ist auch ein Prism II Chip verbaut. Fertig….. Der Empfang ist einfach nur geil. Egal wo man nun genau sitzt! Jetzt fehlt nur noch ein Notebook. Notebook running WLAN security tools Ich nutze ein Fujitsu Siemens LifeBook E 7110! Linux arbeiten mit allen Komponenten in diesem Notebook ohne Probleme und gebastel zusammen. Um Funknetzwerke zu finden, muss die Wlan-Karte in den Monitor Mode gesetzt werden. Im Monitor Mode nimmt die Karte alle Packet an. Egal aus welchem Netz sie kommen und egal für wen sie bestimmt sind. Der Standart Linux-Kernel kann die Karte nicht in den Monitor Mode setzen. Dieser muss also gepatch werden oder es muss ein passendes Kernelmodul erstellt werden. Am einfachsten geht es so: 0. Mit iwpriv schauen ob der eigene Kernel vielleicht schon gepatcht wurde! 1. Quellen des aktuellen Kernels installieren. 2. gcc installieren. 3. Die aktuelle Konfiguration des Kernels ins root der Kernelquellen legen. Unter Suse: zcat /proc/config.gz > .config Als Root unter /usr/src/linux 4. Saug dir hier die Datei orinoco-0.13e-SN-5.tar.bz2 5. Datei schön entpacken! 6. Als Root-User folgendes im root des Kernelmodules tippern: make modules; make install 7. alle Dateien mit der Endung ko in /lib/modules/dein-aktueller-kernel/drivers/net/wireless kopieren. Vorher Sicherung davon machen, da du einiges überschreiben musst! 8. Neustarten oder die Module entladen und laden. Jetzt sollte nach der Eingabe von „iwpriv“, beim Teil der Wlan-Karte der Monitor Mode auftauchen. Um mit dem Notebook nun nach Wlans zu suchen, nutzt man am besten das Programm Kismet. Kismet wireless network scanner interface Dieses sollte vorher noch konfigurieren werden;-). Es gibt unter /etc/kismet/ die Datei: kismet.conf. In dieser müssen wir zwei Änderungen vornehmen. Beim Punkt „suiduser=“ tragen wir hinter dem = unseren Usernamen ein mit dem wir auf der Linux Kiste arbeiten. Am Punkt „source=“ tragen wir hinter dem = folgendes ein: orinoco,eth1,orinocosource Wobei wir eth1 natürlich gegebenenfalls gegen unsere Wlan-Karte austauschen! Ein „sudo kismet“ in der Userkonsole sollte nun das Programm starten und sogleich nach Netzen suchen. Haben wir eines gefunden und wollen erst einmal nachschauen, was genau dort durch die Gegend fliegt. Brauchen wir dazu ein Programm mit dessen Hilfe wir den Datenstrom auslesen können. Dieses erledigt Ethereal super. Später ist es auch drin, mit diesem Programm sehr komplexe Filterungen auf den Datenstrom anzuwenden. Da wir aber nur die Daten annehmen können welche auf unserem Channel gesendet werden. Betreibt Kismet Channelhopping. D.h.: Kismet springt im ms. Takt vom Einen in den Anderen Channel. Wenn wir einen konstanten Datenstrom mitlesen wollen, ist das scheisse! Wir können dann ja nur die Daten mitlesen, wenn wir auch gerade im passenden Channel sind. Daher beenden wir Kismet und setzen die Karte von Hand in den Monitor Mode und den passenden Channel. Dieses geht als User-Root so: iwpriv eth1 monitor 1 1 eth1 ist in diesem Fall die Wlan-Karte, mit monitor 1 sagen wir das der Monitor Mode gestartet werden soll (mit iwpriv eth1 monitor 0 würden wir ihn also wieder beenden) und die letzte 1 gibt den Channel an, in welchem die Karte gesetzt werden soll. Ethereal network traffic monitor capturing packets Ethereal kann nun mit den im Bild angezeitgen Optionen gestartet werden. Nun würde Ethereal JEDES Datenpaket welches im Channel 1 durch die Gegend fliegt auffangen und speichern. Sollte auf dem AccessPoint eine Mac-Adressenfilterung eingerichtet sein, so müssen wir uns um diese nicht weiter kümmern. Wir versuchen uns ja nicht am AP anzumelden, sondern hören ja einfach nur zu. Interessant wird es erst, wenn das Netzwerk die Daten verschlüsselt überträgt. Wir bekommen zwar immer noch alles, können damit aber nichts mehr anfangen. Es ist aber Möglich WEP-Verschlüsselungen aufzubrechen, den Schlüssel zu errechnen. AirSnort WEP key recovery tool AirSnort ist ein Programm welches genau das macht. Es kann die Karte in den Monitor-Mode packen. Wenn vom User gewünscht auch gleich noch in den passenden Channel. Ab diesem Zeitpunkt sammelt Airsnort die verschlüsselten Packete. Bei einer 128 Bit WEP Verschlüsselung muss es ca. 6 Millionen Pakete sammeln. Das liegt daran, dass für die WEP Verschlüsselung nur ein begrenzter Zufallszahlenraum zur Verfühgung steht. Nach ca. 6 Millionen Paketen wiederholen sich in jedem Fall Teile. Mit diesen kann AirSnort nun rechnen. Hat AirSnort den Schlüssel erfolgreich errechnet, tragen wir ihn einfach mit iwpriv bei unserer Wlan-Karte ein und schon kann es weiter gehen! WEP Verschlüsselungen mit einer Stärke von 256 Bit sind im Vergleich noch sehr sicher. Es würde eine sehr lange Zeit dauern die notwendigen Pakete zu sammeln. Leider arbeiten kaum Karten mit 256 Bit WEP Schlüsseln. Es gibt auch eine neue Methode: WPA… WPA gilt bisher als sicher. Ich stufe mein Wlan immer noch als ein feindliches Netz ein. So behandelt es auch meine Firewall und so sollte es jeder Admin behandeln. Es ist und bleibt wohl noch über lange Zeit ein grosses Sicherheitsproblem. Genauere Fragen zu diesem Thema beantworte ich gerne per 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 nicht auf unfreundliche und ungenaue Fragen antworten. KEINER hat ein Recht drauf von mir Support zu bekommen!!

Mailserver

20. August 2009 / / Keine Kommentare

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

 

 

Dieses soll eine kleine Beschreibung über die Gründe, die eigentliche Installation
und Einrichtung meines privaten Mailservers 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 Proxy und Firewall sind andere
Projektbeschreibungen zu finden.

Die Hauptgründe für die Einrichtung des MTA sind also folgende:
– Zentraler Check der E-Mails auf Viren
– Zentraler Check der E-Mails auf Spam
– Einfachere Einschränkung der Bandbreite (damit eine E-Mail nicht die Internetverbindung lahmlegt.
– Keine zusätzliche Software auf den Clients
– Interner schneller E-Mail Verkehr, auch mit sehr grossen Daten

Alle E-Mails von externen Usern werden über Fetchmail vom Postfach des jeweiligen
Providers abgeholt. Werden dann sofort vom AntivirMailgate auf Viren überprüft
und müssen dann einen genauen Check durch Spamassassin über sich ergehen lassen.
Ist die E-Mail virenverseucht, bekommt der Postmaster (also ich) eine genaue Information
über den Virus, den Absender und den Empfänger der E-Mail. Der Absender und der
eigentliche Empfänger bekommt eine kurze Nachricht darüber, dass die E-Mail nicht
weitervermittelt wurde und mit welchem Virus diese E-Mail verseucht war. Sollte die E-Mail
als Spam klassifiziert werden wird vor den Betreff der E-Mail das Wort *****SPAM*****
geschrieben, ein kleiner Bericht angefertigt und diesem dann die eigentliche E-Mail
angehängt. Das ganze wird im Postfach des Empfängers abgelegt. So kann dieser
über seinen E-Mail Client die vermeintlichen Spam E-Mails entsprechend seiner Wünsche
weiter sortieren oder gar löschen. Da die vermeintliche Spam E-Mail dem Bericht
angehängt wird, hat er aber immer die Möglichkeit die E-Mail noch einmal zu
begutachten. Es könnte sich ja auch im eine wirkliche E-Mail handeln. Ist die E-Mail
aber virenfrei und kein Spam wird sie einfach im Postfach des Users abgelegt.

Alle E-Mails von den internen Clients durchlaufen die gleiche Routine bis zu einer
bestimmten Stelle. Ist die E-Mail für einen User bestimmt, der auch auf dem Mailserver
existiert, so wird die E-Mail direkt in dessen Postfach abgelegt und muss nicht erst durchs
Internet wandern. Somit ist auch bei 15 MB (1und1) nicht schon Schluss, sondern er wird an
den maximal möglichen Angaben des MTA gemessen.
Sollte die E-Mail für einen User ausserhalb des MTA bestimmt sein, wird sie an den MTA
des ISP weitergeleitet.

So nun aber zur Konfiguration des Ganzen. Konfigurationspunkte, welche ich aus privaten
oder sicherheitstechnischen Gründen lieber nicht öffentlich preisgeben
möchte, habe ich etwas umgeschrieben oder unter den Tisch fallen lassen.

Fangen wir mit der Konfiguration von Fetchmail an. Ich habe mir unter /etc/ eine
Datei mit dem Namen fetchmail.conf angelegt. Diese Datei sollte nach Möglichkeit
nur vom User root und dem User zu lesen sein, der für den Fetchmaildienst verantwortlich
ist. Denn in dieser Datei stehen die Zugangsdaten zu allen E-Mailpostfächern des ISP bzw.
E-Maildienstanbieters im Klartext. Durch einiges herumprobieren habe ich herausgefunden, dass
es bei einer ADSL-Leitung ganz sinnvoll ist alle 320 Sekunden nach neuen E-Mails in den
Postfächern des ISP zu schauen. Zwar blockiert sich Fetchmail nicht selbst, da wenn
Fetchmail gerade mit dem E-Mailchecken beschäftigt ist startet es sich nicht einfach
noch einmal parallel neu aber wenn man die Zeit unter 320 Sekunden setzt kommt es vor dass
der ISP meint es seien jetzt mal zu viele Anmeldungen in zu kurzer Zeit auf das Postfach
und dieses dann einfach mal für ein paar Minuten oder gar Stunden sperrt. Nimmt man
über 320 Sekunden muss man einfach zu lange auf E-Mails warten, da man ja auch wieder
die Zeit mitberechnen muss, die Fetchmail fürs abrufen der E-Mails braucht!

Ich starte fetchmail per init script im runlevel 3 mit dem Befehl:

fetchmail -d 320 -f /etc/fetchmail.conf

 

Die Option d startet fetchmail als Deamon im Hintergrund und zwar alle 320 Sekunden
(dafür die 320). Mit der Option f gebe ich fetchmail die zu nutzende Konfigurationsdatei an.
Die Konfigurationsdatei kann man in mehreren Arten formatieren. Ich habe mich für die
unten angezeigte Art entschieden. Da ich E-Mails von verschiedenen Servern abholen muss
und es so am übersichtlichsten finde. Es muss aber jeder für sich entscheiden
welche ihm besser gefällt. Ich beschränke mich hier aber auf die von mir genutzte Art.

############ /etc/fetchmail.conf # Anfang ############
set postmaster "postmaster"
set bouncemail
set no spambounce
set properties ""

poll pop.gmx.net with proto POP3
user 'info@gmx.net' there with password 'eienei' is 'peter1' here options fetchall
user 'info@gmx.li' there with password 'sksieneu' is 'klaus' here options fetchall

poll pop.1und1.com with proto POP3
user 'pt3732737' there with password 'safadsfg' is 'maus' here options fetchall
user 'pt302020' there with password 'aerfe' is 'peter1' here options fetchall

poll pop.t-online.de with proto POP3
user '000835444444444444400001' there with password '23424364' is 'bilder' here options keep
user '000835888888888001' there with password '334524364' is 'hund' here options keep
############ /etc/fetchmail.conf # Ende ############

 

Wie man sehen kann stehen in den ersten 4 Zeilen ein paar, selbsterklärende Angeben
für Fetchmail. Das Wort poll sagt Fetchmail: „Achtung, aber hier bezieht sich alles
auf den nachfolgenden Server!“ im ersten Fall also auf pop.gmx.net. With proto POP3 gibt
Fechtmail dann noch das zu nutzende Protokoll für die übertragung an. Bei mir in allen
Fällen pop3. in der nächsten Zeile werden Fetchmail nun die Daten für die einzelnen,
auf diesem Server zu überprüfenden, Postfächer übergeben. Hinter user folgt in
Hochkomma der Username für das Postfach beim ISP. there with password braucht normalerweise
auch schon keine genaue Beschreibung mehr. Hier wird in Hochkomma halt das zugehörige Passwort
für das Postfach angegeben. Direkt dahinter taucht is auf. Hinter is wird in Hochkomma nun der
Unix-Username des Benutzers auf dem lokalen MTA angegeben, in wessen Postfach die abgerufenen
E-Mails einsortiert werden. Der Punkt options fetchall weist Fetchmail an alle E-Mails erst vom
Server herunterzuladen und dann dort zu löschen. Es gibt natürlich auch die Möglichkeit
dieser dort liegen zu lassen und nur die Kopien herunterzuladen. Dafür ist die Option keep
zu setzten, was in den letzten beiden Zeilen der Konfigurationsdatei zu sehen ist. Einem
lokalen User kann natürlich auch mehr als ein externes Postfach zugeordnet werden. Dieses
ist in Zeile 7 und 12 zu sehen. Die Konfigurationsdatei sollte sich ohne grosses Denken
sofort verständlich lesen lassen. Fetchmail lässt sich auch dazu überreden die
E-Mails verschlüsselt vom ISP abzuholen. Genaue Informationen gibt es bei mir oder
am besten mit dem Befehl: man fetchmail

Um die E-Mails nun auf dem lokalen System zu bewegen und auch an Spamassassin weiterzugeben,
nutze ich das Programm Procmail. Diese benötigt eine eigene Konfigurationsdatei. Diese
habe ich in /etc/ angelegt und procmailrc genannt. 

############ /etc/procmailrc# Anfang ############
PATH=$HOME/bin:/usr/bin:/usr/local/bin:

####################
# AntiSpam Section #
####################
:0 hbfw
| /usr/bin/spamassassin -P
############ /etc/procmailrc # Ende ############

 

Der Aufbau ist so simpel und kurz… Da spare ich mir jede Erklärung. Sollten noch
Fragen da sein: Googeln oder Mailen.

Beim Programm Spamassassin wird es schon wieder interessanter. Es braucht natürlich
auch eine Konfigurationsdatei. Diese ist bei mir unter: /etc/mail/spamassassin zu finden
und nennt sich local.cf

############ /etc/spamassasin/local.cf # Anfang ############
# How many hits before a message is considered spam.
required_hits 5.0
rewrite_header Subject *****SPAM*****
# Encapsulate spam in an attachment
report_safe 1
# Use terse version of the spam report
use_terse_report 0
# Enable the Bayes system
use_bayes 1
# Enable Bayes auto-learning
auto_learn 1
# Enable or disable network checks
skip_rbl_checks 0
use_razor2 1
use_dcc 1
use_pyzor 1
# Mail using languages used in these country codes will not be marked
# as being possibly spam in a foreign language.
ok_languages all
# Mail using locales used in these country codes will not be marked
# as being possibly spam in a foreign language.
ok_locales all
############ /etc/spamassasin/local.cf # Ende ############

 

Auch hier sind die Angaben selbsterklärende und schon in der Konfigurationsdatei
beschrieben. Hier taucht erst der Parameter auf, dann eine 0 für deaktiviert, eine
1 für aktiviert oder eine genauerer Angabe zum Parameter. Wenn eine E-Mail mehr als
5.0 Punkte bekommt wird sie als Spam klassifiziert. Spamassassin ist in der Lage
selbstständig zu lernen. Bis es das Filtern von Spam richtig beherrscht sollte man
den Wert vielleicht auf 4.0 oder 4.5 setzten. Hier sollte man ein bischen mit den Werten
herumprobieren.

Jetzt werden die E-Mails also schon mal auf Spam überprüft und sie werden auch
zwischen MTA, in meinem Fall Postfix, usw. herumgereicht. Die E-Mails sollen nun noch auf
Viren getestet werden. Dies sollte aber so passieren, dass keine E-Mail sich am Virenscanner
vorbei schleichen kann. Ich nutze das AntivirMailgate dafür. Dieses stellt einen eigenen
SMPT-Server und lauscht, anstelle von Postfix, auf dem TCP Port 25. Mit den passenden Regeln
in der Firewall (Firewallprojekt) müssen nun alle E-Mails im ganzen Netzwerk hier durch.

Damit das AntivirMailgate auch wirklich so arbeiten muss man natürlich noch ein paar Sachen umstellen..
Im Ordner /etc/ liegt die Datei services. Dort sollte man folgende beiden Einträge hinzufügen:

antivir 10024/tcp #Port for avgated
smtp-backdoor 10025/tcp #Port for postfix backdoor

 

Jetzt können einige Programme das ganze auch etwas übersichtlicher in den logs usw.
aufschlüsseln und wir können mit der Konfiguration des Mailgates fortfahren. Im
Ordner /etc/ sollte die Konfigurationsdatei avmailgate.conf liegen. In dieser müssen
nun diese beiden Einträge eingegeben werden, bzw. die Kommentarzeichen angepasst werden.

ListenAddress localhost port antivir
ForwardTo SMTP: localhost port smtp-backdoor
Der erste Eintrag gibt dem Mailgate an auf dem gerade in den services angegebenen Port zu arbeiten.
Zeile zwei sagt dem Mailgate wohin er die E-Mails nach dem Testen weitergeben soll. Wie man sieht
taucht hier wieder smtp-backdoor auf. Will man sich den Eintrag in /etc/services sparen kann man hier
natürlich dann auch die Ports eintragen. Das ganze kann ich aber nicht empfehlen.

Nun sind noch zwei kleine änderungen an Postfix zu machen. Im Ordner /etc/postfix/ gibt es
die Datei master.cf

In dieser sind folgende änderungen zu machen:

# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (50)
smtp inet n ­ n - - smtpd
localhost:smtp-backdoor inet n ­; n - - smtpd -o content_filter =

 

Mit diesen änderungen sagt man Postfix das es selbst die Finger von den ankommenden E-Mails
lassen soll. Dieses soll ja unser Mailgate erledigen 🙂 Es sollte aber darauf geachtet werden dass,
das erste Zeichen in der Tabelle kein Leerzeichen und kein Tab ist. Sonst gibt es einen Fehler und
man suchst sich Stundenlang tot (ja, es ist mir passiert!).

Zum Schluss nun nur noch folgendes in die Datei main.cf im Ordner /etc/postfix/ packen:

#AntiVir Einbindung
content_filter = smtp:127.0.0.1:10024

 

Jetzt läuft dann auch schon unsere Virenprüfung. Wie man jetzt genau das Programm Antivir
und welche Zusatzoptionen man nun noch beim Mailgate macht, ist wieder so eine Sache mit dem Probieren.
Ich gebe natürlich auch gerne dabei noch eine Hilfestellung. Nur sollte man es selbst
schon einmal ausprobiert haben.

Was fehlt nun noch? Genau die Konfiguration des MTA (Postfix). Sonst geht ja schon alles…
Du solltest sicher gehen das du sasl libs usw. installiert hast. Sonst kommt am Ende die Meldung das
der Service nicht zur Verfügung steht (sobald du versuchst eine E-Mail an deinen ISP weiter zu
schicken). Genau so wichtig ist auch ein installierter popd, welcher auf Port 110 lauscht. Sonst
ist es Essig mit dem Abrufen der E-Mails vom Server.. Hier habe ich in den Anfängen auch
schon mal etwas länger grübeln dürfen.

Ich will alle E-Mails für externe User über den Mailserver von 1und1 schicken. Der ist
über den DNS-Namen smtp.1und1.com zu erreichen. Um E-Mails über den verschicken zu
können muss ich mich dort anmelden. Daher brauche ich dort einen Usernamen und ein Kennwort,
diese habe ich ja automatisch, sobald ich dort eine E-Mail Adresse besitze. Ich habe also im
Ordner /etc/postfix die Datei sasl_passwd angelegt. Die Datei hat folgenden Inhalt:

############ /etc/postfix/sasl_passwd # Anfang ############
smtp.1und1.com pt3333333-3:3333333
############ /etc/postfix/sasl_passwd # Ende ############

 

In diese Datei kommt zuerst der Server um den es sich handelt. Er muss genau so geschrieben
werden wie später der relay host in der postfix Konfiguration. Hier also smtp.1und1.com! Nun folgt
eine Leerzeile und dann pt3333333-3 dieses ist der Username für die Anmeldung am Mailserver des ISP.
Direkt dahinter kommt ein „:“! Dieses gibt an dass hier der Username endet und das zugehörige Passwort
beginnt. In unserem Fall 3333333! Plöp… Das war es auch schon. Man sollte nie vergessen aus diesen
Dateien, auch access und alias.. bla, eine Datenbank zu erstellen. Sonst ist man schon wieder seinen Fehler
am suchen! Das geht mit postmap /pfad/Dateiname

Im gleichen Ordner finden wir nun die Datei access. In dieser sollte man erst mal alle Einträge
auskommentieren. Nur dieser darf drinbleiben:

127 RELAY

 

Das sagt Postfix nun folgendes: Nur E-Mails die von einer IP Adresse kommen welche mit 127 beginnt werden
überhaupt angenommen und weiterverarbeiten. Da die 127..bla für die localhost Geschichte gedacht
ist werden jetzt erst mal nur E-Mails vom eigenen Host angenommen und verarbeitet. Ich habe bei mir
mehrere Netze aber alle beginnen mit 192.168.! Daher schaut meine Datei am Ende so aus:

127 RELAY
192.168 RELAY

 

Hat man nur ein Netz, sagen wir mal 192.168.50.0, dann sollte man das natürlich auch so angeben.
Damit haben wir schon mal sichergestellt, dass keine scheiss Spamer unseren schönen Server als
„offenen relay host“ nutzen können. SEHR WICHTIG!! Gut, speichern und raus.. Was haben wir
vergessen? Genau postmap :-)…

Jetzt schauen wir uns im gleichen Ordner mal die Datei aliases an. In dieser sollte schon so einiges
an Usernamen stehen. Las diese bitte auch erst mal so, es sei denn du weisst was du tust! Der Aufbau ist
aber ganz simpel. Links steht der Aliasname und rechts der wirkliche Username im lokalen System. Möchte
ich also das alle E-Mails die an peter-hat-es-dicke@mailserver.de gesendet werden, dem lokalen User
peter1 zugeteilt werden dann trage ich folgendes ein:

peter-hat-esdick: peter1
Das Spielchen kann ich mit so vielen User- und Aliasnamen machen wie ich Lust und Zeit habe.

Da gibt es nun aber noch eine interessante Datei mit namen canonical! In dieser steht meist nur
auskommentierter Krims. Der Sinn der Datei ist aber folgender. Ist mein Username auf dem lokalen
System hanz, meine E-Mail Adresse aber wurst und ich schicke z.B.: über die Konsole eine E-Mail
ab. So wird als Absender folgendes angegeben:

hanz@mailserver.de

 

Tja, die Adresse gibt es nicht oder gehört nicht mir. Ist so also schon mal scheisse. Wenn
ich aber nun in die Datei cononical folgendes eintrage:

hanz wurst@mamama.de

 

Wird immer, sofern nicht anders vom Mailclient oder ähnlich angegeben, mein Absender auf
wurst@mamama.de gesetzt. Toll nicht?
So, alles schön gespeichert und auch jeweils an postmap gedacht? Sehr gut! Dann schauen wir uns
mal die Datei main.cf an. Ja, die ist schön voll 🙂 Wir sausen daher mal direkt ans Ende der
Datei. Hier tippern wir nun folgendes ein:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relayhost = smtp.1und1.com
smtp_sasl_security_options = noanonymous
smtp_always_send_ehlo = yes
message_size_limit = 1024000000
mailbox_size_limit = 1024000000
myhostname = mailserver.de
smtpd_banner = $myhostname ESMTP (S-wie-Sicker)

 

Dann schauen wir zuerst die ganze Datei durch ob wir nicht damit gerade doppelte
Einträge gemacht haben. Interessant hierbei ist natürlich nur der Teil links
vor dem „=“! Sollten wir doppelte haben, kommentieren wir diese oben aus. Jetzt ganz
schnell wieder runter ans Ende!

smtp_sasl_auth_enable sagt Postfix das wir uns am Mailserver vom ISP anmelden müssen,
smtp_sasl_password_maps sagt Postfix mit welchen Zugangsdaten das ganze passieren soll und
relayhost sagt welcher Host überhaupt der Mailserver unseres ISPs(oder sonst wer) ist.

smtpd_banner verändere ich nur, damit nicht jeder sofort sehen kann, mit welchem SMTP-Server
er sich gerade bei mir unterhält. So hat ein Angreifer es etwas schwerer Sicherheitslöcher
zu nutzen. Da er ja erst mal keine Ahnung hat welche es in diesem System gerade gibt.

mailbox_size_limit gibt die maximale Grösse der Usermailboxen auf dem lokalen System an.
message_size_limit die maximale Grösse der E-Mails, die ein lokaler User verschicken kann.
message_size_limit sollte sinnvollerweise nie grösser als mailbox_size_limit sein.

Tja, das war es dann auch schon.

–==Ende==–

 

 

 

Proxy Server

20. August 2009 / / Keine Kommentare

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.

BF2: Mehr Speed für besseres Gaming-Erlebnis

20. August 2009 / / Keine Kommentare

Veraltet: Battlefield 2 wurde 2014 von EA abgeschaltet. Die hier beschriebenen Netzwerk-Tweaks sind nicht mehr relevant.

Moin moin…

Ich habe hier mal ein paar Tipps zusammengetragen, die dabei helfen BF2 das Ruckeln abzugew?hnen.

Sollte noch jemand ein paar mehr haben, wird sich wohl jeder ?ber eine Erweiterung des Posts freuen, oder?

Um Missverst?ndnisse aus dem Weg zu r?umen, gleich etwas vor weg.
– Ich habe BF2 auf meinem System unter C:GAMESBattlefield2 installiert. Alles wird sich also auch auf diesen Pfad beziehen.
– Alles l?uft auf meinem System so schon l?nger und ist von mir daher auch ausgiebig getestet.
– Alles ist sauber. D.h.: keine dieser Einstellungen verst??t gegen Regeln!

1. Die Anwendung frei stellen!

Geht einfach hin und benennt eure bf2.exe in bf2speed.exe um. Das ist auch schon alles (nein keine Änderungen in der Reg. usw..). Warum das in den meisten F?llen hilft dem ganzen etwas mehr Performance zu geben kann ich auch nicht genau sagen. Im Internet gibt es da mehrere „Ideen“ zu. Irgendwie h?ngt es wohl mit den Nvidia und Ati Treibern zusammen. Denen ist die BF2.exe bekannt. Man kann ja in den Treibereinstellungen bestimmte Profile f?r Anwendungen hinterlegen. Daher muss die bf2.exe dem Treiber ja auch bekannt sein. Die Treiber checken also st?ndig ab die Anwendung l?uft und reagieren irgendwie drauf. Das ganze Spielchen ben?tigt aber ungew?hnlich und unn?tig viel Systemleistung. Also umbenennen!

2. BF2 mit einer hohen Priorit?t starten!

Euer tolles OS vergibt an jede Anwendung eine Priorit?t. Grob vergleichbar mit einem Krankenwagen. Der hat auch eine hohe Priorit?t. Er kann ?ber rote Ampeln fahren, darf heizen wie Sau und jeder muss erstmal auf ihn warten und ihm Platz machen. So klappt das auch mit euren Anwendungen.

Ihr k?nnt jetzt nach jedem Start von BF2 im Taskmanager die Prio. hoch setzten, ich finde das aber affig. Es geht auch einfacher. Folgende kleine Stapelverarbeitungsdatei nimmt euch die Arbeit ab.

Geht in euer BF2-Homeverzeichniss (bei mir C:GAMESBattlefield2) erstellt dort mit rechte Maustaste  Neu  Textdatei eine neue Textdatei. Diese benennt ihr nun in bf2.cmd um. Achtet darauf das ihr auch den Dateipr?fix txt in cmd ?ndert!!!

Nun k?nnt ihr mit: rechte Maustaste auf bf2.cmd  Bearbeiten den Inhalt festlegen. Der sollte so ausschauen:

Rem Datei Anfang
cd /d “ C:GAMESBattlefield2″
start /high bf2speed.exe +menu 1 +fullscreen 1
Rem Datei Ende

Jetzt k?nnt ihr von eurer bf2.cmd eine Verkn?pfung auf dem Desktop erstellen oder wo ihr sie sonst braucht. Immer wenn ihr nun BF ?ber diese Datei startet l?uft es automatisch mit einer hohen Priorit?t d.h.: ihr habt bei eurem Audi 100 gerade das Blaulicht eingeschaltet!

3. Die Punkbusterchecks einschr?nken.

Im normalen Betrieb checkt euer toller Punkbuster alle 60 Sekunden eure Dateien auf der Festplatte. Habt ihr wenig RAM, nicht gerade die schnellste HDD oder sonst was dann kann das schon mal zu lags f?hren oder halt zu Performanceeinbr?cken. Das kann man aber ?ndern!

Logt euch auf einem Ranked-Server ein, auf dem das Spiel auch l?uft (also nicht „Das Spiel startet wenn sich.. nur um sicher zu gehen!) dann geht in die Konsole. Tippert mal pb_sleep rein! Jetzt wird euch die aktuelle Einstellung angezeigt und auch der erlaubte Rahmen (20 – 500). Warum also nicht den Punkbuster anstelle aller 60 Sekunden alle 500 Sekunden mal die Dateien pr?fen lassen? Daher direkt den n?chsten Befehl nachwerfen:
pb_sleep 500 (zwischen pb_sleep und 500 ist 1 Leerzeichen)

Fertig ist…. Damit dass jetzt nicht jedes mal gemacht werden muss noch schnell folgendes hinterher:

pb_writecfg

Geil wa?

4. Die Shader und bla Optimierung

Bei jeder Änderung der Grafikeinstellungen unter BF oder im System, bei jedem Treiberupdate oder jedem Patch werden die Shader usw.. ganz oder zum Teil neu an das System und dessen Leistungsm?glichkeiten angepasst!

Leider gibt es da ein kleines Problem… Habt ihr zuf?llig im Hintergrund den Antivirus laufen lassen oder Winamp oder ein Video oder kopiert gerade ne Datei oder sonst was… Hat das nat?rlich Auswirkungen auf die Leistung. Zu dem bekommt es BF2 auch einfach hin und wieder nicht mit das etwas ge?ndert wurde oder beim stundenlangen anpassen der Shader fliegt ihr als Idler vom Server, wobei der Vorgang dann unsanft abgebrochen wird. Was nun?

Grafikeinstellungen ?ndern und hoffen das BF2 es merkt…. Die Idee ist gut, leider wird bei so etwas aber nicht alles neu optimiert sondern nur Teile und bei unserem Gl?ck nicht die Teile, die wir brauchen!

Was also tun?

Ganz einfach! Geht mal unter C:Dokumente und Einstellungen[euer Username]Eigene DateienBattlefield 2modsbf2

Dort findet ihr einen Ordner mit dem Namen: cache

L?scht diesen einfach mal. Jetzt stellt ihr euer ganzes System genau so ein wie ihr auch sp?ter zocken wollt. Logt euch in BF2 ein und starte mal ein Singelplayer Spiel… Nun werden ALLE Einstellungen neu angepasst. Ihr verliert aber keine Daten und auch nicht euer Sound, Grafik, Kontroll und bla Einstellungen….

5. Datei und Druckerfreigabe

Was das ist muss ich wohl nicht erl?utern. Braucht ihr das wirklich? Ja.. manche brauchen es andere aber nicht.

Daher sollten diese es dann auch deaktivieren. Warum? Tja… es werden immer zu Nachrichten an das Netzwerk geschickt. Es wird Leistung und Bandbreite f?r diese Dinge reserviert. Hier und da h?ngt dann noch die Windows-Firewall mit drin usw. usw… Die Leistung brauchen wir aber eher zum zocken, also aus damit!

Start  Einstellung  Netzwerkverbindungen  rechte Maustaste auf die genutzte LAN-Verbindung  Eigenschaften  Hacken bei Datei- und Druckerfreigabe… weg und wieder mit OK raus. Fertig!

Ich habe da auch noch etwas f?r Leute mir zwei physikalischen Festplatten. Das tipper ich dann aber mal erst auf Anfrage, ok?

So long…

DAVfs2 und GMX: WebDAV unter Linux einrichten

19. August 2009 / / Keine Kommentare

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.

« Ältere Beiträge

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑