Schlagwort: Email (Seite 11 von 11)

Mailserver

20. August 2009 / Sebastian van de Meer / 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 / Sebastian van de Meer / Keine Kommentare

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

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

Sollte jemand Fragen oder Anregungen haben, freue ich mich natürlich über jede
EMail. 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 EMail 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 ProxyServers 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 ProxyServer 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 ProxyServer 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 EMails 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 ProxyServer 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 ProxyServer Squid einzubinden muss die Datei vom SquidDeamon 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 kernelerror@kernelerror.de
emulate_httpd_log off
cache_mem 16 MB
ftp_user root@kernelerror.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 ProxyServer
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 EMail 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@kernelerror.de
Wird über Squid auf einen FTPServer zugegriffen gibt er diese EMailadresse 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 EMails. 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 wwwTeil 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:

SurfProtect verweigert den Zugriff.

SurfProtect erlaubt den Zugriff.

CAcert Nokia

19. August 2009 / Sebastian van de Meer / Keine Kommentare

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 Root Certificate</title></head><body><a href=“root.cer“>Installing Class1 PKI Key</a> <a href=“class3.cer“>Installing Class3 PKI Key</a> <a href=“https://www.kernel-error.de“>Und nun testen..</a></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.

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!

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 6858622] [Mobile: +49 0177 5995900] ] [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!

SSH/OpenSSH

19. August 2009 / Sebastian van de Meer / Keine Kommentare

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.

CAcert

19. August 2009 / Sebastian van de Meer / Keine Kommentare

Veraltet: CAcert hat es nie in die Browser-Truststores geschafft. Die CA existiert zwar noch, spielt aber keine praktische Rolle mehr. Dieser Beitrag ist nur noch als Zeitdokument interessant.

Jeder der etwas mit EDV vertraut ist, wird mir sicher zustimmen. Daten im Rechner oder aus dem Internet sind schön und gut. Nur sind sie auch wirklich vom Autor, welcher im Dokument steht? Sind die Daten vielleicht verändert worden? Unterhalte ich mich auch gerade wirklich mit dem Server oder hat mit ein Hacker über einen fake-dns auf seinen Server geleitet? Genau um solche Dinge sicher zu stellen, gibt es Zertifikate. Eine gute Möglichkeit für Privatleute oder kleine Firmen ist da CAcert.





CAcert:

CAcert ist eine gemeinschaftsbetriebene nicht kommerzielle Zertifizierungsstelle (Root CA), die kostenfrei X.509-Zertifikate für verschiedene Einsatzgebiete ausstellt. Damit soll eine Alternative zu den kommerziellen Roots CAs geboten werden, die zum Teil recht hohe Gebühren für ihre Zertifikate erheben. Die Dienstleistungen der CAcert sind allgemein. Jeder kann sich Zertifikate auf seinem Namen bzw. auf seinen Server ausstellen lassen, nachdem er seine Identität ausreichend belegt hat.

Zertifikate
Folgende Zertifikate und Signaturen werden angeboten:

Client-Zertifikate
Diese Zertifikate sind personalisiert, sie dienen zum Beispiel zum Verschlüsseln und Signieren von E-Mails und anderen Daten, aber auch Authentifikation an Servern oder zum Signieren von Softwarecode.

Server-Zertifikate
Server-Zertifikate stellen die Identität eines Servers sicher und dienen als Basis für verschlüsselte SSL/TLS-Verbindungen. Es gibt eine Bandbreite von Diensten, bei denen Server-Zertifikate zum Einsatz kommen. Dazu gehören u. a. HTTPS, FTP(S), SMTP(S), POP(S) und IMAP(S).

Signatur des PGP-Schlüssels
Man kann den eigenen PGP-Schlüssel zur Signatur einreichen. Die CAcert bestätigt dann die Identität des Schlüsselbesitzers.

Assurance / Identitätsprüfung
Um ein Zertifikat zu erhalten, muss man sich zunächst auf der Seite https://www.cacert.org/index.php?id=1 als Benutzer anmelden. Jedem Benutzerkonto sind Punkte (Assurance Points) zugeordnet, die auf verschiedenen Wegen von anfänglich 0 bis auf 150 Punkte erhöht werden können. Die Punkte geben an, wie genau die Identität eines Benutzers überprüft wurde (bis 100 Punkte) bzw. wieviele Punkte er beim Überprüfen der Identität eines anderen Benutzers vergeben darf (ab 100 Punkten).

Die Authentifikation der eigenen Identität gegenüber CAcert kann auf zwei Arten erfolgen:
Zum einen besteht ein Netzwerk aus Freiwilligen (Web of Trust), gegenüber denen sich der neue Benutzer ausweisen kann, um Punkte zu erhalten. Eine Liste der freiwilligen Assurer ist auf der Internetseite zu finden. Sie können maximal 35 Punkte vergeben. Bei besonderen Veranstaltungen wie z.B. Messen können Super-Assurer sofort die maximalen 150 Punkte vergeben.
Zum anderen sind ‚Vertrauenswürdige Dritte‘ (Trusted Third Parties) wie Notare zugelassen, die aufgrund ihrer Position (Beruf) die Identität des Benutzers bestätigen können. Hier können auch bis zu 150 Punkte erlangt werden.

Quelle: http://de.wikipedia.org/wiki/CAcert http://www.cacert.org/

Ich selbst bin auch ein solcher Assurer und kann die begehrten Punkte vergeben.
Interessierte schicken mir bitte eine kurze E-Mail. Dann können wir ein Treffen absprechen!

Wer sich für CAcert interessiert, sollte sich auch unbedingt den Beitrag: „StartSSL“ anschauen.

IPv6: Adressarchitektur, Autokonfiguration und radvd unter Linux

23. März 2003 / Sebastian van de Meer / Keine Kommentare

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 2¹²⁸ 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.