Mit pf TTL Wert für jede Regel setzen?

Conrad

Member
Hi weiß jemand von Euch ob man mit OpenBSD's pf den TTL Wert für jede einzelne Regel setzen kann?

Ich verwende immer in der SCRUB Regel --->

match in log on vio0 set (tos ef) scrub (max-mss 1460, min-ttl 255, random-id, reassemble tcp, no-df)
match out log on vio0 set (tos ef) scrub (max-mss 1460, min-ttl 255, random-id, reassemble tcp, no-df)

Um die "The Generalized TTL Security Mechanism (GTSM)" zu erzwingen: Und den Standart Wet ttl 64 auf 255 zu setzen:
https://www.ietf.org/rfc/rfc3682.txt

Ich würde aber gerne für jede rule eine eigene TTL setzen, ist das möglich mit OpenBSD's pf ?

--->

pass in log quick on vio0 inet proto tcp from any port > 1024 to 172.31.1.100/32 port {53, 80, 443} flags S/SAFRUP synproxy state # ttl 1 mein Zusatz der leider nicht funktioniert

pass in log quick on vio0 inet proto udp from any port > 1024 to 172.31.1.100/32 port 53 keep state # ttl 1 das nach dem # ist mein Zusatz der aber nicht funktioniert! Leider!

Und so weiter für jede Regel egal ob hinein oder hinaus mit einem eigenen TTL wert zu versehen. Geht das mit OpenBSD?

Vielen Dank
Conrad
 
Hi

Die TTL für jede Regel zu setzen macht großen Sinn wenn man die Netzwerksicherheit verbessern möchte, das Funktioniert natürlich nur bei Regeln wo die Server in Deiner Hand sind.
Wo Du die TTL von Netz A zu Netz B auch wirklich bestimmen kannst also normalerweise nur im Internen Netzwerk (Egal ob Firma oder privat) wo sich normalerweise die Route von A nach B usw nicht ändert, oder nicht oft!

Beispiel: Client A ssh2 ---> Server B
Client max ttl 1 to Server B
Client C ssh2 --> Server B
Client C max TTL 10 to Server B eine größere TTL ist unnötig der Client A hat genau nur 1 HOP Abstand zum Server B beim Client C sind es zum Beispiel genau 10 HOP's zum Server usw. warum also einen größeren TTL Wert setzen?! Security geht vor! So kannst Du
Man-in-the-Middle-Angriff erfolgreich verhindern.

http://www.cisco.com/c/en/us/td/docs/ios/12_2s/feature/guide/fs_btsh.html

https://books.google.at/books?id=mD...age&q=Die ip ttl als security feature&f=false

https://www.ietf.org/rfc/rfc3682.txt

https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff

https://calomel.org/pf_config.html
 
Lt. Murphy hat man genau dann ein Problem - und will sich per ssh einloggen - wenn das Routing (huch, Dynamik!) mal anders ist und man 12 hops "braucht" und wg TTL=10 tut es nicht.

Foot. Shoot. Wissenschon.

PS: sshfp.
 
Und um auch noch in die Kerbe meiner Vorposter zu schlagen: Du baust dir damit unter Garantie so richtig obskure Netzwerkprobleme, die ernsthaft eklig zum debuggen sind.
 
Zusatz:

Ability to drop invalid packets based on the expected TTL value is termed as “IP TTL security”. Is not this a simple and effective technique?



This technique can also be used when routers are multiple hop away if network administrator can configure the receiver with a correct expected TTL value.



In IPv6, TTL field is replaced with hop-limit field. The overall functionality of hop-limit is same as TTL. So technique mentioned here can be applied with hop-limit to provide similar security in IPv6 networks.
 
man man ,man lese doch erstmal was ttl ist und was der wert dahinter darstellt.

selbst in einem gleichwertigen LAN mit mehreren segmenten und einer ,mehrer , firewalls dazwischen würde ich niemals
die TTL als security feature nutzen.

die TTL verändert sich ja schon dann wen ein Rechner in segment a von einem rechner in segment über eine firewlll via cifs
eine datei koppiert.
es macht , im zweifel , sinn in einem multi label oder bgp router umfeld mit ttl werten zu arbeiten aber nicht aus sicherheits sondern mehr aus stabilitäts gründen,

ich abeite in einem BGP , MPLS , OSPF umfeld mit standleitungen , bzw mpls verbindungen von 2 bin 10 GBit Ethernet , und es kommt niemand nur im ansatz auf die idee
mit der TTL zu arbeiten.

im übrigen gibt es z.b .für ipv4 traceroute ein max hop limit.

wenn du die von dir zitierte RFC mal genau liest so geht es bei der IP TTL technik um schutz bestimmter routing mechnismen bzw deren funktion und nicht darum
ssh oder sonstige apps abzusicheren.

sorry , verrenn dich nicht darin .


holger
 
Einfach mal beim Denken bei den Basics bleiben. Wie soll ein Wert, der im Klartext und unauthentifiziert übertragen wird, vor MitM schützen?

Edit: Im Zweifelsfall verringert der MitM den Wert einfach nicht. Dann ist er TTL-mäßig "unsichtbar" und das Ganze ist sinnlos. Dass Router die TTL verringern, ist kein Naturgesetz. Das ist einfach Code, den man auch weglassen kann.
 
Zurück
Oben