Jails bei Hetzner

martin

Well-Known Member
Moin

über die Weihnachtsfeiertage wurde mein Hetzner root Server wohl für einen Angriff ausgenutzt ( der Fehler lag in einem nicht aktuellen NTPD). Nach etwas Recherche im Internet habe ich nun folgende Zeilen in meine ntp.conf eingefügt:
Code:
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict default ignore
Dadurch sollten keine weiteren Angriffe dieser Art mehr möglich sein. Soweit hoffe ich, dass diese Problem also gelöst ist!?
Nun zu meinem Hauptproblem. Nach dem Angriff habe ich den NTP vorübergehen gestoppt, wodurch Pakete diesen Types in den Logs der Hetzner Switches auftauchten:
Code:
 17:23:07.639680 XX:XX:XX:XX:XX:XX > XX:XX:XX:XX:XX:XX, ethertype IPv4
> > (0x0800), length 70: 192.168.0.1 > 72.20.25.153: ICMP [MEINE_OFFENTLICHE_IP] udp
> > port 123 unreachable, length 36
192.168.0.1 ist eine meiner Jails und genau da liegt der Knackpunkt. Laut Hetzner Support bin ich nicht befugt lokale IP Adressen zu verwenden. Nach langem Hin und Her konnte ich den Support Mitarbeiter überzeugen, mir meinen zuvor gesperrten Server wieder frei zu geben, allerdings unter der Voraussetzung, dass "keine weiteren Pakete von 192.168.0.X" auf den Hetzner Switches landen.
Jetzt meine Fragen:
- wie macht ihr das mit den Jails (falls ihr Hetzner Kunden seid)
- kann ich irgendwie (per pf vielleicht) verdindern, dass Pakete von 192.168.0.X in den Logs von Hetzner aufscheinen, ohne dabei die Funktion meiner Jails zu beeinträchtigen? Die Jails brauchen weiterhin eine Verbindung nach außen, wegen Updates und die vom Hostsystem über pf weitergeleiteten Dienste müssen natürlich weiterhin funktionieren.

Danke
 
Ich verwende in meinen Jails ausschließlich mir zugewiesene IPs. Heisst für alle nach aussen wichtigen Systeme habe ich entsprechende IPs beantragt und an die Jail gebunden. Alternativ kannst du natürlich auch die selbe IP mehrfach verwenden so keine Dienste mehrfach auf den selben Ports lauschen.

Sonst könntest du einfach auch noch ein NAT bauen, aber warum verwendst du überhaupt IPs aus dem privaten Adressraum auf dem Server?
 
Ich habe die IPs der Jails (aus der private range) auf einem lo Interface liegen. PF macht dann NAT für mich und Portweiterleitungen auf die Public IP.
 
Hi

das Problem ist nicht die Konfiguration an sich. Die funktioniert seit 3 Jahren einwandfrei, ich verwende wie gesagt den privaten Adressbereich 192.168.0.X und biege mir mit NAT bzw. der pf.conf die Ports so hin wie ich das brauche. Das Problem ist, dass laut Hetzner die Verwendung privater Adressen vertragswidrig ist. Zwar wurde mir mein Server nach langen Erklärungen wieder frei geschaltet, aber das mulmige Gefühl bleibt.
Geraten "verdächtige" Pakete mit Ursprung aus dem privaten Adressbereich auf die Hetzner Switches wird mein Server sofort wieder vom Netz genommen.
 
Im Netzwerk ist das richtig. Aber lokal auf seiner Kiste kann Hetzner doch nichts vorschreiben, sofern da alles durchs NAT läuft, oder?
 
Können sie schon. Aber was sie nicht wissen... ^^ Ich glaube eine sichere Lösung ist, die lokalen IP-Adressen an lo0 zu binden. Das sollte an sich schon mal dafür sorgen, dass Pakete nicht einfach so bis zum Switch laufen. Dazu dann das NAT so konfigurieren, dass wirklich gar nichts aus dem interne Netz nach außen dringen kann, da alles zwangsläufig immer geNATet wird. Und da das nun etwas wirr war, sagen wir es besser in Code:
Code:
# -------------------------------------------------------- #
# Einfaches Filterscript fuer ipfw. Seine Hauptaufgabe ist #
# es In-Kernel-NAT fuer die Jails anzubieten.              #
# -------------------------------------------------------- #

# Das Kommando
cmd="/sbin/ipfw -q"

# Unsere Netzwerkkarte
lan_if="re0"

# Unsere oeffentliche IP
ipaddr="zensiert"

# Das Jail-Netzwerk
jail_net="10.0.0.0/24"

# -------------------------------------------------------- #

# Alles rauswerfen
$cmd flush
$cmd queue flush
$cmd pipe flush

# -------------------------------------------------------- #

# Alles was einen State hat darf durch
$cmd add 10 check-state

# Vom Host auf die Jails
$cmd add 20 allow all from me to $jail_net setup keep-state

# -------------------------------------------------------- #

# NTP Sicherung (muss vor NAT)
$cmd add 30 allow udp from me to any 123 out via $lan_if uid root keep-state
$cmd add 40 deny udp from any to any 123

# -------------------------------------------------------- #

# NAT und Port Forwardings
$cmd nat 1 config if $lan_if \
        redirect_port tcp 10.0.0.1:4321 $ipaddr:4321

$cmd add 50 nat 1 all from $jail_net to not $jail_net
$cmd add 60 nat 1 all from any to $ipaddr

# -------------------------------------------------------- #

# Alles durchlassen
$cmd add 70 allow all from any to any

Regel 50 und 60 sind die Magie.
 
Die ersten Regeln in _jedem_ ruleset sollten sein, RFC1918 und andere bogons _komplett_ zu filtern, d.h. ohne Angabe einer bestimmten Richtung sowohl von als auch zu den Adressen filtern.
 
Ich wollte mir demnächst auch einen VServer bei Hetzner zulegen, natürlich mit FreeBSD. Gibt es dann eine andere Möglichkeit, außer privater Adressen, Jails zu betreiben?
Ich nehme mal an, mehrere öffentliche IPv4-Adressen bekommt man nicht mehr ohne weiteres, und eigentlich sind sie ja auch nicht notwendig.
Als Anfänger würde ich mir aber nur ungern meinen Server sperren lassen ;)
 
Wenn du mehr als eine IP willst musst du dies begründen. Der Betrieb von Jails genügt als Begründung für die Beantragung weiterer IPs (zumindest war das noch zu meiner Zeit der Fall).
Alternativ kannst du deine Jails auch an dein Localhost binden oder einfach mehrere Jails an die selbe IP. In letzterem Fall musst du nur sicher stellen, dass keine Ports mehrfach belegt werden (z.B. über 2 Webserver auf Port 80 oder so), das ginge dann schief.
 
Es hat sich geändert. Seitdem IPv4 nahe vor dem Abgrund steht, ziert sich Hetzner sehr weitere Adressen zu vergeben. Das braucht nun eine gute Begründung und kostet Geld.
 
Das selbe fand auch auf meinem Hetzner Rootserver statt, am 26.12 stieg der ntp Traffic auf ca. 4Gbytes/Tag an,
Ich habe am 28.12. ntp nach außen abgedreht und die Konfiguration genauso wie der TO geändert.
Die Jails laufen bei mir auf kostenpflichtigen zusätzlichen IP Adressen.

Gruß,

Holm
 
Ich bin auch bei Hetzner und habe meine Jails nicht nach aussen hin offen.

Bei mir sieht das Setup so aus, dass ich die Jails mit IPv4 auf Loopback interface 1 und mit IPv6 direkt auf dem Ethernetinterface (falls die Jails von aussen via IPv6 erreichbar sein sollen). Keine Jail hat die public IPv4 von Hetzner direkt. Nichtmal der root server hat irgendwas auf IPv4 laufen.

Über IPv4 ist nur der Webserver ( mittels pf Regeln wird Port80 auf die interne IP gemappt) erreichbar.

Wenn die Jails sich untereinander unterhalten wollen ( bei mir eigentlich nur der nginx webserver, der als Webserver dient und als Proxy zu bestimmten Diensten, die separiert aus sicherheitsgründen in eigenen Jails laufen, dient ) geht das dann über das loopback interface.

So spare ich mir die Kosten für die ganzen zusätzlichen IPv4 Adressen bei Hetzner, weil ich öffentlich nur Webservices zur Verfügung stelle. Jails die Services für meine internen Sachen zur Verfügung stellen laufen allesamt über IPv6 only.

Ich muss allerdings anmerken, dass ich neu bei FreeBSD und Jails bin und bisher das ähnlich mit Debian und Vmwareserver gelöst habe.

Patrick aka Jolly
 
Adressen auf lo0 verhindern aber nicht, dass diese als Quelladressen nach draußen leaken. Filtern, filtern, filtern!
 
Ich hatte vergessen zu erwähnen, dass aller Traffic geblockt wird und nur die Ports, die auch tatsächlich von aussen hin erreichbar sein sollen durchgereicht werden ( auch bei ipv6 ).
 
Hallo,

könnt Ihr mir vielleicht mal einen Link senden wo der Verbot von Privaten IP Adressen steht.

Viele Grüße

Jörg
 
Das steht im Vertrag über den Server / vServer. Beim Bereitstellen des Servers wird in der Mitteilung der Adressen noch einmal zusätzlich darauf hingewiesen.
 
Aus aktuellem Anlass melde ich mich wieder mit dem selben Problem. Mein Server wurde erneut gesperrt.
Wie kam es dazu? Erst gestern habe ich meine Datenbank Jail (es läuft lediglich mysql mit Abhängigkeiten) auf FreeBSD 10.0 RELEASE gebracht und alle Ports aktualisiert. Soweit so gut. Alles lief einwandfrei. Die Jail hat die IP 192.168.0.1 und ist auf lo0. In dieser Konfiguration scheint es ja bei vielen von euch tadellos zu klappen. Wie erwähnt gelangen anscheinend dennoch datenpakete mit 192.168.0.1 an die Hetzner Switches, hier die Beanstandung:
...
09:12:57.155961 08:60:6e:69:5a:1d > 78:fe:3d:46:eb:a5, ethertype IPv4
(0x0800), length 70: 192.168.0.1 > 186.2.161.107: ICMP XXX.XXX.XXX.XXX udp
port 123 unreachable, length 36
09:12:57.184308 08:60:6e:69:5a:1d > 78:fe:3d:46:eb:a5, ethertype IPv4
(0x0800), length 70: 192.168.0.1 > 186.2.161.107: ICMP XXX.XXX.XXX.XXX udp
port 123 unreachable, length 36
09:12:57.196545 08:60:6e:69:5a:1d > 78:fe:3d:46:eb:a5, ethertype IPv4
(0x0800), length 70: 192.168.0.1 > 186.2.161.107: ICMP XXX.XXX.XXX.XXX udp
port 123 unreachable, length 36
09:12:57.343569 08:60:6e:69:5a:1d > 78:fe:3d:46:eb:a5, ethertype IPv4
(0x0800), length 70: 192.168.0.1 > 186.2.161.107: ICMP XXX.XXX.XXX.XXX udp
port 123 unreachable, length 36
09:12:57.401592 08:60:6e:69:5a:1d > 78:fe:3d:46:eb:a5, ethertype IPv4
(0x0800), length 70: 192.168.0.1 > 186.2.161.107: ICMP XXX.XXX.XXX.XXX udp
port 123 unreachable, length 36
...

Das Problem liegt wohl am ntp, was mir aber komisch vorkommt. Wie gesagt, Hostsystem, Jail und Ports sind auf neuestem Stand.
 
Was spricht gegen den Adressraum 127.0.0.0/8? Das sollte überhaupt nicht nach außen geroutet werden.
 
@Rakor
Nein kein Gateway in rc.conf eingetragen, lediglich die Namensauflösung wurde vom Host kopiert. NAT ist aktiviert, damit ich die Ports updaten kann.

@nakal
Es spricht nichts dagegen. Es bedeutet einen zusätzlichen Aufwand, da ich natürlich an sämtlichen Stellen die IP Adresse ändern muss (PHP Code vor allem). Das wäre eigentlich kein Problem, nur müsste ich sicher sein, dass damit das Problem auch gelöst wurde. Denn einmal kann ich Hetzner wahrscheinlich damit vertrösten, dass eine Fehlkonfiguration durch das Update Grund für die "private Adresse" war. Ein zweites mal werden die genauer nachfragen und dann komme ich in Erklärungsnot.

anmerken möchte ich noch, dass meine Konfiguration eine schon seit einem Jahr ohne Probleme funktioniert. Die Probleme habe ich erst seit dem Update.
 
Du kannst ja nicht /etc/resolv.conf einfach so einstellen, dass nach außen kommuniziert wird (was auch mit 192.168.0.0/16 zugelassen ist und mit 127.0.0.0/8 nicht). Hast Du geguckt, ob Pakete tatsächlich die NAT mitmachen? Du hast doch mit unbound einen lokalen Resolver für DNS, den kannst Du vom Jail her kontaktieren.
 
Zurück
Oben