Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
netzwerke:ipsec [2007/10/29 12:40] – st | netzwerke:ipsec [2021/04/14 16:15] (aktuell) – st |
---|
| ====== IPSec ====== |
| [[wpde>IPsec]] ist eine weit verbreitete Lösung für [[security:VPNs]]. IPSec ist ein Framework welches Mechanismen vorschreibt und auf Schicht 3 (Vermittlungsschicht) des [[netzwerke:iso:osi-modell|ISO/OSI-Modells]] läuft. Daher sind viele Einstellungen möglich und Komplexität erhöht bekanntlich die Schwierigkeit der Konfiguration. Zusätzlich kann es zu Problemen aufgrund unterschiedlicher Implementierungsgrade der Hersteller. |
| |
| * **Entscheidung zwischen AH oder ESP:** (Beide zusammen sind möglich aber unüblich) |
| * **[[wpde>Authentication Header Protocol|AH (Authentication Header)]]**: Es identifiziert die Datenquelle und sichert die //Datenintegrität durch Authentifizierung// zu, liefert aber //keine Vertraulichkeit (Verschlüsselung) der Daten//. Es muss immer erst ein Security Agreement (SA) ausgehandelt werden. Der AH-Header wird zwischen dem IP-Datagramm und dem IP-Header eingefügt. //AH ist bei [[netzwerke:NAT (Network Address Translation)|NAT]] nicht möglich//. |
| * **[[wpde>IPsec#Encapsulating_Security_Payload_.28ESP.29|ESP (Encapsulating Security Payload)]]**: Es soll die //Authentizität// der übertragenen Pakete sicherstellen und die //Daten durch Verschlüsselung sichern//. ESP versucht alle möglichen, nicht variablen Felder eines IP-Datagramms zu schützen. Es sind lediglich Felder ausgeschlossen, die sich auf dem Weg eines IP-Pakets durch ein IP-Netz durch die Router verändern können. |
| * **Wahl der [[:Hash-Funktion|Hash]]- und [[security:Verschlüsselungsalgorithmen]]**: hier kann man sich an der aktuellen Situation orientieren, aktuell sind (noch) SHA-1 (MD5 nicht mehr) als [[:Hash-Funktion|Hash]] sinnvoll, für die Verschlüsselung z.B. AES, Blowfish und evtl. 3DES. |
| * **IKE oder vorher ausgetauschte Schlüssel** |
| * **IKE oder ISAKMP** bietet die sichere Schlüsselaushandlung über unsichere Netze und sorgt zusätzlich für eine periodische Änderung des Schlüssels |
| * **vorher ausgetauschte Schlüssel** (Pre-shared-keys) müssen allen Kommunikationspartnern bekannt sein und auch entsprechend gesichert werden. Bei Verlust müssen alle Schlüssel ausgetauscht werden. Daher nur in wenigen Fällen sinnvoll. |
| * **Tunnel- oder Transportmodus:** |
| * **Tunnelmodus**: Im Tunnel Mode wird das ursprüngliche IP–Paket einfach in ein neues Paket eingepackt. Der ursprüngliche (innere) IP-Header wird erst wieder verwendet, wenn das empfangende Security-Gateway (das Tunnelende auf der Empfangsseite) die IP-Kapselung entfernt hat und das Paket dem eigentlichen Empfänger zustellt. Im Tunnelmodus sind //Gateway-zu-Gateway-, Peer-zu-Gateway- oder Peer-zu-Peer-Verbindungen// möglich. Ein Vorteil des Tunnelmodus ist, dass bei der Gateway-zu-Gateway-Verbindung nur in die Gateways (Tunnelenden) IPsec implementiert und konfiguriert werden muss. Angreifer können dadurch nur die Tunnelendpunkte des IPsec-Tunnels feststellen, nicht aber den gesamten Weg der Verbindung. |
| * **Transportmodus**: Der IPsec-Header wird zwischen dem IP-Header und den Nutzdaten eingefügt. Der IP-Header bleibt unverändert und dient weiterhin zum Routing des Pakets vom Sender zum Empfänger. Der Transportmodus wird verwendet, wenn die „kryptographischen Endpunkte“ auch die „Kommunikations-Endpunkte“ sind. Nach dem Empfang des IPsec-Paketes werden die ursprünglichen Nutzdaten (TCP/UDP-Pakete) ausgepackt und an die höherliegende Schicht weitergegeben. Der Transportmodus wird v. A. für //Host-zu-Host//- oder //Host-zu-Router-Verbindungen// verwendet z. B. zu Netz-Management-Zwecken. |
| * **Main oder Quick (Aggressive-)Modus**: |
| * **Main-modus**: Er ist dem Quick oder Aggressive-modus aus Sicherheitserwägungen vorzuziehen. |
| * **Quick- oder (Aggressive-)Modus**: Die Schritte des Main-modus werden auf drei zusammengefasst. Die Übertragung der [[:Hash-Funktion|Hashwerte]] der PSKs werden im Klartext übertragen, die Sicherheit des Verfahrens ist also eng mit der Stärke des pre shared keys und des [[:Hash-Funktion|Hashverfahrens]] gekoppelt. **Wenn hier nicht die maximale Schlüssellänge ausgewählt oder ein unsicher [[:Hash-Funktion|Hash]]-Algorithmus gewählt wurde, hat man keine Sicherheit mehr**. Wenn man hingegen PSK einsetzen will und vorher der Initiator nicht bekannt ist oder die Einstellungen bereits bekannt sind, könnte jedoch der Einsatz des aggressive-modus Sinn machen. |
| |
| |
| :!: Manche Konfigurationen sind anfällig für Angriffe: |
| - ESP im Tunnelmodus mit "confidentiality only" oder mit Integritätsprüfung durch höhere Protokolle. |
| - manche Konfigurationen mit AH. |
| Siehe [[http://marc.info/?l=bugtraq&m=111566201610350&w=2|NISCC Vulnerability Advisory IPSEC - 004033]]. |
| |
| ===== Links ===== |
| * [[http://www.unixwiz.net/techtips/iguide-ipsec.html|An Illustrated Guide to IPsec]] |
| * [[http://www.securityfocus.com/infocus/1821|Penetration Testing IPsec VPNs]] |
| * [[http://www.microsoft.com/germany/technet/sicherheit/newsletter/ipsec.mspx|MSTechnet: Schützen von Netzwerken mit IPSec]] |
| * [[http://www.onlamp.com/pub/a/bsd/2002/12/26/FreeBSD_Basics.html|Cryptosystems: Configuring IPSec]] |
| * [[http://www.onlamp.com/pub/a/bsd/2003/01/09/FreeBSD_Basics.html|Cryptosystems: Debugging IPSec]] |
| * [[http://www.unixwiz.net/techtips/iguide-ipsec.html|An Illustrated Guide to IPse]] |
| * [[http://www.unixwiz.net/techtips/iguide-ipsec.html|IP-Sec-Guide]] |
| * [[http://www.heise.de/netze/artikel/81851|Sichere Verteilung - IP-Sec Geschützte Multicast-Kommunikation]] |
| |
| |
| ===== Clients ===== |
| |
| * [[http://www.shrew.net/software|Shrew Soft VPN Client]] - Opensource-Client für windows |
| |
| |
| |
| ===== strongswan Tunnel ===== |
| |
| <file> |
| # ipsec.conf |
| |
| # PSK -> /etc/ipsec.secrets |
| |
| config setup |
| # strictcrlpolicy=yes |
| # uniqueids = no |
| charondebug="cfg 2, chd 2, esp 2, ike 2, knl 2, lib 2, net 2, tls 2" |
| |
| conn CONNECTION1 |
| |
| auto=start |
| authby=secret #this specifies how the connection is authenticated |
| |
| type=tunnel #the type of connection |
| left=gw1.firma1.tld #This is the public ip address of server A |
| leftsubnet=1.2.3.4/24 #This is the subnet/private ip of server A |
| right=gw2.firma2.tld #This is the public ip address of server B/remote server |
| rightsubnet=5.6.7.8/24 #This is the subnet/private ip of server B |
| keyexchange=ikev2 #Internet key exchange version |
| ike=aes256-sha256-modp2048 #Internet key exchange, type of encryption (modp2048 = group14) |
| ikelifetime=86400s #Time before re-authentication of keys |
| lifetime=3600s |
| esp=aes256-sha256-modp2048 #Encapsulation security suite of protocols |
| </file> |
| |
| # generate PSK: dd if=/dev/urandom count=1 bs=32 2>/dev/null | base64 |
| /etc/ipsec.secrets |
| <file> |
| $left $right : PSK "this_is_the_PSK_change_it!" |
| </file> |
| |
| ==== Routing aktiveren ==== |
| |
| Wenn routing nötig: |
| <code bash> |
| # cat >> /etc/sysctl.conf << EOF |
| net.ipv4.ip_forward = 1 |
| net.ipv4.conf.all.accept_redirects = 0 |
| net.ipv4.conf.all.send_redirects = 0 |
| EOF |
| </code> |
| sysctl -p |
| |
| ==== Verwaltungsbefehle ==== |
| |
| sudo ipsec restart |
| |
| sudo ipsec statusall |
| |
| sudo ipsec status |
| |