Suche
Kategorien
Getaggte Artikel
Impressum
FeM e.V.
Max-Planck-Ring 6d
98693 Ilmenau
Tel./Fax: +49 3677 691929
info@fem.tu-ilmenau.de
www.fem.tu-ilmenau.de
Vertretungs-
berechtigter Vorstand:
Vorsitzender:
Adrian Schollmeyer
Stellvertretender Vorsitzender:
Robin Lehmann
Schatzmeisterin:
Anna Brede
Stellvertretender Schatzmeister:
Maximilian Klook
Registergericht:
Amtsgericht Ilmenau
Registernummer: 120483
Datenschutzerklärung
Max-Planck-Ring 6d
98693 Ilmenau
Tel./Fax: +49 3677 691929
info@fem.tu-ilmenau.de
www.fem.tu-ilmenau.de
Vertretungs-
berechtigter Vorstand:
Vorsitzender:
Adrian Schollmeyer
Stellvertretender Vorsitzender:
Robin Lehmann
Schatzmeisterin:
Anna Brede
Stellvertretender Schatzmeister:
Maximilian Klook
Registergericht:
Amtsgericht Ilmenau
Registernummer: 120483
Datenschutzerklärung
Verwaltung des Blogs
Sunday, 24. November 2013
DNS mit DNSSEC absichern
DNS (Domain Name System) ist ein sehr wichtiger Bestandteil des Internets. Mit DNS finden unsere Browser heraus, welchen Webserver sie für eine Webseite kontaktieren müssen, und die Mailserver, an welchen Server Post gesendet werden soll. Auch viele andere Dienste wie beispielsweise Chat, Fernwartung, Spam-Erkennung oder VPN nutzen oft DNS, um die Adressen der jeweiligen Server heraus zu finden.
DNS hat viele Vorteile, darunter Lastskalierung und eine in weiten Teilen dezentraler Aufbau, jedoch auch Schwächen. Dazu zählt, dass die übertragenen Informationen nicht kryptografisch signiert sind - also Manipulationen nicht erkannt werden können. Manipulationen können dabei beispielsweise durch gefälschte Pakete, kompromitierte Nameserver oder Schadsoftware, welche Einstellungen auf AccessPoints und Routern verstellt, erfolgen. Mitunter passieren solche Manipulationen jedoch auch ganz offiziell und sind ggf. sogar erwünscht - beispielsweise wenn der Zugangsanbieter bei Tippfehlern den Browser automatisch auf eine Suche umleitet.
Mit DNSSEC wurde das DNS um krytografische Signaturen (Unterschriften) ergänzt, sodass interessierte Rechner überprüfen können, ob die erhaltenen Informationen korrekt sind. Dabei wurde das System abwärtskompatible gestaltet, sodass sich der Inhaber einer Domain auch dazu entscheiden kann, diese unsigniert zu lassen - beispielsweise weil es für seinen Anwendungsfall überflüssig ist. Möchte der Domaininhaber seine Domain jedoch signieren, benötigt er DNSSEC-fähige Nameserver, welche seine DNS-Einträge samt ihrer Signaturen verteilen.
Derzeit gibt es sehr wenige Anbieter (wenn überhaupt), welche DNSSEC-fähige Nameserver zur Miete anbieten. In der Folge muss jeder, der eine mit DNSSEC-signierte Zone betreiben will, sich nicht nur um die Erzeugnung der Signaturen und die Verwaltung der Schlüssel kümmern, sondern auch noch mehrere Nameserver entsprechend den Vorgaben der jeweiligen Registry vorhalten.
Für die FeM hat sich das neu gegründete Projekt DNS-Hosting das Ziel gesetzt, solche DNSSEC-fähigen Nameserver (für die Zone fem-net.de) zu betreiben. Dabei geht es explizit nicht darum, als Registrar tätig zu werden.
Seit der Umstellung auf die neue Verwaltungsinfrastruktur werden außerdem den Rechnern in der FeM Nameserver ausgeteilt, welche die DNSSEC-Signaturen überprüfen und weiterreichen, sodass auch andere Rechner in der FeM diese überprüfen können und Rechner, welche dies nicht können, dennoch keine gefälschten Antworten (sofern die Zone signiert war) erhalten.
DNS hat viele Vorteile, darunter Lastskalierung und eine in weiten Teilen dezentraler Aufbau, jedoch auch Schwächen. Dazu zählt, dass die übertragenen Informationen nicht kryptografisch signiert sind - also Manipulationen nicht erkannt werden können. Manipulationen können dabei beispielsweise durch gefälschte Pakete, kompromitierte Nameserver oder Schadsoftware, welche Einstellungen auf AccessPoints und Routern verstellt, erfolgen. Mitunter passieren solche Manipulationen jedoch auch ganz offiziell und sind ggf. sogar erwünscht - beispielsweise wenn der Zugangsanbieter bei Tippfehlern den Browser automatisch auf eine Suche umleitet.
Mit DNSSEC wurde das DNS um krytografische Signaturen (Unterschriften) ergänzt, sodass interessierte Rechner überprüfen können, ob die erhaltenen Informationen korrekt sind. Dabei wurde das System abwärtskompatible gestaltet, sodass sich der Inhaber einer Domain auch dazu entscheiden kann, diese unsigniert zu lassen - beispielsweise weil es für seinen Anwendungsfall überflüssig ist. Möchte der Domaininhaber seine Domain jedoch signieren, benötigt er DNSSEC-fähige Nameserver, welche seine DNS-Einträge samt ihrer Signaturen verteilen.
Derzeit gibt es sehr wenige Anbieter (wenn überhaupt), welche DNSSEC-fähige Nameserver zur Miete anbieten. In der Folge muss jeder, der eine mit DNSSEC-signierte Zone betreiben will, sich nicht nur um die Erzeugnung der Signaturen und die Verwaltung der Schlüssel kümmern, sondern auch noch mehrere Nameserver entsprechend den Vorgaben der jeweiligen Registry vorhalten.
Für die FeM hat sich das neu gegründete Projekt DNS-Hosting das Ziel gesetzt, solche DNSSEC-fähigen Nameserver (für die Zone fem-net.de) zu betreiben. Dabei geht es explizit nicht darum, als Registrar tätig zu werden.
Seit der Umstellung auf die neue Verwaltungsinfrastruktur werden außerdem den Rechnern in der FeM Nameserver ausgeteilt, welche die DNSSEC-Signaturen überprüfen und weiterreichen, sodass auch andere Rechner in der FeM diese überprüfen können und Rechner, welche dies nicht können, dennoch keine gefälschten Antworten (sofern die Zone signiert war) erhalten.
Sichere und anonyme eMail über TOR mit DNSSEC vereinfachen
Wie derzeit der Presse zu entnehmen ist, interessieren sich diverse Stelle nicht nur für die Kommunikationsinhalte sondern vor allem auch für die zugehörigen sozialen Netzwerke - also wer kommunziert mit wem und wieviel.
Nutzt man nun eine klassischen eMail-Provider, können diese Soziales-Netzwerk-Informationen - auch bei der Verwendung verschlüsselter eMails - dort gebündelt abgegriffen werden. Gleichzeitig sichert die Verwendung eines großen Providers bei der Überwachung der verschlüsselten Verbindung zum / zwischen Providern ein wenig die Privatssphäre, weil nur ersichtlich ist, dass mit/zwischen den Providern Daten ausgetauscht worden ist. Weiterhin ist für Otto-Normal-Angreifer auch über die Domain nicht sofort Name und Anschrift des Kommunikationspartners ersichtlich.
Möchte man nun die Zugriffsmöglichkeit des Providers beseitigen, läuft es darauf hinaus, entweder vor dem Provider seine Identität zu verbergen (was die meisten nicht erlauben), oder einen eigenen Mailserver zu betreiben. Allerdings erlauben viele TOR Exit-Nodes derzeit nicht die Kommunikation auf TCP Port 25 (SMTP), sodass die eMails darüber nicht unbeobachtet zugestellt werden können. Außerdem wäre in diesem Fall der Einsatz von TLS und Zertifikatsüberprüfung erforderlich, damit der Exit-Knoten nicht mitlesen kann - mit den ganzen Problemen, die sich bei der Überprüfung der Zertifikate ergeben.
Alternativ könnte man für eingehende Post den Mailserver als Hidden-Service im Tor-Netzwerk erreichbar machen [1] und sich so das TLS und die Zertifikatsüberprüfung ersparen. Dabei muss man aber unter Umständen darauf achten, dass nicht der Mailserver oder Client selbst schon zu viele Informationen über die Identität preis gibt, wenn die Identitäten dabei auch gegenseitig deheim gehalten werden sollen. Weiterhin kann die Adresse nur genutzt werden, wenn sowohl Empfänger als auch Absender über TOR eMails austauschen können. Zudem dürfte eine @<HiddenService>-eMail-Adresse schwer zu merken sein.
Um die Erreichbarkeit im Tor-Netzwerk zu vereinfachen, könnte man jedoch die .onion-Adresse des Hidden-Service als zusätzlichen MX-Eintrag ins DNS eintragen. Dann könnten alle Teilnehmer weiterhin die klassischen Domains verwenden, TOR-kompatible Systeme aber eine Zustellung mittels Tor-Netzwerk vornehmen, ohne dass nicht-TOR-fähige Systeme ausgeschlossen wären. Dabei wäre zu beachten, dass die Namensauflösung ebenfalls über Tor erfolgen muss und die Antwort mittels DNSSEC überprüft werden sollte, um Manipulationen und Abhörtätigkeiten auszuschließen.
Problematisch wird in diesem Zusammenhang die Spam-Erkennung anhand von IP-Blacklisten bezogen auf das einliefernde System. Dies ist jedoch auch schon mit IPv6-PrivacyExtension-Adressen der Fall und führt dazu, dass SPAM vermehrt mit anderen Methoden (Schlagworte im Inhalt, DKIM, gpg-Absenderprüfung) erkannt werden muss.
Um die Antworten des DNS mittels DNSSEC überprüfen zu können, sind DNSSEC fähige DNS-Server - sowohl bei der Bereitstellung der Zone als auch bei der Namensauflösung - erforderlich. Um die Bereitstellung von DNSSEC-signierten Zonen zu vereinfachen, wurde in der FeM das Projekt DNS-Hosting ins Leben gerufen, welches sich zum Ziel gesetzt hat, DNSSEC-fähige Nameserver u.a. für die Zone fem-net.de zu betreiben.
Um nun seinen eigenen Mail-Server anonym für den Empfang und Versand von Post zu erreichen, kann man auf dem ohnehin laufenden Tor-Client einen weiteren Hidden-Service einrichten und diesen den passenden Dienst bereitstellen lassen. Dessen Adresse schreibt man sich dann aber doch besser auf, um die eigene Anonymität beim Abruf der eMails nicht zu gefährden - andernfalls könnte der Zugangsanbieter wo möglich aus der verwendeten Domain auf die eigene Person schließen. Damit wäre jedoch noch nicht preis gegeben, wer mit wem kommuniziert hat.
Verwandte Ansätze:
[1] http://johannes.sipsolutions.net/Projects/exim-tor-hidden-mail?action=AttachFile&do=get&target=whitepaper.pdf
Nutzt man nun eine klassischen eMail-Provider, können diese Soziales-Netzwerk-Informationen - auch bei der Verwendung verschlüsselter eMails - dort gebündelt abgegriffen werden. Gleichzeitig sichert die Verwendung eines großen Providers bei der Überwachung der verschlüsselten Verbindung zum / zwischen Providern ein wenig die Privatssphäre, weil nur ersichtlich ist, dass mit/zwischen den Providern Daten ausgetauscht worden ist. Weiterhin ist für Otto-Normal-Angreifer auch über die Domain nicht sofort Name und Anschrift des Kommunikationspartners ersichtlich.
Möchte man nun die Zugriffsmöglichkeit des Providers beseitigen, läuft es darauf hinaus, entweder vor dem Provider seine Identität zu verbergen (was die meisten nicht erlauben), oder einen eigenen Mailserver zu betreiben. Allerdings erlauben viele TOR Exit-Nodes derzeit nicht die Kommunikation auf TCP Port 25 (SMTP), sodass die eMails darüber nicht unbeobachtet zugestellt werden können. Außerdem wäre in diesem Fall der Einsatz von TLS und Zertifikatsüberprüfung erforderlich, damit der Exit-Knoten nicht mitlesen kann - mit den ganzen Problemen, die sich bei der Überprüfung der Zertifikate ergeben.
Alternativ könnte man für eingehende Post den Mailserver als Hidden-Service im Tor-Netzwerk erreichbar machen [1] und sich so das TLS und die Zertifikatsüberprüfung ersparen. Dabei muss man aber unter Umständen darauf achten, dass nicht der Mailserver oder Client selbst schon zu viele Informationen über die Identität preis gibt, wenn die Identitäten dabei auch gegenseitig deheim gehalten werden sollen. Weiterhin kann die Adresse nur genutzt werden, wenn sowohl Empfänger als auch Absender über TOR eMails austauschen können. Zudem dürfte eine @<HiddenService>-eMail-Adresse schwer zu merken sein.
Um die Erreichbarkeit im Tor-Netzwerk zu vereinfachen, könnte man jedoch die .onion-Adresse des Hidden-Service als zusätzlichen MX-Eintrag ins DNS eintragen. Dann könnten alle Teilnehmer weiterhin die klassischen Domains verwenden, TOR-kompatible Systeme aber eine Zustellung mittels Tor-Netzwerk vornehmen, ohne dass nicht-TOR-fähige Systeme ausgeschlossen wären. Dabei wäre zu beachten, dass die Namensauflösung ebenfalls über Tor erfolgen muss und die Antwort mittels DNSSEC überprüft werden sollte, um Manipulationen und Abhörtätigkeiten auszuschließen.
Problematisch wird in diesem Zusammenhang die Spam-Erkennung anhand von IP-Blacklisten bezogen auf das einliefernde System. Dies ist jedoch auch schon mit IPv6-PrivacyExtension-Adressen der Fall und führt dazu, dass SPAM vermehrt mit anderen Methoden (Schlagworte im Inhalt, DKIM, gpg-Absenderprüfung) erkannt werden muss.
Um die Antworten des DNS mittels DNSSEC überprüfen zu können, sind DNSSEC fähige DNS-Server - sowohl bei der Bereitstellung der Zone als auch bei der Namensauflösung - erforderlich. Um die Bereitstellung von DNSSEC-signierten Zonen zu vereinfachen, wurde in der FeM das Projekt DNS-Hosting ins Leben gerufen, welches sich zum Ziel gesetzt hat, DNSSEC-fähige Nameserver u.a. für die Zone fem-net.de zu betreiben.
Um nun seinen eigenen Mail-Server anonym für den Empfang und Versand von Post zu erreichen, kann man auf dem ohnehin laufenden Tor-Client einen weiteren Hidden-Service einrichten und diesen den passenden Dienst bereitstellen lassen. Dessen Adresse schreibt man sich dann aber doch besser auf, um die eigene Anonymität beim Abruf der eMails nicht zu gefährden - andernfalls könnte der Zugangsanbieter wo möglich aus der verwendeten Domain auf die eigene Person schließen. Damit wäre jedoch noch nicht preis gegeben, wer mit wem kommuniziert hat.
Verwandte Ansätze:
- http://tormail.org/
- https://groups.google.com/forum/#!msg/alt.privacy.anon-server/75_ayzjJaeY/tn5QFr1isGoJ
- http://www.danner-net.de/om.htm
[1] http://johannes.sipsolutions.net/Projects/exim-tor-hidden-mail?action=AttachFile&do=get&target=whitepaper.pdf
Thursday, 14. November 2013
Großer Netzumbau am Uplink-Switch
Am Dienstag, dem 12.11.2013 trafen sich gegen 07:00 verschlafene FeM-Aktive um den großen angekündigten Netzumbau zu zelebrieren.
Nach etwas koffeinhaltigem Heiß- und zuckerhaltigem Kaltgetränk begab sich die Gruppe zum Haus M, um dem FeM-Netz um 07:30 durch das Herunterfahren von c-fem-1 (dem zentralen Router, aka "der cisco") den temporären Garaus zu machen.
Während die eine Hälfte nun damit beschäftigt war, den Ist-Zustand der Kabelage zu dokumentieren und dann den Cisco abzunabeln, bereitete ein weiteres Team den neuen Netzwerkschrank durch kleine Umbauten auf den Einbau des Routers vor.
Nach einer gefühlten Ewigkeit (gemessen: 1h10m) stand der Router an seinem neuen Platz, der Uplink ins Rechenzentrum nebst der ersten Verbindungen steckte und alles starrte gebannt die Konsole des Routers an.
Nach dem obligatorischen Umstecken (lechts und rings kann man nicht verwechseln!) konnte dann als erster Meilenstein das Studentenwerk wieder ans Netz genommen werden.
Zeitgleich zum Stecken der weiteren Verbindungen zum Cisco spaltete sich ein kleiner Trupp ab, um in den Betriebsräumen in den Wohnheimblöcken die nötige Steck- und Konfigurationsarbeit zu leisten.
Gegen 10:50 war die Arbeit im Haus M getan und gemeinsam wurden, unterbrochen von einer Mittagspause in der Mensa, in den letzten Blöcken die Uplinks konfiguriert und gesteckt. Leider gab es hier verschiedenste Fehlerquellen (kaputte Fasern zwischen den Häusern, fehlkonfigurierte Switche), was zu weiteren Wegen zwischen den Betriebsräumen führte. Gegen 16:00 stellte sich dann jedoch ein gewisser Erfolg ein und wir konnten schlussendlich in das FeM-Office zurückkehren.
Wieder bei koffeinhaltigen Heiß- und zuckerhaltigen Kaltgetränken wurde dann die getane Arbeit im Wiki dokumentiert und der Arbeitseinsatz beendet.
Was wurde erreicht:
-Wohnheim H, E, L und P mit 10 Gigabit/s angeschlossen (vorher 1Gigabit/s)
-Wohnheim I mit 3 Gigabit/s angeschlossen (vorher 1Gigabit/s)
-Leute (ohne Internet) zur direkten sozialen Interaktion gebracht
-Leute (ohne Internet) zum Lesen eines Buches gebracht
-Leute (ohne Internet) mit Frischluft vergiftet
-Leute (ohne Internet) zum Lernen gebracht
Wednesday, 13. November 2013
SEPA - der einheitliche europäische Zahlungsraum kommt.
Derzeit zahlt ihr euren FeM-Mitgliedsbeitrag mittels Überweisung oder Lastschrift. Die "normalen" Lastschriften werden jedoch Anfang des kommenden Jahres eingestellt, sodass wir bis dahin auf die Nutzung von SEPA-Lastschrift umstellen müssen. Überweisungen können - müssen jedoch nicht - noch bis vorr. 2016 funktionieren (abhängig von den Konditionen deiner Bank), indem deine Bank diese dann selbstständig in SEPA-Überweisungen umwandelt.
Was ändert sich dabei für euch?
- Aus Kontonummer und Bankleitzahl wird IBAN (Internation Bank Account Number) und BIC (Bank Identifier Code).
- Aus Abbuchungs-, Einzugs- oder Lastschrift-Ermächtigungen werden sogenannte SEPA-Mandate. Jedes Mandat hat eine eindeutige Nummer (Mandatsreferenz).
- Alle Abbuchungen werden euch einzeln oder gebündelt vorher angekündigt - mit konkretem Zahlungstermin. Bei der FeM wird dies per eMail passieren.
- In jeder Abbuchung wird die Gläubiger-Identifikationsnummer (CI), die Mandatsreferenz sowie eine eindeutige Zahlungs-Identifikationsnummer (optional) angegeben, mit der die Zahlungen eindeutig einer Firma oder Verein, einem Vertrag oder einem Vorgang zugeordnet werden können. Dies ermöglicht es eurer Bank, euer Konto besser gegen unbefugt Abbuchungen abzusichern und vereinfacht die automatisierte Verarbeitung von Zahlungen.
- Das SEPA-Lastschriftverfahren ist auch mit Konten von Banken im europäischen Ausland (SEPA-Zahlungsraum) möglich. http://de.wikipedia.org/wiki/Einheitlicher_Euro-Zahlungsverkehrsraum
Die neue IBAN (SEPA-Kontonummer) und BIC (SEPA-Bankleitzahl) sowie die Gläubiger-Identifikationsnummer der FeM findet ihr auf http://fem.tu-ilmenau.de/index.php?id=379.
Die Mandatsreferenz wird euch zusammen mit der Ankündigung der Abbuchung per eMail mitgeteilt.
Alle bestehenden Lastschrift-Ermächtigungen bleiben erhalten und werden von uns automatisch in SEPA-Mandate umgewandelt. Dies wird voraussichtlich am 5. Dezember 2013 passieren. Ab diesem Zeitpunkt werden wir für neue Mitglieder sowie bei der Änderung der Bankverbindung nur noch SEPA-Mandate akzeptieren, ihr könnte alte Formulare also entsorgen oder löschen. Die neuen Formulare gibt es ab dem 5. Dezember 2013 auf http://fem.tu-ilmenau.de/index.php?id=72 .
Für Fragen wende dich an admin@fem.tu-ilmenau.de oder nutze das Formular.
Geschrieben von Michael Braun
um
19:41
Friday, 1. November 2013
Anbindung Professor-Philippow-Str. erfolgt
Der Anschluss des Glasfaserkabels ist heute erfolgt und die Switche wurden eingerichtet.
Weitere Informationen für studentische Bewohner gibt es unter der Mailadresse admin@fem.tu-ilmenau.de
Weitere Informationen für studentische Bewohner gibt es unter der Mailadresse admin@fem.tu-ilmenau.de
(Seite 1 von 1, insgesamt 5 Einträge)