Hallo. Wie kann man IP Zugriffe unterbinden wenn vorher keine DNS Abfrage stattgefunden hat? So soll zB der Zugriff auf 1.1.1.1 gesperrt werden wenn diese IP direkt aufgerufen wird. Wenn vorher eine DNS Abfrage stattfindet zB google.de A -> 1.1.1.2 soll der Zugriff auf 1.1.1.2 danach frei sein. Danke. Martin
Das wird gar nicht so einfach. Man müsste DNS mitlesen und aus der Antwort die IPs extrahieren und diese dann im Paketfilter für eine gewissen Zeit freischalten.
Hallo. Einen lokalen bind9 könnte ich nutzen. Gibt es eventuell ein Lösung für einen transparenten Squid? Martin
In der Firewall alles zumachen, per DNS-Proxy, sniffer, nf-userspace-queueing etc. DNS-Anfragen analysieren, entsprechene ALLOW-Regeln in die Firewall pushen. Gibt's m.W. nicht fertig, je nach gewünschter Performance wirst du selber ein wenig Scripten oder Programmieren müssen. (einfachste Lösung: Bash-5zeiler, tail -f auf dnsmasq-Log, ein wenig grep)
Planlos schrieb: > (einfachste Lösung: Bash-5zeiler, tail -f auf dnsmasq-Log, ein wenig > grep) Das wird wahrscheinlich wegen dem Timing nicht funktionieren: der Client wird wahrscheinlich sehr schnell nach der DNS-Antwort seinen Verbindungsaufbau versuchen. Das tail -f hat da noch nicht reagiert. Vermutlich wirst Du eine Lösung brauchen, die die DNS-Antwort verzögert bis die Firewall-Regel aktiv ist.
Martin schrieb: > Wie kann man IP Zugriffe unterbinden wenn vorher keine DNS Abfrage > stattgefunden hat? Wenn es sich um HTTP/HTTPS/FTP-Zugriffe handelt: Proxy-Server verwenden und in der Firewall zwischen Netz und Rest der Welt nur diesem Proxy Zugriff geben. Im Proxy lassen sich dann problemlos alle Zugriffe auf numerische Ziele sperren.
A. K. schrieb: > Wenn es sich um HTTP/HTTPS/FTP-Zugriffe handelt: Proxy-Server verwenden > und in der Firewall zwischen Netz und Rest der Welt nur diesem Proxy > Zugriff geben. Im Proxy lassen sich dann problemlos alle Zugriffe auf > numerische Ziele sperren. Der Proxy ist in der Tat die sauberste und daher auch die gängige Lösung. Aber Du brauchst dafür einen Eingriff in den Client, in dem Du dem Browser so einstellst, daß er den Proxy verwendet. Sonst geht nichts durch. Ein transparenter Proxy ist für HTTP möglich, nicht aber bei HTTPS.
Das nächste Problem ist, der Client cached die DNS Anfrage. Das Cache timeout vom Client muss mut dem zusammen passen, wann du die Regel wieder raus wirfst. Was willst du erreichen? Mir wäre noch was eingefallen, der bind könnte die Antwort "scramblen", ganz simpel z. B. mit XOR -1. Statt 1.1.1.2 antwortet er mit 254.254.254.253 Iptables muss beim routing dieses scrambling dann wieder rückgängig machen. Somit wäre ein direkter Zugriff auf 1.1.1.2 nicht möglich (wohl aber durch Eingabe von 254.254.254.253) Der scrambling Algorithmus müsste natürlich so gewählt werden, dass er nicht mit privaten oder Broadcast-Netzwerkadressen kollidiert. Gruß Roland
Gerd E. schrieb: > Aber Du brauchst dafür einen Eingriff in den Client, in dem Du dem > Browser so einstellst, daß er den Proxy verwendet. Sonst geht nichts > durch. Yep. Das ist auch meistens problemlos möglich. Da ohne Proxy nichts geht ist die Lernkurve steil.
:
Bearbeitet durch User
Gerd E. schrieb: > Ein transparenter Proxy ist für HTTP möglich, nicht aber bei HTTPS. Doch. Mit Einschränkungen allerdings. Dem Client muss eine zusätzliche CA beigebracht werden und sowas wie CA pinning darf nicht verwendet werden.
:
Bearbeitet durch User
A. K. schrieb: > Gerd E. schrieb: >> Ein transparenter Proxy ist für HTTP möglich, nicht aber bei HTTPS. > > Doch. Mit Einschränkungen allerdings. Dem Client muss eine zusätzliche > CA beigebracht werden und sowas wie CA pinning darf nicht verwendet > werden. Wie soll das gehen? Bei einem transparenten Proxy sieht der Proxy nur die TCP-Verbindung auf die Ziel-IP. Dennoch muss er ein Zertifikat präsentieren, welches auf den DNS-Namen, den der Browser angesteuert hat, ausgestellt ist. Woher soll er den DNS-Namen kennen? Daß er, wie von Dir oben angesprochen, das Zertifikat mit seiner eigenen CA erstellen muss ist klar.
Gerd E. schrieb: > Wie soll das gehen? Wie es technisch abläuft hab ich mir nicht angesehen. Es gibt aber Firewalls, die es nachweislich können. Selbst bei Verwendung von PFS.
A. K. schrieb: > Wie es technisch abläuft hab ich mir nicht angesehen. Es gibt aber > Firewalls, die es nachweislich können. Selbst bei Verwendung von PFS. glaube ich nicht. Das ganze geht nur wenn keine Virtuellen Hosts eingesetzt werden. Sobald auf einem https mehre Hostsname vorhanden sinn kann es nicht mehr funktionieren. Außerdem ist ein transparenten ziemlich sinnlos. In Firmennetzten kann man die Proxy systemweit konfigurieren - warum soll man ihn dann noch Transparent machen?
A. K. schrieb: > Wie es technisch abläuft hab ich mir nicht angesehen. Es gibt aber > Firewalls, die es nachweislich können. z.B. die Sophos UTM können es. Siehe u.a. hier: https://ictschule.com/2015/05/15/content-filter-fr-ssl-seiten-auf-sophos-utm-einrichten/
Icke ®. schrieb: > z.B. die Sophos UTM können es. Siehe u.a. hier: > > https://ictschule.com/2015/05/15/content-filter-fr-ssl-seiten-auf-sophos-utm-einrichten/ und wo stehen die Einschränkungen? So lange keine Virtuelle Host vorhanden ist, ist das ja auch kein Problem. Da in dem Artikel nicht von V-Hosts steht, würde ich mich nicht darauf verlassen das es funktioniert.
Peter II schrieb: > glaube ich nicht. Das ganze geht nur wenn keine Virtuellen Hosts > eingesetzt werden. Sobald auf einem https mehre Hostsname vorhanden sinn > kann es nicht mehr funktionieren. Das war mal so. Mit SNI wird der Hostname im Klartext übertragen. Siehe auch https://github.com/dlundquist/sniproxy > Außerdem ist ein transparenten ziemlich sinnlos. In Firmennetzten kann > man die Proxy systemweit konfigurieren - warum soll man ihn dann noch > Transparent machen? Ack. Die Frage ist, was will der Threadstarter erreichen. Gruß Roland
Peter II schrieb: > Icke ®. nachtrag: ich habe gerade nochmal nachgelesen: https://de.wikipedia.org/wiki/Server_Name_Indication bei SNI wird wirklich der Hostname Im Klartext übertragen, damit könnte die Proxy ein passendes Zertifikat ausstellen. Ich hätte gedacht, das es verschlüsselt(gehascht) übertragen wird.
Peter II schrieb: > glaube ich nicht. Ausprobiert und geht. > warum soll man ihn dann noch Transparent machen? Ob man das als formalen transparenten Proxy bezeichnet, oder als moderne Firewall, ist kaum noch relevant. Moderne Firewalls schauen ohnehin recht tief in den Stream rein und schrauben auch gerne daran herum. Bei klassischen Verfahren von Checkpoint kann man Filterung und transparenten Proxy noch gut unterscheiden, bei Palo Alto verschwimmt das völlig. Man kann Scanning für Web und Mail zwar auch in separaten Proxies/Servern machen. Aber wenn es die Firewall sowieso schon kann, dann kann man das auch nutzen.
:
Bearbeitet durch User
Peter II schrieb: > bei SNI wird wirklich der Hostname Im Klartext übertragen, damit könnte > die Proxy ein passendes Zertifikat ausstellen. Wenn die Daten unverändert an den Zielhost weitergegeben werden, braucht man das gar nicht > Ich hätte gedacht, das es verschlüsselt(gehascht) übertragen wird. Gibt glaube ich eine Erweiterung "encrypted SNI" - konnte aber auf die Schnelle nicht herausfinden ob die schon im Standard ist. VG Roland
Hallo. Mit Squid: acl numeric_IPs dstdom_regex ^(([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)|(\[([0-9a-f]+)?:([0-9a-f:]+)?:([0-9a- f]+|0-9\.]+)?\])) oder bei nur ipv4 acl notanip dstdom_regex [^0-9\.] Martin
Roland P. schrieb: > Das nächste Problem ist, der Client cached die DNS Anfrage. Das Cache > timeout vom Client muss mut dem zusammen passen, wann du die Regel > wieder raus wirfst. Das ist unproblematisch, denn in der DNS-Reply steht die TTL mit drin und genau so lange darf der Client das Ergebnis verwenden - also sollte man das Timeout für die Regel auch so setzen. Aber der ganze Ansatz mit Firewall-Regeln ist pervers, denn was sich da an einer Menge von Regeln anhäuft, ist der Performance des Paketfilters nicht gerade zuträglich, DNS Round Robin wurde ja nicht erst gestern erfunden und ist gerade bei häufig benutzten Services oft genug zu finden. Paketfilter mit tausenden von Einträgen sind unschön (nicht nur im normalen Betrieb, auch bei der Fehlersuche).
A. K. schrieb: > Dem Client muss eine zusätzliche > CA beigebracht werden und sowas wie CA pinning darf nicht verwendet > werden. 1. Du meinst certificate/public key pinning. 2. Nein das klappt (meist) trotzdem, certificate pinning wird für manuell nachinstallierte Zertifikate ignoriert! Damit eben genau so etwas noch funktioniert. Martin schrieb: > Wie kann man IP Zugriffe unterbinden wenn vorher keine DNS Abfrage > stattgefunden hat? Für was brauchst du das? Das hört sich nach einem sehr speziellen Problem an, welches man SO eventuell gar nicht lösen sollte. Es wäre für einen Angreifer (falls es hier um Security geht!) sehr einfach, einen DNS Server aufzusetzen der IPs nach Wunsch zurück gibt.
Hallo. Ich muss den Zugriff auf gewisse Internetseiten beschränken. Eine Sperre des DNS Namen hat sich als unwirksam herausgestellt - findige Leute geben jetzt einfach die IP ein (zB von Ihrer Fritz!Box zuhause um von dort Dateien ins oder aus dem Netz zu kopieren - dank All-IP ändert sich diese ja sogar tagelang nicht ;-) Da stellte sich mir die Frage wie verhindert man das einfach und flexibel (die DNS Liste mit den offenen Seiten wird immer mal wieder angepasst). Den Ansatz über Squid werde ich mal versuchen. Wie machen das grosse Firmen? Oft sind da ja auch einige oder alle Internetseiten gesperrt - DNS-Tunnel und direkte IP geht aber meist trotzdem. Martin
Martin schrieb: > Hallo. > > Ich muss den Zugriff auf gewisse Internetseiten beschränken. Eine Sperre > des DNS Namen hat sich als unwirksam herausgestellt - findige Leute > geben jetzt einfach die IP ein (zB von Ihrer Fritz!Box zuhause um von > dort Dateien ins oder aus dem Netz zu kopieren - dank All-IP ändert sich > diese ja sogar tagelang nicht ;-) > Da stellte sich mir die Frage wie verhindert man das einfach und > flexibel (die DNS Liste mit den offenen Seiten wird immer mal wieder > angepasst). Man definiert die erlaubten Zielnetze und sperrt alles andere im Paketfilter. Die Pflege erledigt man über ein paar Listen und Scripte. BTDT. > Den Ansatz über Squid werde ich mal versuchen. > Wie machen das grosse Firmen? Oft sind da ja auch einige oder alle > Internetseiten gesperrt - DNS-Tunnel und direkte IP geht aber meist > trotzdem. Eben. Deswegen macht man das einfach nicht - es ist eh zwecklos und stört im entscheidenden Augenblick dann doch wieder die legitime Arbeit. BTDT, war halt das Geld des Auftraggebers, das er da mit dem Humbug verbraten hat. Umgangen haben wir das dann nach inoffizieller Absegnung trotzdem, denn das konnte die dortige Zentral-IT auch nicht wirksam unterbinden. Aufklärung, Weiterbildung und ein hinreichend schmerzhaftes LART (ich habe gerne ein 19" C-Profil genommen) sind da wirksamer, preiswerter und nachhaltiger.
Ralf D. schrieb: > Eben. Deswegen macht man das einfach nicht - es ist eh zwecklos und > stört im entscheidenden Augenblick dann doch wieder die legitime Arbeit. In dieser Balance gibt es keine einfachen Antworten. Entwickler wollen einen offenen Zugang und die Systemleute sehen die Risiken offener Zugänge. Aber man kommt dann schon zu passablen Lösungen für beide Seiten. Es spricht sich rum, wenn jemandem von jetzt auf gleich der PC infektionsbedingt geplättet wurde. Praktische Erfahrung zeigt, dass bereits eine so simple Sache, wie ein nur über Proxy erreichbares Internet, oft verhindern kann, dass ein eingefangener Trojaner zum Problem wird. Weil sich viele dieser Genossen nicht über Proxy zum C&C trauen, sondern nur direkt. Und das geht erstens nicht und fällt zweitens auf. Natürlich gibts 1000 Möglichkeiten, diese Hürde zu überwinden. Aber so wie nicht jeder Gauner eine Intelligenzbestie ist, so ist auch nicht jeder eingefangene Schädling ein Stuxnet.
:
Bearbeitet durch User
Martin schrieb: > Wie machen das grosse Firmen? Beispielsweise mit dem Squid wie geschildert. Proxies dienen heute weniger der Ersparnis von Datenrate (dieser Nutzen ist so gering, dass man diese Funktion auch abschalten kann um Ressourcen zu sparen), als vielmehr als Sicherheitsmechanismus, Filter, für QoS ... Allerdings sind Enterprise-Firewalls und -Proxies etwas gewitzter als eine Fritzbox. Da lassen sich Internet-Zugänge auch abhängig vom aktiven Nutzer eines PC auf per Positivliste bestimmte Themenbereiche von Seiten einschränken, vorklassifiziert vom Hersteller der Firewall oder des Proxies. Wenn also dein Büronachbar auf Seiten kommt, die dir gesperrt sind, dann nützt es dir u.U. auch nichts, dich auf seinem PC anzumelden. > DNS-Tunnel und direkte IP geht aber meist trotzdem. Das kann ein Katz- und Maus-Spiel werden. Tricks wie DNS-Tunnel eignen sich nur für bescheidene Datenmengen, sonst fällt das einer besseren Firewall möglicherweise auf.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.