Messages

Sorry dass ich ggf. doof nachfrage, aber ist es wirklich ernst gemeint, dass die Weiterleitung auf den SIP Port und die Sprach/Fax Ports von ANY erlaubt werden :o
Das würde im Normalfall dazu führen, dass - so die Sense bei einem SIP Portscan irgendwem auffällt - man recht fix ungebetene Gäste hat die über einen telefonieren können - oder konfiguriert 1&1 seine FB so streng, dass das nicht möglich ist?

Grüße

@Oxy
Finde ich persönlich zu pessimistisch und wir/ich reden hier nicht nur von der Generation Ü40/50. Und die Social Media Generation (Y) ist durchaus in der Lage sowas wahrzunehmen. Wenn sie darauf keinen Bock hat ist das was anderes ;) Aber alle als hoffnungsloses Pack abzustempeln finde ich schon einen extrem pessimistischen Ausblick.

EDIT: Mich hier aber bitte nicht falsch verstehen. Ich bin auf jeden Fall gegen das Aufbrechen von SSL im Betrieb oder in der Firma, jedoch finde ich die Idee für Zuhause "ganz interessant", würde mir den Stress aber nicht machen wollen. :)

Gerade zu Hause finde ich es eben nicht wirklich sinnvoll, denn da ist Aufklärung das wirkungsvollste Mittel und da auch - zumindest in meinem Umfeld bislang - nie vergeudet gewesen. Selbst meine Eltern die auf Ende 60 zugehen, sind in der Lage zu bemerken, dass mit der Bankseite oder dem Zertifikat was nicht stimmt :) Würde man denen das unterschieben, würden sie genau nix bemerken. Das Zert/den Balken nehmen sie wahr. Dass da ein Logo kleiner oder unschärfer ist - meh, das fällt nicht auf. Und inzwischen ist in den aktuellen Browsergenerationen der Klick aufs Schloß etc. so viel einfacher, an die Infos zum Zert zu kommen.

Grüße

Phishing-Seiten haben ein gültiges Sicherheitszertifikat, weil sie eine eigene Domain haben und sich diese auch überprüfen lassen können. Da hilft das also genau gar nichts.

Doch, weil ich das Zertifikat _selbst_ prüfen kann. Bank: EV Zertifikat mit grünem Balken. Phisher: meist / immer irgendein Guffel-DV Zertifikat. Kein grüner Balken bei der Bank? Oh wait!
-> funktioniert nicht mehr, ich kann nicht mehr in das Zert reinsehen für wen es ausgestellt wurde. Und bei allem größer Class 2 steht da nicht nur "domain.tld" sondern eine komplette Anschrift die validiert sein muss.

User überprüfen TLS-Zertifikate? Muss irgendwie an mir vorbei gegangen sein, denn meiner Erfahrung nach wird immer dann reagiert, wenn es zu einer Warnung kommt. Hauptsache der Browser zeigt an, dass alles passt...

Nennt sich Erziehung, Aufklärung und Training. Wenn jemand bei einer Bank oder anderen Seite, bei der EV bspw. Pflicht ist keinen grünen Balken sieht, werden sie mißtrauisch. Sowas kann man lernen oder informierend weiter geben.

Außerdem funktioniert es nicht mehr, dass irgendwer zum Beispiel Rechnung.js aus einer E-Mail auf macht und die dann https://example.com/ransomware.exe runter lädt und ausführt und du dich infolge dessen um die Organisation des nächten Restore des Backups kümmern darfst.

Wird meist eh nur auf Windows Systemen funktionieren und dort ist in den meisten Umgebungen ein halbwegs ordentlicher Virenschutz (leider) immer noch Pflicht. Und ich bezweifle mal ganz stark, dass ein eingeschleifter ClamAV mit seiner recht schwachen Scan-Leistung da besser sein sollte als ein richtiger Client der mehrfach am Tag mit Signaturen versorgt wird. Und hier rede ich von einem reinen Virenscanner. Keinem Internet Security Suite Mistding, das sich selbst wieder wie eine Krake in Verbindungen eingräbt wo sie nichts zu suchen hat (Ja, ich schaue zu dir, Kaspersky, Symantec und Co.).

Bleibt jedoch der Punkt, dass der Proxy an der Stelle meines Erachtens mehr Ärger bringt als er potentiell beseitigen soll plus Schutzmechanismen bzw. Prüfmechanismen aushebelt, die anders besser funktionieren. Wie sich ein Proxy bspw. auf HPKP und HSTS auswirkt, hast du bspw. nicht beachtet in deinen Ausführungen. Diese werden - zumindest laut meinem letzten Stand - nicht weitergereicht. Ein Client bekommt also bspw. nicht mit, dass eine Verbindung auf SSL gefordert wird und HTTP gar nicht mehr erlaubt ist. Und sendet somit evtl. Daten versehentlich im Klartext.

Aber wie schon gesagt, ich sehe das anders und lege das nur dar, warum. Ich zwinge niemand meine Meinung auf. TLS ist problematisch genug ordentlich durch-/umzusetzen (schon auf Hostingseite), sich dann noch mit Proxies dazwischen in den Fuß zu schießen halte ich eben für kontraproduktiv. Und wir als Hoster haben schon oft genug gehört "dass die Seite auf dem Server nicht funktioniert", was dann eben doch wieder ein Proxy Problem in der eigenen Hoheit war. Insofern kenne ich beide Seite zu genüge ;)

Das hat mit freigestellt o.ä. einfach nichts zu tun. :) Du möchtest die Lösung, sei dir gegönnt. Ich mag sie nicht, denn man sieht so etwas schlicht nicht mehr. Bzw. einer muss sich dauerhaft damit beschäftigen, das kontrollieren und umsetzen, damit es für alle sauber funktioniert. Macht er das nicht, haben alle gleichzeitig ein Problem weil sie durch den Proxy immer heile Welt vorgegaukelt bekommen. Und genau aus dem Grund sind die Experten gegen SSL Interception auf Client Seite, weil immer Dinge verschleiert werden, die damit gar nicht erst beim Client ankommen, sondern vorher schon umgebaut werden. Man kann sich also nicht darauf verlassen.

Das kann nett sein, wenn man es zur Kontrolle nutzt (dannn hat man aber eh noch diverse Bestimmungen am Hals zwecks Datenschutz) oder zur Sicherung/Sicherheit. Nur wessen Sicherheit wird denn erhöht? Meine Clients bzw. Nutzer sind sicherer, wenn sie selbst aufgeklärt sind was diverse Szenarien anrichten und was das bedeutet, anstatt ihnen beim Surfen einfach vorzugaukeln alles wäre schick. Wenn ich bei jeder Seite einfach immer meine Dummy-CA sehe, wie soll man da jemand beibringen mal ein Zertifikat mit Argwohn zu beäugen, dass vielleicht nur vorgibt korrekt zu sein bzw. das einfach nicht passt (Stichwort Phishing). Das Problem bei sowas ist, dass Leute davon ausgehen dass das dann immer so ist und auch so sorglos agieren, wenn sie nicht mehr hinter dieser Proxy-"geschützten" Lösung sind. Und das halte ich persönlich für grenzwertig und eher schutzsenkend als -fördernd.

But I agree to disagree on this topic :)

Daher werden die sich hüten, falsche Zertifkate auszustellen und bei Bedarf nicht zu sperren. Ein Beispiel gibts hier:

Zu dem Satz sage ich nur (wiederholt): Symantec (und ihre unheilige Ehe mit Blue Coat). Wie oft wurden jetzt schon angebliche Demo, Test und sonstige Zerts von gültigen! CAs von Symantec unterschrieben die für Google und Co ausgestellt waren und absolut gültig waren? Zu Tests mit Laufzeiten von 3 Jahren und mehr? *hust hust*

Ich sehe das Zertifikat nicht mehr und habe also keine Chance sowas zu bemerken. Genauso wie HPKP und HSTS unterwandert werden.

Ein kurzer Gedankenanstoß noch zu SSL Termination auf "der anderen Seite" (also beim Client):

Wessen Proxy ist so eingestellt, dass er falsche, kaputte, unbekannte, unsaubere Zertifikate oder nicht vollständige Zertifikatsketten ablehnt? Wie bekomme ich als Client hinter dem Proxy mit, dass meine Verbindung zu "vielleicht-eine-bank.de" ein unsauberes Zertifikat retour liefert - da der Proxy die Verbindung öffnet (und ggf. das Zert annimmt, damit nicht so viele Fehler zum Client durchschlagen) und neu verschlüsselt, sieht für mich alles toll aus.

-> man nimmt dem Benutzer bzw. dessen Browser und sonstigen Tools durch re-encryption die Möglichkeit, selbst angemessen auf Probleme zu reagieren!

Anderes Beispiel: Zertifikatskette gebrochen oder ggf. nicht mehr sauber, Zertifikat als zurückgezogen gemeldet etc. Ist der Proxy genauso aktuell wie der Browser der sich automatisch updated? Hoffentlich, denn mein Browser lehnt z.B. Zertifikate von unsauberen CAs oder fehlerhaften Intermediates ab. Durch Re-encrypt sehe ich da nur meine 20 Jahre Eigenbau CA die erlaubt wird...

Da bin ich ebenso kritisch!

Grüße

Nehmen wir den USB Case an: Ein USB Stick ist beim Boot gesteckt -- auf welchen Partitionen soll gesucht werden? Auf allen? Soll diese Funktionalität bei jedem Boot ausgeführt werden? Soll das ganze auch für SD Karten gelten? Andere Festplatten?

Und die Preisfrage ist: soll das vollautomatisch laufen, oder halbautomatisch?

Kann ich an der Stelle nur für mich / unseren pfSense Fall beantworten: Hier ist es so, dass der Stick frisch formatiert mit FAT(32) sein muss, ergo gibt es nur einen Partition (einige Sticks unterstützen noch dazu auch keine wirkliche Partitionierung zumindest unter Windows). Daher primäre/erste Partition wäre genug.

Ansonsten: Wenn beim Boot gesteckt zusammen mit einem Installer Medium (CD/DVD/anderer USB), würde ich immer die Config einlesen und ausführen lassen, denn:

Resultat 1: User macht Installation und Konfiguration kann direkt schon auf neue Installation gespeichert werden
Resultat 2: User bootet von neuem USB-Installstick und kann damit direkt mal "kurz live antesten"
Resultat 3: User bootet von (spezieller) CD/DVD read-only Fassung und man kann damit (ggf) ein Livesystem realisieren, dass die Konfiguration zur Laufzeit nur temporär einliest, Änderungen während der Laufzeit werden in temporäres FS/RAM geschrieben und beim Neustart Settings wieder vom USB geholt. Gab es als Anfrage tatsächlich schon in Präsentationssystemen etc. wo man Änderungen gestatten will (zur Demo bspw.) aber nach Neustart dann wieder reset hat.

Ist aber nur mein Gedanke was das für Vorteile brächte.

Grüße

> How firewall rules in any version will filter by user group on LDAP / AD base?

What is meant by that one? Doesn't make much sense to me the way it reads. How should a _filter rule_ (on an IP package) determine a LDAP/AD user group? That info is nowhere to be found in an IP package of any sort!?

Ach Namen und Geschlechter sind Schall und Rauch :)

IPsec instabiler? Weshalb? Es geht nur darum, vom DSL Router ALLES an Daten zu bekommen und nicht nur eine Teilmenge. Das Einzige was "problematisch" sein kann ist, dass man eben an der Stelle Doppeltes NATting hat, allerdings haben wir das auch im Einsatz und auch andere Gegenstellen von verschiedenen Herstellern ohne Probleme. NAT-T hat da einiges an Problemen gelöst.

Notwendig ist das bei IPsec weil hier nicht nur UDP 500/4500 benötigt wird, sondern auch ESP als Protokoll. Wird das nicht weitergeleitet kommt der Tunnel später auch nicht zu Stande.

Den Zyxel solltest du doch problemlos vom LAN aus über die IP erreichen, über die er auch das Gateway für die beiden Sensen spielt? Alles andere wäre seltsam. Eine zweite IP musst du dem Zyxel deshalb nicht verpassen.

Grüße

Ich mutmaße mal dass du mich mit Jörg meinst, stimmt nur nicht ganz :D Aber immerhin 3 von 4 Buchstaben passen :P

> Ich habe gestern den Router so umgestellt, dass er selber PPPoE macht, und dann per NAT alles auf die Firewall IP umgeleitet - bzw. alle Ports, wo das ging, einer im 30000er Bereich war reserviert.

Nicht schön. Hat der Router keine Einstellung für exposed Host oder eine sonstige Einstellung, die einfach ALLES auf eine weitere IP weiterschickt? Je nach (schlechtem) Hersteller heißt sowas dann auch DMZ oder sonstwie. Einfach nur alle Ports weiterleiten, damit ist es nicht getan, es muss alles - also auch alle Protokolle, nicht nur TCP/UDP weitergeleitet werden. Das könnte sonst auch dein IPsec Problem erklären, denn da werden noch zusätzlich andere Protokolle benötigt.

>  es gibt doch nur externe (VDSL) Router? Sowas als Karte oder USB Stick gibt es doch seit 56k/ISDN Zeiten nicht mehr? Weil du von einem externen Router sprichst.

Nope nicht mehr. Bspw. gibt es von Draytek inzwischen den DSL Modem/Router auch als PCIe Steckkarte.
-> http://www.draytek.de/vigornic-132-serie.html
Damit ist sowas prinzipiell auch integriert möglich.

Das extern bezog sich aber mehr auf "außerhalb der *Sense" und ggf. ist sowas auch ein Providerrouter, also wirklich extern, denn was ich selbst nicht kontrolliere(n kann), ist von der Behandlung für mich gleichzusetzen wie "extern" oder "WAN" also potentiell unsicher. :)

Grüße
Jens

@andi:

Ich würde empfehlen das mit einem externen DSL Router zu realisieren. Was ganz einfaches und simples, was dann ordentlich weiterleitet auf die CARP VIP der beiden Sensen dann. PPPoE Einwahl mit CARP ist ein wenig zweispältig (so mein letzter Stand). Im dümmsten Fall hast du 2 PPPoE Sessions auf beiden Sensen offen, das ist dann eher kontraproduktiv ;)

did you configure both default gateways on the corresponding interfaces of opnsense?

Dein Trafficrouting machst du per Policy Based Rules? Wenn ja, dann einfach unter diese Regeln eine Blockregel setzen mit Gateway default/* und den gleichen Zielen.

Jan 6 14:45:09 openvpn[55222]: RESOLVE: Cannot resolve host address: 192.168.167.10: hostname nor servname provided, or not known

Hi mustermann,

das wird ja auch kaum funktionieren, wenn du den VPN Server  nicht durch den UM Router durchtunnelst UND noch dazu keinen DynDNS Namen o.ä. vergeben hast. Dass sich ein VPN Client nicht mit einer privaten IP durchs Internet verbinden kann leuchtet ein :D Schon gar nicht per V4 wenn du nach außen aber nur DS Lite hast.

Grüße

Wenn du es exportierst wirst du normalerweise nach einem Kennwort gefragt. Gibst du keins ein, braucht es auch keines zum importieren. Vielleicht nochmal durchspielen?