Firewalls sind sinnlos aber...

[mclien]

Präambel: ich mag mich hier an vielen Stellen irren und an vielen auch nur Stümperwissen habe, dennich ist mir etwas aufegfallan, immer wenn es um firewalls geht.
Alle Fragen und Threads scheinen mir eine Variante dieses Statements zu enthalten (das ja sicher hochgradig korrekt und begründbar ist)
"Firewalls sind nutzlos, konfiguriere lieber dein System sicher"
Leider geht aber dann meist die zusätzliche Information nicht über ein "achte auf keine unnötigen offenen ports" (o.ä.) hinaus.
Tatsächlich vermisse ich dann eigentlich immer die Hinweise, wo man denn nun Weitere INformationen dazu finden kann, um Dinge zu verstehen.
Wie zum Beispiel unterscheide ich (mein Rechner), wenn ein http Packte bei mir ankommt, ob das nun eines ist das ich angefordert habe oder nicht (da scheint ja nunmal auf den ersten Blick der Mechanismus "established" bei Firewalls sinnvoll). Das kann ich ja kaum dadurch verhindern, dass ich den empfangenen port einfach zumache (und wenn wie/wo mache ich das nochmal).
iptables Erklärungen finde ich durchaus zuhauf im Netz, aber "So konfiguriere ich meine ports, wenn ich auf den 32c3 gehe" vermisse ich dann doch (oder bin zu blöd diese zu finden).
Also wie sind all die Leute die mir (ganz ehrlich) wissenstechnisch wieder mal voraus sind an das Wissen gekommen ihr System so zu konfigurieren, dass ihr euch ohne Firewall sicherer seit?
(Bitte keine Polemik o.ä. in meinen Beitrag interpretieren, ich habe das echt noch nicht rausgefunden...)

[mat6937]

Wie zum Beispiel unterscheide ich (mein Rechner), wenn ein http Packte bei mir ankommt, ob das nun eines ist das ich angefordert habe oder nicht (da scheint ja nunmal auf den ersten Blick der Mechanismus "established" bei Firewalls sinnvoll). Das kann ich ja kaum dadurch verhindern, dass ich den empfangenen port einfach zumache (und wenn wie/wo mache ich das nochmal).

Wenn Du z. B. einen lauschenden Port 80 (Server) hast, dann musst Du nichts anfordern, denn Du stellst ja zur Verfügung.

Wenn Du keinen lauschenden Port (Server) hast, dann hast Du auch keinen empfangenden Port, für Datenpakete mit dem syn-Flag (state NEW) und so musst Du auch nichts zumachen.

EDIT:

BTW: Betr. angefordertes Paket, kommt z. B. auf eine Anfrage mit "seq 6627291" (syn-Flag) eine Antwort mit "ack 6627292" (syn+ack-Flag).

EDIT 2:

Siehe auch: http://www.heise.de/security/meldung/Si ... 92257.html

[uname]

Ganz nutzlos sind Firewalls nicht. Das Problem sind eher die Anwender, die deren Sinn nicht verstehen. Natürlich kann man z.B. Firewalls nutzen, um Ports zu blockieren, die gar nicht offen sind. Man könnte z.B. anfangs alles zu machen. Und dann erlaubt man die einzelnen Verbindungen, die man tatsächlich benötigt. Das ist mühsam. Aber fehlerhafte Konfigurationen und auch einige Angriffe vor allem von innen können vielleicht verhindert werden. Im Firmenumfeld erscheint mir dieses Vorgehen sinnvoll gemäß dem Motto "doppelt hält besser".
Problem ist nur, dass das größte Scheunentor die Kommunikationen sind, die man erlauben will. Wer einen Webserver bereitstellt erlaubt z.B. die Ports 80/443. Nun fühlt sich der Admin sehr toll, da er vermeintlich alles unternommen hat. Nur im Endeffekt hätte er auch gleich seine Firewall deinstallieren können. Port 80/443 muss er erlauben und die gesperrten Ports werden wahrscheinlich sowieso nicht genutzt. Es ist somit viel wichtiger den Dienst (hier Apache2) korrekt zu konfigurieren und evtl. abzusichern. Auch muss man verstehen wie Kommunikationen funktionieren. Gleiches gilt für andere Kommunikationen. Z.B. kann man über SSH ganze VPNs tunneln wenn man Spaß daran hat. Umgekehrt kann man diese Möglichkeit serverseitig natürlich leicht deaktivieren.
Inwieweit Personal Firewalls besser sind weiß ich nicht. Im Windows-Umfeld funktioniert der Angriff (selbst hinter NAT) immer gleich. Schadcode wird vom Virenscanner nicht erkannt, Schadcode wird ausgeführt und kommuniziert per HTTPS mit seinem C&C-Server, um rückwärts als Fernwartungstrojaner zu arbeiten. Hier würde ich gerne mal wissen wie eine Personal Firewall das verhindert? Mindestens wenn der Schadcode den Browser als Kommunikationsweg nutzt weiß ich nicht wie die Personal Firewall den erlaubten HTTPS-Datenstrom und den verbotenen HTTPS-Datenstrom über den Browser unterscheiden will. Aber statt tolle Produkte auf den Markt zu werfen, sollten die Hersteller einfach mal schreiben wie die Software wirklich arbeitet. Sicherheit hat auch immer was mit dem Verständnis der Maßnahmen zu tun. Es ist ein Irrglaube zu behaupten, dass nur da etwas teurer ist auch deswegen z.B. sicherer sein muss.

[guennid]

Aber statt tolle Produkte auf den Markt zu werfen, sollten die Hersteller einfach mal schreiben wie die Software wirklich arbeitet.

+1!

So wie ich mclien verstehe, geht es ihm nicht um die "Absicherung" von Webservern, sondern um den Schutz seiner Tochter, bzw. deren Schleppi in Amiland (meine Annahme ist nicht diesem thread entnommen). Ich glaube kaum, dass auf diesem Schleppi eine Apache zum Einsatz kommen soll. Es scheint mir also also um eine recht banale und alltägliche Angelegenheit zu gehen: Kann man einen Linux-PC, auf dem weiter nichts als geschrieben, Videos angeschaut, gesurft und gemailt wird, durch eine sogenannte "Firewall" schützen?

Da ich auch zu diesen Leuten mit dem "Stümperwissen" gehöre, interessiert mich diese Frage schon jahrelang und mich beschleicht der Eindruck, dass auch hier im Forum auf Fragen nach dem Sinn und Unsinn einer persönlichen Firewall regelmäßig mit Kanonen auf Spatzen geschossen wird, will sagen, Szenarien konstruiert werden, die auf die reale Anfrage wenig oder gar nicht passen und insofern schlicht nicht hilfreich sind. (unames Beitrag ausdrücklich ausgenommen!).

Grüße, Günther

[uname]

Wenn dem so ist würde ich auf den Artikel https://wiki.ubuntuusers.de/Personal_Firewalls verweisen wollen. Er zeigt recht eindrucksvoll, dass Paketfilter eher unnötig sind.

Ich finde ein paar andere Dinge zur Absicherung viel wichtiger:

- Debian GNU/Linux - Betriebssystem (das erschlägt schon mal 99% aller Angriffsszenarien wie z.B. Windows-Trojaner)
- minimale Softwareauswahl, da jedes Programm Sicherheitslücken haben kann (ja ich weiß Gnome ist toll, aber vielleicht reicht ja Openbox)
- optimale Konfiguration von Programmen (vor allem die, die ins Internet kommunizieren wie z.B. Browser)
- regelmäßige Aktualisierung aller Pakete, Verzicht auf Fremdquellen
- Virenscanner halte ich unter Linux für unnötig
- Wissen über Sicherheit vermitteln

evtl.:
- Festplattenverschlüsselung
- BIOS-Passwort
- extrem alte Hardware (ohne UEFI/SecureBoot)
- nur Stable-Version (Jessie) verwenden
- geeignete Backup-Strategie
- clientseitig aktivierbare Fernwartungsmöglichkeit (z.B. auf Basis von Remote-SSH-Port-Forwarding) falls gewünscht
- Zwischenrouter zur Netztrennung (z.B. TL-WR802N -> WISP bei WLAN) vor allem bei dauerhaftem Standort
- Möglichkeit für VPN-Verbindungen über deutsche Server (selbst gehostet)

Insgesamt ist eine Firewall nur eine sehr kleine Komponente. Es ist wie beim Virenscanner unter Windows. Mag ja wohl wichtig sein. Nur sich drauf verlassen wäre fatal.


Vielleicht am Rande:
Einfach mal zwischen PC und Router einen Zusatzrouter z.B. auf Basis von Debian schalten und dann mal alle Kommunikationen z.B. mit wireshark mitsniffen. Sehr interessant die Ergebnisse für Windows, Linux und Android. Bei Windows und Android läuft so viel Zeug durch, welches man nie geblockt bekommt. Bei Debian braucht man nichts blocken. Da kommuniziert keine Client-Anwendung ungefragt mit dem Internet. Und wenn doch mal wird die Community wohl einen Bug-Report schreiben.

[mclien]

Erstaml schon mal Dank für die bisherigen Beiträge.
Dann will ich mal den Fall konkreter beschreiben. (übrigens wird das Szenario dann in GB sein).
Notebook ist ein HP etwas neuerer Generation mit:
-zumindest deaktiviertem UEFI
-es läuft ein aktuelles Jessie (wie sie dann updates einspielt wird ihr noch beigebracht)
-> alternative wäre die Frage, ob die security uodates automatisch einzuspielen in diesem Fall sinvoll ist (und wie man das dann macht)
-Software wird bei mir immer nach Bedarf installiert (also minmal Install von deb und nur installiert was nötig ist)
-Wesentliche Dinge: Fluxbox, Libreoffice, Icedove, Iceweasel, wicd (und was die jeweils MItbringen)
-keine Fremdquellen (ggf. multimedia für vlc)


-Platte ist verschlüsselt ( 37 Zeichen langes passwd)
-BIOS passwd schient mir dann zusätzlich nicht direkt zielführend( oder habe ich was vergessen/ übersehen)
-backup wird ein kleines shellscript werden auf eine ebenfalls evrschlüsselte externe hdd (eigentlich nur rsync)
-Zwischenrouter werde ich nicht mehr hinbekommen
-fernwartung wird eher nicht benötigt, denke ich (bzw. werden da alle Bemühungen warscheinlich am router der Gastfamiie eh enden)

Der Gedanke ist eigentlich eher: Meistens ist die Kiste hier im Netz, da habe ich den router nach aussen davor. Und statt jedesmal dienste umzukonfigurieren, wenn mal ausser Haus das Netz genutzt wird lieber die FW anschalten, um dann die wenigen ports zu blocken, die offen sind (was eigentlich nur 22 für ssh sein dürfte und je eben auch die die ich übershene habe)

[uname]

-es läuft ein aktuelles Jessie (wie sie dann updates einspielt wird ihr noch beigebracht)

schau dir evtl. unattended-upgrades an, auch brauchst du evtl. eine zusätliche Lösung für Flash

-fernwartung wird eher nicht benötigt, denke ich (bzw. werden da alle Bemühungen warscheinlich am router der Gastfamiie eh enden)

Für Fernwartung ist der Router der Gastfamilie irrelevant wenn es einen SSH-Server im Internet gibt bzw. dein Rechner zuhause per SSH erreichbar ist. Siehe z.B. http://debianforum.de/forum/viewtopic.php?t=138442

[TRex]

Interessant wirds, wenn du ausgehenden Verkehr filterst... aber das so weit einzuschränken, dass kein maximal mittelmäßig intelligenter Schadcode mehr raustelefonieren kann, ist mit viel Arbeit und Disziplin verbunden.

[wanne]

Noch als Ergänzung zu mat6937s Erklärung: Das glit nur für tcp Pakete. udp-Pakete haben weder Sequenznummern noch noch Syn und ack Flags.
Da wird entsprechend für jedes ausgehende Paket für eine gewisse Zeit gespeichert auf welchen Port es gieng und dann bei jedem eingehenden geprüft, ob es in der passenden Tabelle steht. Bei IPv6 ist der source Port btw. dann optional. Bin mal gespannt, wie sie es da dann machen.
Das machen sich viele Protokolle zu nutze. Da für Internettelefonie eingehende Anrufe ja durchaus gewünscht sind, nicht angeforderte Pakete aber oft gefirewalled werden, sendet man da einfach mal vorsorglich Pakete raus kommt dann irgend wann mal was wertet die Firewall das als angefordert.

Ich hatte auch relativ lange tinc laufen. Das macht das gleiche und verpackt dann darein verschlüsselt beliebige andere Pakete (VPN). Die Firewall hält dann jedes Pakte für von tinc angefordert.
Womit ich dann wieder voll bei unames Aussage bin:

Aber fehlerhafte Konfigurationen und […] können vielleicht verhindert werden. Im Firmenumfeld erscheint mir dieses Vorgehen sinnvoll gemäß dem Motto "doppelt hält besser".

Aber eben erstmal keine gezielten Angriffe. (Bzw. eher solche, die nur durch fehlerhafte Konfiguration ermöglicht werden.)
Leicht fehlerhaft konfigurierbare Software läuft aber eher nicht auf dem typischen Schleppi der Tochter.
Ausnahmen fallen mir mehr oder weniger 3 relativ bekannte ein. Aber allesamt bei weitem nicht typisch sondern das was man ganz selten doch mal findet:

• Windows XP macht freigaben wenn man auf öffentlich einstellt wirklich öffentlich. – Hängt die also ohne Firewall (oder NAT) ans Internet.
• Relativ viele Linux User haben die Vorzüge von ssh kennengelernt. Per default bietet der passwort authentifikation an. Meine login Passwörter sind aber alles andere als sicher genug, als das man die ans Internet stellen kann.
• Visual Studio hatte mal in irgend einer Version, die die Hilfe als Webseite auslieferte. Der mitgelieferte IIS stellte die Hilfe dann dem Internet zur Verfügung. Nu ist die Hilfe nicht geheim, trotzedem will man nicht wirklich einen völlig veralteten (Wer updatet Visual Studio schon regelmäßig. Das kostet ja sogar.) IIS am Internet stehen haben.

Ein lsof -i -stcp:LISTEN ist würde das aber alles anzeigen. IMHO um längen sinnvoller, als stundenlang irgend welche Firewalls zu konfigurieren.

Im Windows-Umfeld funktioniert der Angriff (selbst hinter NAT) immer gleich. Schadcode wird vom Virenscanner nicht erkannt, Schadcode wird ausgeführt und kommuniziert per HTTPS mit seinem C&C-Server, um rückwärts […] zu arbeiten.

Nicht nur Schadcode funktioniert so. Auch allerlei andere Software, an die Admin nicht so wirklich denkt, wenn er sagt, machen doch nur Web funktioniert auf die gleiche Art und weise Skype, Whatsapp, Windows Update...

Als letztes gibt es noch eine Sache wo Firewalls teils tatsächlich helfen. Und das sind Angriffe nach außen. Bei uns an der UNI ist der einzig legitime Mail-Server der der UNI. Spambots laufen entsprechend ins leere. Genauso dürfen viele Der Server einfach keine Webseiten aufrufen. DOS mit der dicken UNI-Leitung sind dann erstmal nicht.

[wanne]

Interessant wirds, wenn du ausgehenden Verkehr filterst... aber das so weit einzuschränken, dass kein maximal mittelmäßig intelligenter Schadcode mehr raustelefonieren kann, ist mit viel Arbeit und Disziplin verbunden.

Ich würde das eher für unmöglich betrachten. Vieles telefoniert mittlerweile über Tor. Und das bekommen nicht mal die Iraner zuverlässig gefiltert.
Das sieht für Server, die eine dedizierte Aufgabe haben etwas anders aus. Aber den privaten Laptop.
Alleine wenn Facebook tun soll musst du dank dauernd wechselnder Server mehr oder weniger allen verschlüsselten Verkehr akzeptieren. Und für dir FIrewall ist das halt verschlüsselter Verkehr des IE. Das ist genau das was auch die Trojaner machen. Weiter reingucken kannst du da nicht, solange du nicht de passende Verschlüsslung knackst. Und wenn du das kannst, hätte ich von dir gehört.

[uname]

Weiter reingucken kannst du da nicht, solange du nicht de passende Verschlüsslung knackst. Und wenn du das kannst, hätte ich von dir gehört.

Naja. Du kannst schon deinen Benutzern Fake-SSL-Zertifikate im Browser unterjubeln und aus der eigentlichen HTTPS-Verbindung zwischen Client und Server zwei Vebindungen nämlich zwischen Client und Proxy sowie Proxy und Zielserver machen. Da kannst du dann zwischendurch auch mal reinschauen. Auch hat TLS/SSL weitere Nachteile. Wenn du z.B. gleichzeitig Proxy-Systeme entwickelst und Zertifikate ausstellst (die Firma wollen wir mal nicht nennen) hast du einige Möglichkeiten.

[MSfree]

Naja. Du kannst schon deinen Benutzern Fake-SSL-Zertifikate im Browser unterjubeln und aus der eigentlichen HTTPS-Verbindung zwischen Client und Server zwei Vebindungen nämlich zwischen Client und Proxy sowie Porxy und Zielserver machen. Da kannst du dann zwischendurch auch mal reinschauen.

Nunja, wenn man als Anwender jede (Zertifikats)warnung einfach wegklickt, mag das funktionieren. SSL ist jedenfalls so aufgebaut, daß der Client mitbekommt, wenn man nicht mit dem Server sondern mit dem Proxy verbunden ist.

Was aber bei einem Proxy trotz Verschlüsselung funktioniert, ist die Filterung nach URLs, denn die werden im Klartext übertragen. So kann man über einen Proxy auch Facebook explizit aussperren oder zulassen.

Aber ich muß dem OP schon Recht geben, daß Firewalls im Sinne von apt-get install firewall und alles ist gut, Blödsinn sind. Das vermittelt nur das Gefühl von Sicherheit, ohne überhaupt auszusagen, um welche Art von Blockaden es sich handelt und welche Löcher notwendigerweise offen gelassen werden.

Eine Firewall ist ein Konzept und kein Softwarepaket, das man nur zu installieren braucht, ohne weiter nachzudenken. Sie kann auch nicht aus nur einem Paket bestehen, da gehört mehr dazu, wie z.B. ein Paketfilter, ein Webproxy und eventuell sogar ein Virenscanner, und das alles idealerweise selbst konfiguriert. Dann aber ist eine Firewall alles andere als sinnlos.

Ich würde trotz alles Probleme, die eine vorkonfigurierte "Firewall" (im Sinne von apt-get install firewall) mit sich bringt, den Rechner nicht statt dessen einfach offen lassen und "nur so wenig Dienste wie möglich" anbieten. Denn das So-wenig-wie-möglich-Konzept ist genauso utopisch wie apt-get install firewall. Die Debian Desktopinstallation bringt zahlreiche Netzwerkdienste mit, von denen der unbedarfte Nutzer nicht ahnt, daß sie da sind, und daß sie eventuelle Einfallstore darstellen. Wer seinen Rechner z.B. öfter mal mit seinem Smartphone "tethert", um ins Internet zu gehen, sollte zumindest eingehende Pakete filtern, die nicht im Sinne von iptabels ESTABLISHED,RELATED sind.

[schorsch_76]

Zu deinem Scenario: Tochter zu Besuch in GB bei einer Gastfamilie.

Der Worst Case ist also mit einem Besuch in einem Hotel Wifi zu vergleichen. Als ich vor einiger Zeit in Shanghai war und dort im Wifi war, hab ich einfach mal geschaut, was hier alles einprasselt und versucht eine Verbindung aufzunehmen. Das ist erschreckend. Auch in deutschen Hotels passiert das.

Für mich war hier das entscheidende, so schnell wie möglich in mein VPN reinzukommen. Hier gibt es meines Erachtens drei kritische Punkte:

• Authentifizierung mit dem Wifi. Meist ist das Webbasiert und unverschlüsselt. Hier kann im Browser Javascript und ähnliches ausgeführt werden das du nicht unter Kontrolle hast.
• Verbindungsaufbau mit deinem VPN. Hier muss zur maximalen Sicherheit kein PSK (Preshared Key) verwendet werden sondern Zertifikatsbasierte Authentifikation. Ein PSK könnte im Worst Case aus deiner Client.conf (openvpn) ausgelesen werden (Siehe erster Punkt) und dann ein MITM laufen.
• Der VPN Server muss auch den DNS setzen. Was nützt die Verbindung dann die Adressen über inen untrusten DNS aufgelöst werden selbst wenn die DNS Pakete über den VPN Server gehen, dann zum "bösen DNS" und dann die Antwort wieder durchs VPN zum Client?

Wenn dann das VPN steht sieht die Route dann so aus:

Zur VPN Server IP über wlan0. [3]
Alles andere über tap0 (VPN).
DNS gesetzt über VPN Server. [2]

Wie die anderen schon geschrieben haben lass keine Dienste laufen bzw so wenig wie möglich. Meist ist Debian in der Standardeinstellung schon ziemlich gut.

Festplattenvollverschlüsselung inkl. grub [1] wäre auch noch gut. Dann kann der Kernel und die Initrd nicht ausgetauscht werden. Dann ist ein "Evilmaid" Angriff nicht mehr ganz so einfach, aber immer noch möglich.

P.S.: Ich wünsche ihr/euch viel Spass

[1] http://www.pavelkogan.com/2014/05/23/lu ... ncryption/
[2] http://serverfault.com/questions/416708 ... ecific-dns
[3] wiki.openvpn.eu/index.php/OpenVPN-Syntax

[DeletedUserReAsG]

Die Debian Desktopinstallation bringt zahlreiche Netzwerkdienste mit, von denen der unbedarfte Nutzer nicht ahnt, daß sie da sind, und daß sie eventuelle Einfallstore darstellen.

Auch der unbedarfte Debiannutzer darf mit z.B. netstat nachschauen, und muss sich nicht auf seine Ahnung verlassen. Zumindest bei mir waren’s nicht „zahlreiche Netzwerkdienste“, die da mitgebracht wurden.

[MSfree]

[*]Verbindungsaufbau mit deinem VPN. Hier muss zur maximalen Sicherheit kein PSK (Preshared Key) verwendet werden sondern Zertifikatsbasierte Authentifikation. Ein PSK könnte im Worst Case aus deiner Client.conf (openvpn) ausgelesen werden (Siehe erster Punkt) und dann ein MITM laufen.

Die ca.crt, ta.key, client.crt und client.key sind in der openvpn.conf ebenfalls referenziert, könnte von dem bösen Skript also auch gefunden, ausgelesen und für MITM mißbraucht werden.

Wie die anderen schon geschrieben haben lass keine Dienste laufen bzw so wenig wie möglich. Meist ist Debian in der Standardeinstellung schon ziemlich gut.

Einspruch, Debian ist hier eben genauso schlecht wie Windows oder OS-X. In einer nichtvertrauenswürdigen Umgebung dürfen gar keine Dienste nach aussen offen sein. Selbst SSH ist ein mögliches Einfallstor, über das schon einmal ein von mir betreuter Router geknackt wurde, obwohl ich bei der Konfiguration nichts falsch gemacht hatte.

[MSfree]

Auch der unbedarfte Debiannutzer darf mit z.B. netstat nachschauen

Du glaubst wirklich, daß der unbedarfte Nutzer mit der Ausgabe von netstat etwas anfängt?

[DeletedUserReAsG]

Der unbedarfte Debiannutzer sollte das können. Ebenso, wie er sich darüber im Klaren sein sollte, dass er einen sshd nach dessen expliziter Installation seinen Wünschen gemäß konfigurieren sollte. Manch andere Distris/Systeme hingegen suggerieren dem unbedarften Distributions-/Systemnutzer, dass alles ootb korrekt und sicher wäre; in der Debiandoku bin ich bislang aber nicht auf solche Aussagen gestoßen – im Gegenteil, es wird ziemlich direkt auf das Securing-HowTo verwiesen.

[schorsch_76]

[*]Verbindungsaufbau mit deinem VPN. Hier muss zur maximalen Sicherheit kein PSK (Preshared Key) verwendet werden sondern Zertifikatsbasierte Authentifikation. Ein PSK könnte im Worst Case aus deiner Client.conf (openvpn) ausgelesen werden (Siehe erster Punkt) und dann ein MITM laufen.

Die ca.crt, ta.key, client.crt und client.key sind in der openvpn.conf ebenfalls referenziert, könnte von dem bösen Skript also auch gefunden, ausgelesen und für MITM mißbraucht werden.
...

Ja die werden referenziert und können gelesen werden. Aber: es wird über die CA geprüft das der Client auch von der RootCA unterschrieben wurde und damit ins VPN darf. Hier brauche und will ich keine öffentliche CA wie Verisign und co. sondern meine eigene CA. Denn ich will ja kontrollieren wer in mein VPN rein darf. Auch will ich sicher gehen dass ein "richtiger" Signing Mechanismus verwendet wird und auch ein starker Verschlüsselungsalgorithmus.

Der Angreifer hat eben keinen Zugriff auf den Private Key der CA mit dem das Clientzertifikat unterschrieben wurde. Wenn mir der Angreifer die Certs austauschen kann, hat er schon root Zugriff und nicht nur lesenden Zugriff wie ein User. Deshalb ist "normalerweise" auch die Rechte auf den Certs und der Config auf 0600. Wird das vergessen zu setzen, kann der User zwar im Zweifel den PSK lesen oder die Certs aber immer noch nicht austauschen. Hier greift die normale Linux Rechteverwaltung wieder.

[mclien]

Vielen Dank für die umfangreichen Infos.

Für das akute Szenario, lässt sich das aber doch recht gut einschränken.
alles was sie braucht hat sie lokal dabei, braucht also gar nicht in ein VPN.
Ihren user und ihre daten hat sie auf ihrer Platte (verschlüsselt). Mailabruf hat sie dann auch lokal.
Dann bekommt sie fürs backup eine verschlüsselte externe hdd.
Die lauschenden Dienste muss ich nochmal checken, aber das war nur ssh, meines Wissens. "Die" firewall ist keine vorgefertigte sache, sondern ein minimal script für iptables, das im wesentlichen alle verbindungen die reinkommen droped, ausser established, related.
Login am Router sicher nicht per webapp, sondern per wicd Config (SSID und passphrase/passwd).

das genaue firewallscript reiche ich heute abend noch nach.

EDIT:
liegt hier: http://nopaste.debianforum.de/39463
sieht aber verdächtig danach aus, als ob das irgendein basic script ist, dass ich auch hier aus dem Forum hatte

[spiralnebelverdreher]

-Platte ist verschlüsselt ( 37 Zeichen langes passwd)

Mit welchen Mitteln (LUKS, dm-crypt, ...) hast du denn die Platte verschlüsselt, dass du ein Passwort mit 37 Stellen als nötig erachtest? Zumindest bei LUKS wäre auch mit einem Viertel der Zeichen (solange die in keinem Wörterbuch stehen) ein Angriff sehr sehr aufwendig.

[mclien]

LUKS, denke ich. Was immer wheezy im debian installer anbietet.
37 zeichen: Wenn ich das jetzt noch wüsste. jedenfalls kann ich mir das deutlich besser merken als so manche kürzere Passwörter. (Meine Tochter auch).
oder soll ich besser diese passwort nehmen?
OK genau genommen, war das eher "viel ist gut" und das war halt eines, dass wir beide uns gut merken können.

[uname]

Sobald ein Passwort das Gehirn des Menschen verlässt ist es angreifbar. Bei deinem 37 Zeichen - Verschlüsselungspasswort ist der Missbrauch eher gering. Es auszuprobieren ist sinnlos und an das Passwort kommt man vor allem durch einen Keylogger, da bei der Eingabe keinerlei Netzwerkverbindung besteht. Sobald man das Passwort jedoch über irgendein Netzwerk überträgt ist eigentlich eher die Frage wo man es unverschlüsselt abgreifen kann. Denn dann ist die Komplexität unerheblich. Und ich rede nicht von trivialen Transportverschlüsselungen wie TLS/SSL. Was bringt das alles wenn der Webserver das Passwort unverschlüsselt entgegen nimmt oder es am Client unverschlüsselt eingegeben wird? Und selbst am SSH-Server der ja allgemein als ziemlich sicher angesehen wird, lässt sich mit strace leicht jedes Passwort mitsniffen. Warum sollte ich als Angreifer versuchen ein vermeintlich sicheres Passwort aus /etc/shadow zu hacken? Ich kann besser warten bis es jemand mal wirklich eingibt. Keine Trivialpasswörter zu verwenden macht nur Sinn wenn Angreifer ausschließlich irgendwelche Passwortdatenbanken analysieren. Da ist natürlich 12345 als Passwort nicht mehr ganz so gut geeignet.

[schorsch_76]

...
EDIT:
liegt hier: http://nopaste.debianforum.de/39463
sieht aber verdächtig danach aus, als ob das irgendein basic script ist, dass ich auch hier aus dem Forum hatte

Das ist ein Shell/init Script das wohl in den Systemstart eingebunden werden soll. Es macht alle Ports von Außen zu und erlaubt alle ausgebende Kommunikation. Da kann nicht viel schief gehen

[mclien]

Ah, sorry. Dass das ein initscript ist war mir schon klar (hatte ich nicht erwähnt, ich wollte nur betonen, dass ich das nicht allein erdacht habe..)

Wo ich immer ein bisschen am hadern bin ist, wo ich denn überall links anlegen sollte.

Von meinem Verständnis wären das:
/etc/rc2.d/<bevor das Netzwerk gestartet wird> (default runlevel von debian)
/etc/rc0.d/<nachdem das Netzwerk down ist>

was vergessen?

[wanne]

Du kannst schon deinen Benutzern Fake-SSL-Zertifikate im Browser unterjubeln und aus der eigentlichen HTTPS-Verbindung zwischen Client und Server zwei Vebindungen nämlich zwischen Client und Proxy sowie Proxy und Zielserver machen. Da kannst du dann zwischendurch auch mal reinschauen.

Und hast die Sicherheit von deinem System wirklich nachhaltig untaminiert. Ganz im Gegenteil hat Firefox beispielsweise seine Sicherheitseinstellungen wieder massiv zurückgefahren, damit solche dämlich Lösungen wieder funktionieren. Somit sind diese Systeme nicht nur für sich sondern für alle ein massives Sicherheitsproblem.
Der einzige Sinn von sowas ist dass mitarbeiter nicht so ohne weiteres mal auf Facebook surfen können, ohne erwischt zu werden.
VPNs kannst du damit trotzdem nicht unterbinden. Gibt mittlerweile welche, die über den Facebook-Chat funktionieren. Wenn du die blockst, encodier man halt mim Ave-Maria-Code. Den bekommst du dann wirklich nicht mehr gefiltert. (Esseiden du filterst auf Latein. Aber der lässt sich ja auch auf jede andere Sprache übertragen.)

Als ich vor einiger Zeit in Shanghai war und dort im Wifi war, hab ich einfach mal geschaut, was hier alles einprasselt und versucht eine Verbindung aufzunehmen. Auch in deutschen Hotels passiert das.

Ich habe im Leben noch nie gesehen, dass irgend welche andere Clients in einem WLAN was unlegitimes gamacht haben. Hier und da mal ein Torrent client, der fragt, ob das File, dass er da gerade zieht schon jemand anders im LAN hat und jede menge Windows systeme die im allgemeinen sowieso verbal inkontinet sind.
Das sind eher DNS-Server, vom Anbieter, die verfälschte (werbeversächte) ergebnise liefern oder Proxys wie dei von uname, die versuchen die Videoqualität bei youtube runterzusetzen.

versucht eine Verbindung aufzunehmen. Das ist erschreckend.

Der Kernel entpackt Pakete ja nur und kann mit den Inhalten (Außer bei ICMP (ping)) absolut nichts anfangen. Wenn sich da also kein programm gemeldet hat, dass explizit diesen Inhalt haben will, gibt es da gar keine andere Möglichkeit für den Kernel, als das einfach Wegzuwerfen. Was daran beängstigend sein soll, dass da ein paar Pakete reinkommen die instantan weggeworfen werden kann ich nicht sehen. (Genau aus dem Grund habe ich auch noch nie in WLANs irgend welche Angriffe mit dir als Verbindungen gesehen. Was soll irgend ein "Angriff" bi dem der Rechner eh nur einfach alle Pakete wegwirft.)
Womit wir bei der absoluten sinnlosigkeit von sowas hier angekommen sind:

"Die" firewall ist keine vorgefertigte sache, sondern ein minimal script für iptables, das im wesentlichen alle verbindungen die reinkommen droped, ausser established, related.

Ob mir meine Firewall oder mein Linux Kernel die passenden Pakete dropt ist völlig egal. Ganz im gegenteil schafft du dir einen weiteren Angriffspunkt: Die Firewall. Und dagegen gab es in der vergangenheit deutlich mehr angriffe. (Wen auch typischerweise nur DOS.)
Einzig wenn du expliziet ein Programm installierst, dass auf eingehende Verbindungen hört ändert sich was. Wenn du das machst, willst du ja aber vielleicht, das es tut… Wenn nicht – Deinstalliere es und bau keine Firewall davor.