IP ohne DNS sperren

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.

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.

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.

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/

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:
> 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.

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

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).

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.

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.