IPv4 – IPv6 / IPv6 – IPv4 Gateway / Proxy

Um IPv6 Webseiten per http oder https für IPv4 Anfragen oder IPv4 Seiten für IPv6 Anfragen erreichbar zu machen, bietet sich ein Linux Gateway / Proxy an. Linux, in diesem Fall ein CentOS 7 System, bietet u.a. folgende Möglichkeiten ein solches Gateway bzw. einen solchen Proxy Server zu realisieren:

socat

Socat (für SOcket CAT) ist ein mächtiges Tool, das zwei bidirektionale Byte-Streams anlegt und Daten zwischen diesen überträgt. Datenkanäle können Dateien, Pipelines, Geräte (Terminal oder Modem, etc.) oder Sockets (Unix, IPv4, IPv6, Raw, UDP, TCP, SSL) sein. Zunächst muss das Paket „socat“ per yum installiert werden:

[root@proxy ~]# yum install socat -y

Dann bitte folgendes Verzeichnis anlegen:

[root@proxy ~]# mkdir /etc/socat

Jetzt werden zwei Shell Skripte erzeugt. Ein Skript für die Umleitung des Ports 80 und ein Skript für die Umleitung des Ports 443. In beiden Fällen wir eine IPv4 Anfrage an einen IPv6 Webserver direkt weitergeleitet.

[root@proxy ~]# vi /etc/socat/80_socat
#!/bin/bash
# /etc/socat/80_socat
# Socat-Script Port 80

# TCP Port 80
/usr/bin/socat TCP4-LISTEN:80,fork TCP6:[IPv6-Adresse des Zielrechners]:80
[root@proxy ~]# vi /etc/socat/443_socat
#!/bin/bash
# /etc/socat/443_socat
# Socat-Script Port 443

# TCP Port 443
/usr/bin/socat TCP4-LISTEN:443,fork TCP6:[IPv6-Adresse des Zielrechners]:443

Die beiden soeben erzeugten Dateien ausführbar machen:

[root@proxy ~]# chmod 755 /etc/socat/80_socat
[root@proxy ~]# chmod 755 /etc/socat/443_socat

Jetzt wird ein für jeden der beiden Ports ein Dienst generiert.

1. Port 80

[root@proxy ~]# adduser socat -s /sbin/nologin
[root@proxy ~]# vi /etc/systemd/system/80_socat.service
[Unit]
Description=socat Service 80
After=network.target

[Service]
Type=simple
User=root
ExecStart=/etc/socat/80_socat
Restart=on-abort

[Install]
WantedBy=multi-user.target

2. Port 443

[root@proxy ~]# vi /etc/systemd/system/443_socat.service
[Unit]
Description=socat Service 443
After=network.target

[Service]
Type=simple
User=root
ExecStart=/etc/socat/443_socat
Restart=on-abort

[Install]
WantedBy=multi-user.target

Der systemctl Daemon muss neu geladen werden um die beiden „Socat-Dienste“ starten zu können.

[root@proxy ~]# systemctl daemon-reload
[root@proxy ~]# systemctl start 80_socat
[root@proxy ~]# systemctl start 443_socat

Damit diese Dienste beim Start des Rechners geladen werden:

[root@proxy ~]# systemctl enable 80_socat
[root@proxy ~]# systemctl enable 443_socat

Bei IPv4 Anfragen für Port 80 und 443 werden diese nun auf einen IPv6 Webserver umgeleitet. Natürlich kann socat auch mit anderen Ports umgehen!

Wichtig: Im Apache Log des Ziel-Servers taucht nur die IPv6 Adresse des Quell-Servers auf!

Apache als Reverse Proxy

Der Apache HTTP Server der Apache Software Foundation und einer der meistbenutzten Webserver im Internet kann ebenfalls als Reverse Proxy eingesetzt werden.

Zunächst müssen folgende Pakete installiert werden:

[root@proxy ~]# yum install httpd mod_ssl mod_proxy_html

Das Modul „mod_proxy_html” schaltet das Rewriting für HTML links an damit diese funktionieren können.

[root@proxy  ~]# cp /usr/share/doc/httpd-2.4.6/proxy-html.conf /etc/httpd/conf.d/

Jetzt wird eine Reverse Proxy Konfiguration benötigt. Dazu wird die Datei /etc/httpd/conf.d/reverse-proxy.conf mit folgendem Inhalt erzeugt:

#Port 80
ProxyRequests Off
ProxyPass / http://[IPv6-Adresse des Zielrechners]:80 connectiontimeout=5 timeout=30
ProxyPassReverse / http://[IPv6-Adresse des Zielrechners]:80

#Port 443
ProxyRequests Off
ProxyPass / https://[IPv6-Adresse des Zielrechners]:443 connectiontimeout=5 timeout=30
ProxyPassReverse / https://[IPv6-Adresse des Zielrechners]:443

Damit der Apache Dienst beim Start des Rechners geladen werden kann:

[root@proxy ~]# systemctl enable httpd

Den httpd Daemon starten:

[root@proxy ~]# systemctl start httpd

Die Datei /etc/httpd/conf.d/ssl.conf sowie die SSL Zertifikate im Verzeichnis /etc/pki des Ziel-Servers sollten auf den Proxy-Server exakt so in Kopie vorliegen.

Squid als Reverse Proxy

Squid kann nicht nur als Forward Proxy Server und Web-Cache, sondern auch als Reverse Proxy eingesetzt werden. Vor allem aufgrund seiner guten Skalierbarkeit und der ausgezeichneten Unterstützung für HTTP/HTTPS ist er für die Aufgabe prädestiniert.

Squid Paket installieren:

 [root@proxy ~]# yum install squid

Damit der Proxy Dienst beim Start des Rechners geladen werden kann:

[root@proxy ~]# systemctl enable squid

Die entsprechend angepasste Squid Proxy Konfiguration wird nun benötigt. Die Datei /etc/squid/squid.conf sollte dann wie folgt aussehen:

# Recommended minimum configuration:
#
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7       # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
acl SSL_ports port 443          # https
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT

# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports
# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports
# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager
#http_access deny to_localhost

# Squid normally listens to ports 80 and 443
http_port 80 accel defaultsite=www.domain.de vhost
https_port 443 accel cert=/etc/pki/tls/certs/domain.de.pem key=/etc/pki/tls/private/domain.de.key.pem cafile=/etc/pki/CA/certs/domain.de.ca.pem defaultsite=www.domain.de vhost

# Uncomment and adjust the following to add a disk cache directory.
cache_dir ufs /var/spool/squid 500 16 256
# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid

# Add any of your own refresh_pattern entries above these.
#
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

# First (HTTP) Peer
cache_peer [IPv6-Adresse des Zielrechners] parent 80 0 no-query originserver login=PASS name=80 

# Second (HTTPS) Peer
cache_peer [IPv6-Adresse des Zielrechners] parent 443 0 no-query originserver  ssl sslflags=DONT_VERIFY_PEER login=PASS connection-auth=off name=443

#ACL proxy
acl proxy_acl dstdomain .domain.de .domain.com
http_access allow proxy_acl 
cache_peer_access 443 allow proxy_acl 
cache_peer_access 80 allow proxy_acl 

# Additional ACL definitions
acl manager proto cache_object 
acl purge method PURGE 
acl CONNECT method CONNECT

# Restrictions
http_access allow manager localhost 
http_access deny manager 
http_access allow purge localhost 
http_access deny purge 
http_access deny all

# Disable caching
# cache deny all 

# memory cache size
cache_mem 256 MB

# define hostname
visible_hostname proxy.domain.de

#logformat <name> <format specification>
logformat apache %{%d.%m %H:%M:%S}tl  %>a %Ss %ru

#access_log 
access_log  /var/log/squid/access.log apache

cache_mgr webmaster@domain.de

Wichtig ist, dass alle SSL Zertifikate (Ziel-Server-Zertifikat, Ziel-Server-Zertifikat Schlüssel und CA Zertifikat) im Verzeichnis /etc/pki des Ziel-Servers auf den Proxy-Server wieder exakt so in Kopie vorliegen. Die Pfadangaben und Namen der Zertifikat Dateien in der Zeile unten müssen auf dem Proxy Server korrekt vorliegen.

https_port 443 accel cert=/etc/pki/tls/certs/domain.de.pem key=/etc/pki/tls/private/domain.de.key.pem cafile=/etc/pki/CA/certs/domain.de.ca.pem defaultsite=www.domain.de vhost

Squid starten und testen:

[root@proxy ~]# systemctl start squid

Microsoft PKI • NPS • RADIUS • WLAN 802.1x • OCSP

Microsoft Public Key Infrastructure • Network Policy Server • RADIUS • WiFi 802.1x • OCSP

Zunächst eine kurze Darstellung des Prozesses zum Einbuchen in das WLAN. Als Authentifizierung Methode wird EAP-TLS -Zertifikat-basiert eingesetzt.

Die Methode ermöglicht die Clientauthentifizierung mithilfe von Zertifikaten. EAP-TLS erfordert, dass für den Active Directory integrierten NPS-Server (RADIUS) ein Server-Zertifikat von der AD Zertifizierungsstelle (CA) ausgestellt wird. Diesem Zertifikat müssen die AD Clients vertrauen.

Beim PEAP-Authentifizierungsvorgang zwischen dem PEAP-Client und dem Authentifikator gibt es zwei Phasen. In der ersten Phase wird ein sicherer Kanal zwischen dem PEAP-Client und dem authentifizierenden Server eingerichtet. In der zweiten Phase wird die EAP-Authentifizierung zwischen dem PEAP-Client und dem Authentifikator bereitgestellt.

In der ersten Phase der PEAP-Authentifizierung wird der TLS-Kanal zwischen dem PEAP-Client und dem Netzwerkrichtlinienserver erstellt. Die folgenden Schritte veranschaulichen, wie dieser TLS-Kanal für PEAP-Drahtlosclients erstellt wird.

  1. Der PEAP-Client wird einem Drahtloszugriffspunkt zugeordnet, der als RADIUS-Client für einen Server mit NPS konfiguriert ist. Eine IEEE 802.11-basierte Zuordnung ermöglicht eine Authentifizierung mit einem (automatisch) vorinstallierten Schlüssel, bevor eine sichere Zuordnung zwischen dem PEAP-Client und dem Zugriffspunkt erstellt wird.
  1. Nachdem die IEEE 802.11-basierte Zuordnung erfolgreich zwischen dem Client und dem Zugriffspunkt erstellt wurde, wird die TLS-Sitzung mit dem Zugriffspunkt ausgehandelt.
  1. Nachdem die Authentifizierung auf Computerebene zwischen dem PEAP-Drahtlosclient und dem Netzwerkrichtlinienserver erfolgreich abgeschlossen wurde, wird die TLS-Sitzung zwischen beiden ausgehandelt. Der bei dieser Aushandlung abgeleitete Schlüssel wird zum Verschlüsseln der gesamten nachfolgenden Kommunikation verwendet, einschließlich der Authentifizierung des Netzwerkzugriffs, was dem Benutzer das Herstellen einer sicheren Verbindung mit dem Netzwerk ermöglicht.

Die gesamte EAP-Kommunikation, einschließlich der EAP-Aushandlung, erfolgt über den TLS-Kanal und stellt die zweite Phase der PEAP-Authentifizierung dar. Nachdem der TLS-Kanal zwischen dem RADIUS Server und dem PEAP-Client erstellt wurde, übergibt der Client die Anmeldeinformationen in Form eines Zertifikats über den verschlüsselten Kanal an den Netzwerkrichtlinienserver (RADIUS).

Der Zugriffspunkt leitet Nachrichten nur zwischen dem Drahtlosclient und dem RADIUS-Server weiter. Der Zugriffspunkt (oder eine Person, die diesen überwacht) kann diese Nachricht nicht entschlüsseln, da es sich nicht um den TLS-Endpunkt handelt.

Der Netzwerkrichtlinienserver authentifiziert den Benutzer und den Clientcomputer mit dem Authentifizierungstyp EAP-TLS (Smartcard oder Zertifikat).

skizze

  1. Der Client fordert Zugriff auf Netzwerkdienste an. Es startet die Verbindung nach Auswahl eines verfügbaren WLAN-Netzwerks durch einen Benutzer oder automatisch nach Erkennung eines zuvor bereits konfigurierten Netzwerks.
  2. Nach dem Empfang der Anforderung durch den Zugriffspunkt wird sie zur Authentifizierung an den RADIUS-Server weitergeleitet.
  3. Der RADIUS-Server validiert den Benutzer Account mithilfe des Verzeichnisdienstes.
  4. Nach der Benutzerauthentifizierung bietet der Zugriffspunkt gemäß den Richtlinien und Zugriffsrechten, die vom RADIUS-Server vorgegeben werden, Zugriff auf das Netzwerk.

Zertifikate für AD-intergrierte Computer können per Gruppenrichtlinie und einer manuell angepassten Zertifikatsvorlage automatisch an alle Computer der Domäne verteilt. Mittels Filterung auf eine Sicherheitsgruppe können auch nur bestimmte Computer oder Benutzer automatisch mit Zertifikaten versorgt werden.

Ein Client Zertifikat kann jederzeit – temporär oder vollständig – widerrufen werden. Es wandert dann in die CRL (Certificate Revocation List). Sobald diese Liste „verteilt“ wurde, ist eine erneute Anmeldung des Clients über das WLAN nicht mehr möglich. Wird das Zertifikat beim Widerrufen als „geblockt“ gekennzeichnet kann es bei Bedarf jederzeit wieder aktiviert werden.

OCSP

OCSP ist ein Protokoll, das entwickelt wurde, um den Umgang mit gesperrten Zertifikaten zu vereinfachen. Das Online Responder Management beim Windows Server wird zum Verwalten für das OCSP (Online Certificate Status Protocol) benötigt.

Wenn ein Zertifikat gesperrt wird, wird diese Information in einer sogenannten CRL (Certificate Revocation List) veröffentlicht. Diese Listen werden in definierten Zeitabständen veröffentlicht. Anwendungen, die Zertifikate verarbeiten – also beispielsweise ein Web-Server für die Client-Authentifizierung –, können diese Listen herunterladen. Das Problem dabei ist der Spagat zwischen Aktualität und der Größe der Listen. Wenn größere Zertifizierungsstellen viele gesperrte Zertifikate beispielsweise von ehemaligen Mitarbeitern in der CRL haben, ist eine sehr kurze Aktualisierungsfrist lastintensiv.

OCSP erlaubt nun einzelne Anfragen zum Status von Zertifikaten, setzt also die Informationen der CRL in Einzelinformationen um, die für die Beantwortung dieser spezifischen Anforderungen benötigt werden. Beim Windows Server können dafür Arrays von mehreren Servern für die Beantwortung konfiguriert werden. Mit sogenannten Sperrkonfigurationen wird festgelegt, welche Anforderungen in welcher Weise beantwortet werden sollen.

Mac OS X Terminal mit seriellem USB Adapter

Um einen seriellen USB Adapter im Terminal Fenster von Mac OS X für den Consolen-Zugriff auf aktive Komponenten des Netzwerks nutzen zu können wird nur ein kleines Shell Script benötigt. In diesem Beispiel wird ein Digitus USB auf Seriell DB9 Adapter verwendet.

Nach dem Shell Script folgt noch ein alternatives AppleScript.

Um den Namen des entsprechenden seriellen USB Ports herauszufenden ist  z.B. der Befehl  ls -al /dev | grep tty.usb* hilfreich.

 

#!/bin/sh

#

getc ()

{

stty raw

tmp=`dd bs=1 count=1 2>/dev/null`

eval $1='$tmp'

stty cooked

}

clear

echo "Starting serial terminal.... "

echo ""

echo "!!! To quit the screen app, type control-A, then control-\ !!!"

echo ""

echo ""

echo "Strike any key to continue ... "

getc anychar

# Set serial usb port for terminal use

/usr/bin/screen /dev/tty.usbserial-FTHL5VRS 9600

Alternativ kann auch ein AppleScript verwendet werden:

tell application "Terminal"

do script with command "screen /dev/tty.usbserial-FTHL5VRS"

set number of rows ofwindow 1 to 100

set number of columns ofwindow 1 to 120

set background color ofwindow 1 to "black"

set normal text color ofwindow 1 to "yellow"

set custom title ofwindow 1 to "Serial Console"

end tell

Backup Shell Script Apache inkl. MySQL DB

Diese kleine Backupscript dient zur Sicherung von Dateien und Verzeichnissen eines Linux Rechners. In diesem Beispiel ist zusätzlich der Sicherung des Apache Webservers und der MySQL Datenbanken Rechnung getragen worden. Das Backup wird im Verzeichnis /root/bin als backup.sh erstellt.

Dieses Shell Script sicher die in der Variablen BDIRS angegeben Verzeichnisse. Ein externes (NAS, SAN, Netz-) Laufwerk wird unter /media gemountet ist. Hier werden das Backup als backup.tgz und die Datenbanken cloud und wordpress als cloud.sql und wordpress.sql gesichert.

#! /bin/sh

## Backup-Script: "Rechnername"

# Liste der zu sichernden Verzeichnisse definieren:

BDIRS="/root /home /etc /var/lib /var/www /var/log"

# Backup: Die oben definierten Verzeichnisse werden als backup.tgz in das Verzeichnis /media gesichert und komprimiert

/bin/tar  czvf "/media/Backup.tgz" $BDIRS

# DB Backup: Die Datenbanken werden ebenfalls in das Verzeichnis /media gesichert.

# Für "Passwort" das entsprechende Datenbank Passwort einsetzten.

/usr/bin/mysqldump --databases --opt -Q -uroot -pPasswort cloud > /media/cloud.sql

/usr/bin/mysqldump --databases --opt -Q -uroot -pPasswort wordpress > /media/wordpress.sql

## Anmerkung: Restore des Backups

##  /bin/tar -xzvf /media/backup.tgz

## DB Restore. Für "Passwort" das entsprechende Datenbank Passwort einsetzten!

## /usr/bin/mysql -u root -pPasswort< cloud.sql

## /usr/bin/mysql -u root -pPasswort < wordpress.sql

Das Script kann einfach dahin gehend erweitert werden, dass der Dateiname des zu erstellenden Backups das aktuelle Datum beinhaltet. So können mehrere Backup erstellt und unterschieden werden.

#! /bin/sh

# Backup-Script: "Rechnername“

# Datumsformat festlegen

DATUM=$(date +%F-%T)

# Liste der zu sichernden Verzeichnisse definieren:

BDIRS="/root /home /etc /var/lib /var/www /var/log"

# Backup: Beim Backup wird das Datum des Backups mit in den Dateinamen aufgenommen. Die oben definierten Verzeichnisse werden als Datum-backup.tgz in das Verzeichnis /media gesichert und komprimiert

/bin/tar czvf "/media/$DATUM Backup.tgz" $BDIRS

# DB Backup: Die Datenbanken werden ebenfalls in das Verzeichnis /media gesichert. Beim Backup wird auch hier das Datum des DB-Backups mit in den Dateinamen aufgenommen. Für "Passwort" das entsprechende Datenbank Passwort einsetzten.

/usr/bin/mysqldump --databases --opt -Q -uroot -pPasswort cloud > "/media/$DATUM cloud.sql"

/usr/bin/mysqldump --databases --opt -Q -uroot -pPasswort wordpress > "/media/$DATUM wordpress.sql"

## Anmerkung: Restore des Backups

##  /bin/tar -xzvf /media/DATUM-backup.tgz

## DB Restore. Für "Passwort" das entsprechende Datenbank Passwort einsetzten und für "DATUM" das Datum der Datei einsetzten.

## /usr/bin/mysql -u root -pPasswort< DATUM-cloud.sql

## /usr/bin/mysql -u root -pPasswort < DATUM-wordpress.sql

Damit das Backup regelmäßig ausgeführt wird, muss die Datei /etc/crontab editiert werden. Danach wird täglich um 3:32 Uhr das vorher erstellte Backup Script ausgeführt.

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# Definition des Jobs:
# .---------------- Minuten (0 - 59)
# | .------------- Stunden (0 - 23)
# | | .---------- Tag des Monats (1 - 31)
# | | | .------- Monat (1 - 12) oder jan,feb,mar,apr ...
# | | | | .---- Tag der Woche (0 - 6) (Sontag=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command 

# Das Backup /root/bin/backup.sh wird täglich um 3:32 Uhr als Benutzer root ausgeführt. 

32 3 * * * root test -x /root/bin/backup.sh && /root/bin/backup.sh 1>/dev/null

Statusabfrage: Ist App aktiv oder inaktiv?

Mithilfe dieses Applescrits kann der Status einer Mac OS X Application überprüft werden. In diesem Beispiel wird nachgeschaut ob das Programm Mail geöffnet oder geschlossen ist. Ist die App Mail aktiv wird nach 5 Sekunden erneut eune Überprüfung durchgeführt. Befindet sich Mail im Zustand beendet, wird es neu gestartet.

-- mailapp.applescript

on ApplicationIsRunning(Mail)

tell application "System Events" to set appNameIsRunning to exists (Mail)

return appNameIsRunning

end ApplicationIsRunning

on idle —- Im Abstand von 5 Sekunden wird überprüft ob das Programm Mail noch läuft.

if application "Mail" is not running then

tell application "Mail" to run

end if

return 5 — Wiederholungsinterwall in Sekunden.

end idle

eMail bei Änderung der IP Adresse

Ist dem Internet Gateways keine feste IP Adresse zugeordnet, änder sich die externe IP Adresse regelmäßig.  Das folgende Applescrip überprüft regelmäßig ob sich die externe IP Adresse geändet hat. Wird dem Internet Gateway durch den Provider eine neue dynamische IP Adresse zugewiesen wird eine eMail versendet.

-- Mail-IP.applescript

property newAddress : ""
property currentAddress : ""
property newMessage : ""
property emailRecepient : "Benutzername
property emailAddress : "benutzer@domäne.xxx-- eMail Empfänger

on idle
 -- Auslesen der derzeitigen externen IP Adresse.
 tell application "System Events" to set newAddress to do shell script "curl http://checkip.dyndns.org | awk '/: / {print $6}' | cut -f 1 -d '<' "

 -- Hat sich die IP Adresse seit der letzten Überprüfung geändert ...
 if newAddress is not equal to currentAddress then

-- ... sendet die IP Adresse als eMail.
 tell application "Mail"
 set newMessage to make new outgoing message with properties {visible:true, subject:"ip info", content:"Die externe IP Adresse lautet: " & newAddress}
 tell newMessage
 make new to recipient at end of to recipients with properties {address:emailAddress}
 end tell
 activate
 send newMessage
 end tell
end if

-- Die derzeitige IP Adresse als neue IP Adresse definiert.
 set currentAddress to newAddress

-- Stündlich wird eine Überprüfung durchgeführt Die Angabe erfolgt in Sekunden.
 return 3600

end idle

 

Wichtig: Neue Festnetz-Rufnummer!

Bitte beachten:

Am 01. 10. 2016 habe ich eine neue Festnetz-Rufnumer erhalten. Die Rufnummer lautet seither wie folgt: +49 231 69 00 174. Bitte gleichen Sie meine neuen Kontaktdaten mit den Ihren ab und verwenden Sie zukünftig nur noch diese Festnetznummer.

Vielen Dank für Ihr Verständnis!

Michael Buth

Linux: Gefährliche glibc Sicherheitslücke

Eine schwerwiegende Sicherheitslücke gefährdet fast alle Linux-Systeme und Linux kommt inzwischen fast überall zum Einsatz und dementsprechend viele Systeme nutzen die Glibc-Bibliothek. Eine DNS-Funktion erlaubt die Ausführung von bösartigem Code. Updates sollten schnellstmöglich installiert werden.
Neben zahlreichen Linux Distributionen sind u.a. auch VMware, diverse Router und Appliances betroffen.

Ich unterstütze Sie gerne bei der Überprüfung Ihrer Systeme.

Kritische Sicherheitslücke bei Cisco

Cisco schließt kritische Sicherheitslücke in seiner Adaptive Security Appliance

Cisco hat eine kritische Sicherheitslücke in seiner Adaptive Security Appliance (ASA) geschlossen. Ein Angreifer kann remote die Kontrolle über eine ASA Appliance übernehmen, die als VPN Server konfiguriert ist. Dafür muss er nur speziell präparierte Netzwerkpakete versenden.

Die Anfälligkeit wird im Common Vulnerability Scoring System (CVSS) mit 10 Punkten bewertet. Das Problem steckt in den Protokollen Internet Key Exchange Version 1 (IKEv1) und IKE Version 2 (IKEv2). Fragmentierte IKE-Pakete können einen Pufferüberlauf auslösen.

Betroffen sind die Cisco ASA 5500 Series Adaptive Security Appliance, Cisco ASA 5500-X Series Next-Generation Firewall, Cisco ASA Services Module für Cisco Catalyst 6500 Series Switches und Cisco 7600 Series Router. Außerdem sind Cisco ASA 1000V Cloud Firewall, Cisco Adaptive Security Virtual Appliance (ASAv), Cisco Firepower 9300 ASA Security Module und Cisco ISA 3000 Industrial Security Appliance anfällig.

„Ein Angreifer kann die Schwachstelle ausnutzen, indem er manipulierte UDP-Pakete an ein betroffenes System verschickt“, schreibt Cisco. „Ein Exploit könnte es einem Angreifer erlauben, Schadcode auszuführen und die vollständige Kontrolle zu übernehmen oder einen Neustart des Systems auszulösen.“

Ich helfe Ihnen gerne diese Lücke zu beseitigen.