IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Networking (Seite 7 von 12)

Bash Schnipsel Message Size Limit

Ich muss gerade bei einigen Systemen den Message Size Limit von Postfix kontrollieren. Jetzt liegen die verschiedenen Kundendomains in verschiedenen Containern. Ich muss also immer nachschauen welcher, da ich faul bin hat mir folgender Einzeiler die Arbeit etwas erleichtert….

kernel@errorpc ~ $ ssh xyz-user@`dig kernel-error.de in MX +short|sed -e 's/^.\{,3\}//'` "postconf | grep message_size_limit"
message_size_limit = 104857600

Er sammelt sich per dig den gesetzten MX Eintrag der jeweiligen Domain aus dem DNS (es gibt nur einen pro Domain), schneidet die Prio und das Leerzeichen ab und übergibt den übrigen Hostname dann an ssh, welches sich direkt als xyz-user dort anmeldet, Postfix nach dem eingestellten Wert fragt und direkt wieder „auflegt“.

Passt natürlich nicht für jeden Fall, war aber hier wieder schön.

Fragen? Einfach melden.

Perfect Forward Secrecy für Postfix und Dovecot konfigurieren

Perfect Forward Secrecy (PFS) sorgt dafür, dass jede TLS-Verbindung einen eigenen temporären Schlüssel verwendet. Selbst wenn jemand den privaten Schlüssel des Servers in die Hände bekommt, kann er damit früher aufgezeichnete Verbindungen nicht entschlüsseln. Für E-Mail ist das besonders relevant, weil Mailverkehr gern auf Vorrat mitgeschnitten wird.

PFS bekommt man durch ECDHE- oder DHE-Schlüsselaustausch. Moderne OpenSSL-Versionen und aktuelle Postfix/Dovecot-Releases machen das Richtige von Haus aus. Trotzdem lohnt sich ein Blick auf die Konfiguration, um sicherzustellen, dass keine veralteten Protokolle oder Cipher-Suiten aktiv sind.

Postfix

Die relevanten Einstellungen in der main.cf:

# Eingehend (smtpd)
smtpd_tls_security_level = may
smtpd_tls_protocols = >=TLSv1.2
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_mandatory_ciphers = medium

# Ausgehend (smtp)
smtp_tls_security_level = dane
smtp_tls_protocols = >=TLSv1.2
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_mandatory_ciphers = medium

# Cipher-Präferenz beim Server
tls_preempt_cipherlist = yes

>=TLSv1.2 schaltet TLS 1.0 und 1.1 ab. tls_preempt_cipherlist = yes lässt den Server die Cipher-Reihenfolge bestimmen, nicht den Client. Postfix sortiert AEAD-Ciphers (GCM, CHACHA20) automatisch nach vorn, PFS-Ciphers haben Vorrang. Die medium-Stufe schließt alles unterhalb von 128-Bit-Verschlüsselung aus.

Für den ausgehenden Versand ist smtp_tls_security_level = dane die beste Wahl. Damit prüft Postfix TLSA-Records per DANE. Gibt es keinen TLSA-Record, fällt Postfix auf opportunistisches TLS zurück. Wer zusätzlich MTA-STS auswertet, deckt auch Server ohne DNSSEC ab.

Dovecot

In /usr/local/etc/dovecot/conf.d/10-ssl.conf (FreeBSD) bzw. /etc/dovecot/conf.d/10-ssl.conf (Linux):

ssl = required
ssl_min_protocol = TLSv1.2
ssl_prefer_server_ciphers = yes
ssl_options = no_ticket

ssl = required erzwingt TLS für alle Verbindungen. ssl_min_protocol = TLSv1.2 schließt alte Protokolle aus. ssl_prefer_server_ciphers = yes gibt dem Server die Kontrolle über die Cipher-Wahl. no_ticket deaktiviert TLS Session Tickets, die PFS untergraben können wenn der Ticket-Key kompromittiert wird.

Eine explizite Cipher-Liste ist bei aktuellem OpenSSL nicht nötig. Die Defaults bevorzugen ECDHE mit AEAD. Wer es trotzdem einschränken will:

ssl_cipher_list = ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM:DHE+CHACHA20:!aNULL:!eNULL
ssl_cipher_suites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

ssl_cipher_list gilt für TLS 1.2, ssl_cipher_suites für TLS 1.3. Bei TLS 1.3 ist PFS immer aktiv, da gibt es keine Cipher-Suiten ohne Schlüsselaustausch mehr.

Testen

# Postfix (STARTTLS auf Port 25)
openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Postfix (Implicit TLS auf Port 465)
openssl s_client -connect smtp.kernel-error.de:465 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Dovecot (STARTTLS auf Port 143)
openssl s_client -starttls imap -connect imap.kernel-error.de:143 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Dovecot (Implicit TLS auf Port 993)
openssl s_client -connect imap.kernel-error.de:993 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

Entscheidend ist die Zeile Server Temp Key. Steht dort X25519, ECDH P-256 oder DH 2048, ist PFS aktiv. Mit OpenSSL 3.5+ und entsprechender Konfiguration sieht man dort auch X25519MLKEM768 für Post-Quantum-Schlüsselaustausch.

Siehe auch: Post-Quantum TLS für E-Mail

Fragen? Einfach melden.

Unsichere SSL/TLS-Verschlüsselungen im Firefox deaktivieren

Veraltet: Die hier beschriebenen about:config-Einstellungen existieren in aktuellen Firefox-Versionen nicht mehr in dieser Form. Moderne Browser deaktivieren unsichere Protokolle und Cipher automatisch. Dieser Beitrag ist veraltet.

Nach der NSA „Geschichte“ sollte klar sein dass man mehr denn je darauf achten sollte eine möglichst sichere Verschlüsselung zu nutzen. Als Benutzer kann man leider nicht immer Einfluss auf die Gegenseite, den Server nehmen. Um denn noch etwas mehr steuern zu können, dass eine „sichere“ Verschlüsselung benutzt wird kann jeder etwas an seinem Client schrauben.

Warum? Nun ja….. Nehmen wir als Beispiel den Firefox Web Browser. Dieser unterstützt viele verschiedene Protokolle, diese noch in vielen verschiedenen Version und noch mehr Chiffrensammlungen. Die Gegenseite sollte ebenso mehrere Verfahren unterstützten. Der Hintergedanke dabei ist dass sich beide Seiten so auf ein Verfahren einigen können welches beide unterstützen. Wenn man also nun seinen Client nur Verfahren anbieten lässt, welche man als sicher erachtet… Tja, dann können sich beide nur auf ein sicheres Verfahren einigen. OK, wenn der Server nun nichts „sicheres“ anbietet, werden sie sich nicht einig werden. An dem Punkt muss man sich dann fragen ob man wirklich „unsicher“ mit der Gegenseite sprechen möchte oder nicht!

Es ist doch hin und wieder erschreckend, welche Seite nur ~schlechte~ Chipher anbieten. Hier ist wohl, wie so oft per IPv6, ein Weg zur Lösung… Nachfragen. Also den Betreibern einer solchen Seite die Frage stellen, warum geht das nicht?!?! Manche Antworten sind echt lustig.

Ich denke es gibt drei große Punkte an denen man ansetzten kann:

1. Als kleinstes Protokoll TLS1
2. RC4-Stromchiffren komplett deaktivieren
3. Perfect Forwad Secrecy (PFS) vorschreiben

1. Sorgt dafür das der Browser nur noch als sicher bekannte Protokolle nutzt.
2. Wirft die als unsicher geltende RC4 Cipher Suite raus.
3. Sorgt dafür das selbst aufgezeichnete SSL/TLS Verbindungen in der Zukunft nicht so schnell gebrochen werden können, selbst wenn die Rechenleistung deutlich zunimmt.

Im Firefox lässt sich alles schnell und sehr einfach über die Seite: about:config einrichten.

B.t.w.: TLS (Transport Layer Security) ist der Nachfolger, die Weiterentwicklung von SSL (Secure Sockets Layer). Wir sprechen also besser nur von TLS, oder? Zurück zum Text…

1. TLS Version 1.0 als kleinstes unterstütztes Protokoll.
Unter der about:config Seite in der Suche nach security.tls.version suchen. Hier den Wert security.tls.version.max auf 3 und den Wert security.tls.version.min auf 1 setzten.

2. RC4 Cipher Suite deaktivieren.
Wieder über die Suche der about:config Seite nach rc4 suchen. Nun bei allen angezeigten Zeilen den Wert auf false setzten.

3. Perfect Forwad Secrecy (PFS) vorschreiben
Erraten, about:config und die Suche benutzen. Gesucht wird security.ssl3…. Bei den Suchergebnissen nun alle Werte auf false setzten bei denen nicht ECDHE, DHE oder RC4 (wobei die RC4 „Jungs“ sollten ja bereits aus sein) in der Bezeichnung steht.

Seine Einstellungen kann man nun am besten prüfen auf: https://www.ssllabs.com/ssltest/viewMyClient.html

Ach ja…. Die Seite https://www.ausweisapp.bund.de/ kann spannenderweise nicht mehr aufgerufen werden, wenn man diese sicheren Einstellungen in seinem Browser vorschreibt. Lustig, hm?


U-P-D-A-T-E

Wem das alles etwas zu hart ist, der kann bei security.ssl3 den Wert: security.ssl3.rsa_aes_256_sha auf true lassen/setzten. Dieses würde sich zwar vielleicht mit steigender Rechenleistung entschlüsseln lassen. Ist aber aktuell noch recht sicher und wird von mehr Webseiten angeboten als nur auf Diffie Hellman zu setzten.

Oh ja, was man Serverseitig tun könnte findet sich hier…

 

Zum Dumm, zum Zum: Eine humorvolle Reflexion

Na, mal wieder Lust auf etwas aus der: „Mein Gott, van de Meer!“ Ecke? OK…
Ich werfe also gerade einige Domains auf einen neuen DNS Server. Alles prima, nur saugt sich der Slave die Zonen nach einer Änderung nicht vom Master. Ich teste alles durch renne wild umher und gehe schon anderen Leuten auf den Sack. Bis mir jemand sagt… Kommen die Notifys vielleicht noch vom alten Server? Der PTR von der IPv4 Adresse ist….. Gott bin ich doof. Mein Gott bin ich blöde…

Der neue DNS Server hat mehrere IPv4 Adressen. Der Bind hört natürlich auf eine, nur ist es nicht die primäre IPv4 Adresse des Servers. Der Bind schickt folglich die Notifys über eine andere IPv4 Adresse zum Slave. Der denkt sich… Ok tolle Info aber ich soll auf ne andere Adresse hören. Also interessiert er sich nicht und zieht sich die Zone nicht. Ist ja ich richtig so!

Ich Wurst habe nämlich vergessen dem Bind zu sagen dass er bitte einfach alles über eine bestimmte IPv4 Adresse versenden soll. Ich muss den Bind im Grunde an eine ausgehende IP Adresse binden.
Kann Bind natürlich, schon alleine wegen IPv6. Denn da hat man ja schnell mehrere Adressen.
Nun kann man dem Bind viele verschiedene Vorgaben machen, wie er denn bitte den Weg nach draußen zu nehmen hat. Man kann sagen über welche IP Adresse er selbst anfragen rausschicken soll, über welche Adresse er bitte die Zonen durchreichen soll und auch über welche Adresse er das Notify an den Slave schicken soll.

options {
......
transfer-source 1.2.3.4;
notify-source 1.2.3.4;
query-source 1.2.3.4;
......
};

Alles einfach in den Optionsblock und fertig ist:

So einfach kann es sein, WENN MAN DARAN DENKT! Damit bewegt sich Bind fast nur noch über die angegebene Adresse nach draußen. Man bin ich blöde und wieviel Zeit ich damit wieder verbrannt habe *heul*!

Fragen? Einfach melden.

Contabo VPS

Lange habe ich nach einem ordentlichen Anbieter für einen neuen vServer gesucht. Dabei galt es folgende Kriterien zu erfüllen:

– Min. 2 IPv4 Adressen
– Ein kleines IPv6 Netz
– Unbegrenzter Traffic
– Min. 100Mbit/s Anbindung
– Min. 2 CPUs
– Min. 4 GB RAM
– Min. 200 GB HDD
– Linux als OS

Natürlich habe ich zuerst die Großen abgeklappert.

– 1und1 kein IPv6 (warum nicht? Ich meine 2014 HALLO!?!?)
– Strato nur EINE IPv6 Adresse (Ö_ö eine IPv6 Adresse…. eine?)
– Host Europe kein IPv6 bei den vServer nur bei den Root Server EINE (tz..)
– 1blue kein IPv6
– Server4you kein IPv6 beim vServer, sonst soll es wohl gehen…
– Serverloft… Joar, die Kosten sind mir zu hoch. Sind aber auch keine vServer.
– usw. usw. usw…

IPv6 scheint noch immer ein größeres Problem zu sein, ist nicht voll integriert oder ist (wie auch meherer IPv4 Adressen) hochpreisigen Produkten vorbehalten.

Dann bin ich auf Contabo gestoßen. Ich war Opfer der Werbung im Linux Magazin 🙁 Preis/Leistung sah dabei einfach zu gut aus. Daher habe ich angerufen. Ohne lange Hoteline sprach ich mit einem Menschen. Diesem stellte ich direkt meine Fragen und er konnte sie überraschenderweise direkt und sicher beantworten. Mit sicher meine ich, dass man nicht das Gefühl hatte er würde es irgendwo nachlesen oder wäre nach einer kurzen Schulung auf die Hotline losgelassen worden. Nein, es war wirklich gut!

Natürlich habe ich abschließend die Frage gestellt wie es klappt dass die angegebene Leistung so gut ist, der Support so schön zu funktionieren scheint und die Ausstattung und Randbedingungen ebenfalls so gut erscheinen. Nach hörbarem Schmunzeln bekam ich die Antwort: Das würde oft gefragt…. Ich müsse es so sehen. Contabo selbst stellt wirklich nur die Hardware und die Infrastruktur. Für das System selbst ist man selbst verantwortlich. Wenn es da mal Probleme gibt, könnte der Support zwar helfen diese wäre dann aber Kostenpflichtig (er meinte damit wenn man seine Kiste mal zerfriemelt hat). Man müsse schon wissen was man tut, dieses würden Contabo bei seinen Produkten einfach voraussetzten.

Schien also genau das zu sein was ich gesucht habe! Daher habe ich bestellt… Wobei ich genau eine solche Antwort von jedem Root-Server erwarten würde.

Alles ging schnell und für mich verständlich online. Ich bekam eine E-Mail mit der Bitte Geld zu überweisen (wer konnte damit nur rechnen. ). Kurz nach meiner Überweisung flatterten bereits die Zugangsdaten in mein Postfach.

Wie bei der Bestellung angeklickt hatte ich schon eine zweite IPv4 Adresse und konnte die PTR-Records flott im Webmenü eintragen. Um die PTR-Records der IPv6 Adressen zu ändern musste ich kurz den Support per E-Mail bemühen. Freitags um 23:36 Uhr habe ich ihn angemailt als ich morgens aufgewacht bin hatte ich schon die Bestätigung in meinem Postfach. Das System selbst ist genau wie bestellt und hat mehr Leistungsreserven als erwartet. Ich habe 8GB Arbeitsspeicher, 400Gb Festplattenplatz und zwei CPUs mit 3,4GHz. Auf der Webseite war nur etwas von 3,2GHz zu lesen. Ok ok… die paar MHz machen den Braten jetzt nicht fett, das es Core I7 CPUs sind hat mich denn noch überrascht!

Ich habe natürlich Speicher und CPU mal mit Arbeit beworfen um zu testen ob es nicht nur Schein ist. Alles prima…. Die Storage Anbindung ist ja gerne mal etwas zu genau auf den Punkt dimensioniert. Bei meinem System kann ich nicht klagen. Performance und I/Os sind wunderbar und mehr als ausreichend.

100Mbit/s sind auch 100Mbit/s… Wobei man hier auf das „Kleingedruckte“ achten muss: Keine zusätzlichen Kosten durch Traffic (bei einem Durchschnittsverbrauch über 40 Mbit/s in einem zusammenhängenden Zeitraum von mindestens 5 Tagen erfolgt eine Umstellung der Anbindung auf 10 Mbit/s).

Zu dem Thema muss ich dann wohl mal eine kleine Auswertung vom Support anfordern. Sollte doch machbar sein, oder?

Ob mich dieses noch ärgert, werde ich herausfinden. Ob mich noch mehr ärgert wird sich zeigen!

Fragen? Einfach melden.

Grobe Schnitzer im der DNS Konfiguration testen.

Da habe ich doch gerade noch einen Tipp bekommen (danke Felix). Möchte man „mal eben“ seine DNS Konfiguration inkl. Mailserver testen wird einem ein solcher Test über die Webseite www.dnsinspect.com angeboten.

Der Test geht natürlich jetzt nichts ins absolute Detail aber die ganz groben Fehler findet er dann schon. Auch so Dinge wie PRT – HELO/EHLO – Hostname oder postmaster und abuse Adresse. Zu gesprächige Nameserver usw. usw. usw…

Einfach zum Spaß mal eure Domain reinwerfen und schauen was passiert .-)

http://www.dnsinspect.com/kernel-error.de

Fragen? Einfach melden.

Schönes Tool zum Testen / Prüfen seines SPF oder DMARC RECORDS

Die Webseite https://dmarcian.com stellt zwei sehr schöne Möglichkeiten zur Verfügung um seinen >> DMARC-RECORD << und oder seinen >> SPF-RECORD << zu testen.

Am besten gefällt mir dabei der SPF Test, denn dieser sammelt auch gleich alle nötigen DNS Lookups zusammen und visualisiert sie einem recht ansprechend.

Bunte Bilder *wwwööööööööööhhhhhhhhhyyyyyyyyy*

Ja, wenn es hilft schick mir eine E-Mail und ich sage dir ob deine Konfiguration sauber ist.

Viel Spaß!

Siehe auch: SPF-Record einrichten

Fragen? Einfach melden.

VLAN mit den iproute Tool ip.

Früher also man noch ifconfig nutzte, da gab es vconfig um VLANs auf einem Linux Rechner zu konfigurieren. Wenn ich mich richtig erinnere ist die Verwendung von ifconfig inzwischen unter Strafe gestellt.

Also BITTE nutzt ip. Es kann mehr, es zeigt auch alles an und es ist viel einfacher. Vertraut mir…

Hier einmal kurz VLAN mit command ip!

Anlegen des VLAN Interfaces:

$ ip link add link eth0 name eth0.10 type vlan id 10

Vergeben eine IPv4 Adresse auf dieses neue VLAN Interface:

$ ip -4 addr add 192.168.10.1/24 dev eth0.10

Aktivieren des neuen VLAN Interfaces:

$ ip -4 addr add 192.168.10.1/24 dev eth0.10

Damit haben wir nun ein VLAN Interface mit der VLAN ID 10 und der IPv4 Adresse 192.168.10.1 und der Netzmaske 255.255.255.0. Die .10 im Interfacenamen hat nichts mit der VLAN ID zutun. Ich nenne es nur gerne so um es für mich einfacher zu machen.

Ein Tool, sinnvoll aufgebaut, für fast alles nutzbar, funktioniert, geil. Benutzt es.

Fragen? Einfach melden.

Version bei BIND nicht anzeigen lassen: Schritt-für-Schritt-Anleitung

Es gibt viele gute Gründe warum man die Version seines DNS Servers unkenntlich machen sollte. Viele Roboter und noch mehr Scriptkiddies suchen nach Versionen mit Sicherheitslöchern. Natürlich sollte man seine Version immer auf dem aktuellen Stand der Sicherheitsupdates halten… Denn noch kommt es vor dass man auch mal ein paar Tage auf einer „kaputten“ Version läuft. Dieses muss man ja nicht jedem unter die Nase reiben, hm?

Beim Bind ist es extrem einfach. Man reißt einfach mit dem Editor seiner Wahl die named.conf auf und wandert zum Options-Bereich. Dort ergänst man einfach die Option version:

options
{

[Zeugs und andere Optionen]
version "unknown";
[noch mehr Zeugs und andere Optionen]

};

Nun einfach Bind seine Konfiguration neu laden lassen:

$ rndc reconfig

Schon wird keine Version mehr angezeigt. Testen kann man alles wie immer mit dig:

$ dig -c CH -t txt version.bind +short @dns1.telekom.de
"SORRY"

Sorry finde ich gut liebe Telekom.

Bock auf ein kleines Spiel? Wer mir zuerst sagt auf welchem Schiff mein primärer DNS Server stehen müsste, der bekommt eine Dose Dr Pepper Cola geschenkt.


Update 26.11.2013 19:53

Glückwunsch Dome, du bekommst die Dose. Bekomme ich ein Foto wie alles ausschaut nachdem DHL das Paket (oder besser Maxibrief *grübel*) bei dir abgegeben hat? Ich löse aber mal nicht, dann können die anderen noch mitspielen!

Siehe auch: DNSSEC einrichten

Fragen? Einfach melden.

Ping6 funktioniert nicht auf fe80-Adresse: Fehlerbehebung

Ja, die liebe fe80 Adressen! Wer schon mal ganz unbedarft folgendes in seine Konsole hämmert:

$ ping6 fe80::20c:42ff:fe72:2ba6
connect: Invalid argument

Wundert sich sicher im ersten Moment über die freche Antwort: „connect: Invalid argument“. ABER das ist absolut richtig. Denn wenn man mehrere Netzwerkkarten in seinem Rechner verbastelt hat, dann hat man ebenfalls mehrere fe80 link local Adressen. Nämlich mindestens eine pro Netzwerkkarte. Damit sollte es jetzt schon klingeln, hm? Noch nicht? Na woher soll das Paket den bitte wissen über welche der Netzwerkkarten es denn den Weg zur angepingten Adresse nehmen soll?!?!? Genau überhaupt nicht! Daher muss das Interface welches als „Ausgang“ genutzt werden soll immer mit angegeben werden.

$ ping6 fe80::20c:42ff:fe72:2ba6%eth0
PING fe80::20c:42ff:fe72:2ba6%eth0(fe80::20c:42ff:fe72:2ba6) 56 data bytes
64 bytes from fe80::20c:42ff:fe72:2ba6: icmp_seq=1 ttl=64 time=0.323 ms
--- fe80::20c:42ff:fe72:2ba6%eth0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.323/0.323/0.323/0.000 ms

Unter Linux gibt man einfach %NIC-Name an und unter Windows einfach %NIC-ID:

C:\>ping -6 fe80::20c:42ff:fe72:2ba6%3

Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6%3 mit 32 Bytes Daten:
Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms
Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms

Ping-Statistik für fe80::20c:42ff:fe72:2ba6%3:
Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\>

Wobei ich die Meldung eines Microsoft Windows doch schnell etwas verwirrend finde. Denn hier gibt es nur die Rückmeldung dass das Zielnetz nicht erreichbar ist. Was ja im Grunde korrekt ist, nur grenzt es leider den Fehler nicht so schön ein!

C:\>ping -6 fe80::20c:42ff:fe72:2ba6

Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6 mit 32 Bytes Daten:

Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.

Ping-Statistik für fe80::20c:42ff:fe72:2ba6:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),

C:\>

Japp, so einfach kann es sein.

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑