Schlagwort-Archive: firewall

IPCop is back

ipcopisback

Es war nicht mehr auszuhalten mit IPFire. Das Ding frisst sich bei mir innerhalb weniger Tage fest und dann ist man nur noch am Proxy-Cache leeren, URL-Filter neu starten und rebooten, in der Hoffnung, dass danach das Netz wieder performant läuft. Außerdem bekomme ich die Logik der Firewall nicht in meinen Kopf. Egal welches Netzsegment ich für welche Uhrzeit oder welchen Dienst sperre … entweder läuft gar nix mehr im ganzen Haus oder alles flutscht durch.

Jetzt hab ich mir wieder einen IPCop installiert und muss sagen: Die Installation von IPCop 2.x hat sich gegenüber 1.x nicht geändert – man fühlt sich sofort zu Hause. URL Filter und BOT sind mit an Bord und tun auch, was man einstellt. Und das Netz im Haus? Fühlt sich nicht nur schneller an, ist auch messbar flotter. Außerdem sind die Sperrmeldungen von IPCop einfach schön 😉

GnuPG, S/MIME, Thunderbird und Firewalls

Ich selbst bevorzuge für die Verschlüsselung von E-Mails GnuPG. Ich brauch da keine Infrastruktur Dritter und das gefällt mir. Einmal eingerichtet läuft das über Jahre. Einfach so. Ohne Kosten.

Für S/MIME spricht jedoch, dass der Standard von viel mehr MUAs unterstützt wird und dass die Handhabung oft einfacher ist. Kein zu unterschätzendes Argument, wenn man eine ganze Redaktion zu versorgen hat, die Frickeln „doof“ findet und von Windows über Apple bis Linux alles (un-)mögliche als Betriebssystem nutzt.

Ein Prüfstein war für mich diese Woche die Handhabung von GnuPG und S/MIME, wenn man mit seinem Laptop hinter der schulischen Firewall hockt, bei der nur Port 80 und Port 443 offen sind und man deswegen auf Webmail angewiesen ist. Thunderbird kommt hier schlicht nicht ins Netz.

Was dann?

S/MIME

Im Webmailfenster (wir nutzen EGroupware) auf speichern klicken.

Auf die EML Datei doppelt klicken – der lokale Thunderbird macht die Datei auf, entschlüsselt diese und fertig.

Versenden von verschlüsselten Nachrichten ist dann kein so ein großer Spaß mehr.

Man verfasst die Nachricht im Thunderbird und speichert diese im Ordner „Entwürfe“ ab. Dann klickt man diese rechts an und speichert diese über den entsprechenden Eintrag im Kontextmenü auf dem Desktop als EML.

Diese EML kann man dann als Anhang an eine Mail dran hängen, die man über den Webmailer verschickt. Beim Empfänger wird der Anhang entschlüsselt angezeigt – die Mail mit dem Anhang oben, der einst verschlüsselte Anhang unten (ähnlich wie bei einer Weiterleitung).

GnuPG

Die Nachricht – und hier nur den Nachrichteninhalt – per Copy and Paste in einen lokalen Texteditor werfen und als irgendwas.asc speichern.

Dann über das Kontextmenü (oder per Doppelklick – je nach Konfiguration) der Datei z.B. mit KGpg (je nach Desktop) öffnen und die Passphrase eingeben. Die neu erzeugte, entschlüsselte Nachricht im Editor lesen.

Das Schreiben von Nachrichten erfolgt ebenfalls im lokalen Texteditor. Man speichert die Datei lokal ab, verschlüsselt den Inhalt (Kontextmenü der Datei) und kopiert diesen aus der neu angelegten Datei mit der Endung asc wieder in den Webmailer zurück.

Und nun?

Das einfache Lesen von S/MIME-verschlüsselten Nachrichten unter den genannten Bedingungen wird in der Redaktion sicherlich gut ankommen. Ich selbst finde weiterhin den Weg für Lesen und Schreiben bei GnuPG sympathischer. Das ist zwar in beiden Fällen fummelig – aber einheitlich, unterliegt einer Logik, einer Vorgangsweise und nicht derselben zwei.

Eine berechtigte Frage ist natürlich, wie oft so was vorkommt und ob man nicht schlicht warten kann mit dem Lesen und Schreiben verschlüsselter Nachrichten, bis man wieder zu Hause / im Office ist.

Ach ja – getestet habe ich mit Textmails. Wie sich das mit HTML Mails und Anhängen anfühlt … die Tests stehen noch aus.

SmoothWall

… unser IPCop ist nach mehreren Jahren Arbeit heute Morgen verschieden. Egal was ich mach – booten tut die Kiste nicht mehr. Die Probleme mit dem DHCP Server des Cops waren wohl nur der erste Gruß aus dem Grab.

Ich bin dann, weil der IPCop 2.0 mit 2.6er Kernel immer noch Beta ist, auf Smoothwall Express umgestiegen. Wie vom IPCop gewohnt – auch hier lässt sich ein URL Filter mit Zugriff auf die Shallalist und der Advancedproxy nachinstallieren und eine Funktion wie Block Outgoing Traffic ist schon in der Basisinstallation mit an Bord.

Bisher lässt sich die „neue“ Firewall ganz gut an: 512 MB SDRam auf einem P 3 mit 450 Mhz reichen locker. Womit ich im Moment allerdings noch zu Kämpfen habe, ist die Oberfläche. So altbacken der IPCop auch aussah – ich fand mich schneller auf ihm zurecht.

Dafür hat Smoothwall mehr bells and whistles – z.B. sich in Echtzeit verändernde Balkengrafiken zum Netzwerkverkehr. Sieht cool aus, braucht aber eigentlich keiner.

Smoothwall überzeugt mich im Moment eher dadurch, dass eine ganze Reihe von Tools mit an Bord sind, die ich auf dem IPCop gelegentlich schon vermisst habe: locate ist ebenso anwesend wie eine echte crontab oder top. Außerdem liegen die Konfigurationsdateien meist da, wo man diese nach Linux Filesystem Hierarchy auch erwartet bzw. wo diese auf vielen anderen gebräuchlichen Distris auch liegen. Lediglich die Start-Stop Skripte scheinen etwas verteilt in der Gegend herumzu liegen – clustern aber hier:

/usr/bin/setuids/restartdhcp
/usr/bin/setuids/restartdnsproxy
/usr/bin/setuids/restartntpd
/usr/bin/setuids/restartsnort
/usr/bin/setuids/restartsquid
/usr/bin/setuids/restartssh
/usr/bin/setuids/restartupnp

Mehr hierzu gibt es da.

dhcp trouble

Meinem IPCop schienen die IPs ausgegangen zu sein und er weigerte sich, einem neuen Gerät eine IP aus der Liste der „verfallenen dynamischen Zuordnungen“ zu geben – warum auch immer.

Also bearbeitete ich auf dem IPCop die Datei

/var/state/dhcp/dhcpd.leases

und löschte eine (der nur scheinbar freien) IP händisch heraus, dann klappt wieder alles: Einstöpseln und das Neugerät bekommt einen Platz im Heimnetz.

Quelle: Hier gefunden und hier wird ausgeführt, dass das keine gute Idee ist.