STINT 2024 | Siegburger Tauch Intensiv Notfall Tage

Liebe Tauchsportbegeisterte,

herzlich willkommen zu den dritten Siegburger Tauch-Intensiv-Notfall-Tagen vom 26. April  bis zum 28. April 2024 im Dive4Life Indoortauchcenter. Die interdisziplinäre Fortbildung wird in Zusammenarbeit mit Daniela Koonen (HBO Zentrum Euregio Aachen), Prof. Stefan Schröder, einem der Initiatoren des Bonner Tauchersymposiums, sowie dem dive4life Indoortauchcenter organisiert und durchgeführt. Hier werden Themen mit aktuellen Bezügen zu Forschung und Praxis bei Wasserrettung, Tauch- und Notfallmedizin aufgegriffen. Neben mir sorgen zahlreiche namhafte Referenten für die thematische Breite von der Theorie bis zur Praxis im Indoortauchbecken.

STINT 2024 | Siegburger Tauch Intensiv Notfall Tage

26. – 28.04.2024

Die Anmeldung ist ab sofort möglich!

 

Technisches Tauchen

Workshop „Technisches Tauchen“.

 

Die Inhalte des Workshops

1.    Versuch einer Definition:

2.             Technisches Tauchen ist Sporttauchens jenseits der üblichen Grenzen.

  • Verwendung von professionellen Techniken, Prozeduren und Ausrüstung
  • Überschreiten von Tiefe und Dauer eines Nullzeit-Tauchgangs

-> Dekompression wird erforderlich

  • Verwendung von speziellen Gasgemischen
  • Gaswechsel während eines Tauchgangs
  • Verwendung von Rebreathern (CCR)
  • Verwendung von Scootern (DPV)
  • Tauchen in „Overhead“-Umgebungen

3.             Freizeittauchen jenseits der Sporttaucher-Grenzen erfordert

  • Spezielle Kenntnisse (Dekompressionstheorie, Toxizität von Gasen)
  • Spezielle Vorbereitung (Tauchgangsplanung, Umgang mit Tabellen und Computerprogrammen)
  • Spezielle Ausrüstung (Redundanz!)
  • Spezielle Ausbildung
  • Regelmäßiges Training
  • Körperliche und Psychische Fitness

3.1.  Ziel

  • Jedes Problem muss während des Tauchgangs gelöst werden können

4.    Ausrüstung für das technische Tauchen

  • Redundanz
  • Ausreichende Reserve beim Gasvorrat
  • Verschiedene Gase für verschiedene Tiefen
  • Spezielle Tauchcomputer
  • Alternatives Tariermittel
  • Redundanz bei Atemregler, Schneidewerkzeug, Maske, Lampe etc.
  • Signal- und Kommunikationsmittel (Bojen, Lampen)
  • Reels, Spools, Marker etc.

5.    Technische Tauchorganisationen

  • IAND – gegründet 1985, 1991 umbenannt in IANTD
  • ANDI – gegründet 1988
  • TDI – abgespalten von IANTD 1994
  • GUE – gegründet 1998

6.    DIR – Doing it right

  • Einheitliche Ausrüstungskonfiguration und Ausbildung
  • Redundanz aller wichtigen Ausrüstungsgegenstände
  • Hohes Maß an körperlicher Fitness
  • Perfektes Training grundlegender Tauchtechniken
    (z.B. Tarierung, Flossenschlagtechniken)

7.    Errungenschaften des technischen Tauchens

  • Sicherheitsstopp, Deep Stop
  • Finimeter, Oktopus
  • Doppelventile bei Kaltwasser-Tauchgängen,
  • Doppel-Tank, 2. Erste Stufe, absperrbare Brücke
  • Trockentauchanzüge
  • Nitrox
  • Triebmittel, Jackets, Wings
  • Sidemount
  • Atemregler-Konfiguration mit langem Schlauch und gleichwertiger alternativer Luftversorgung

8.    Rebreather CCR

  • Ausatmung durch CO2-Absorber in Gegenlunge
  • Einatmung aus Gegenlunge
  • Kontrolle des pO2 durch Sauerstoff-Sensoren
  • Anpassung des pO2 durch Einspeisung von Sauerstoff und Verdünnungsgas je nach Tiefe
  • Konstanthaltung des pO2
  • Das Volumen (in Lunge + Gegenlunge) bleibt konstant – kein Tarieren durch Atmung möglich
  • Beim Abtauchen wird Volumen komprimiert, pO2 im System steigt an
    -> Volumen im Loop wird durch Zugabe von Diluent aufrecht erhalten
  • Beim Auftauchen dehnt sich das Volumen im Loop aus -> Gas muss aus dem System abgelassen werden
  • pO2 fällt ab (Gesetz von Dalton): Sauerstoff wird zugegeben
  • Festgesetzter Setpoint des pO2 (i.d.R. 1,3) garantiert immer das optimale Deko-Gas
    -> immer „best Mix“ Geringere Inertgas-Aufnahme
    -> Frühzeitige und optimierte Dekompression

IT-Administrator Workshops

In Zusammenarbeit mit dem Magazin IT-Administrator werde ich folgendes Intensiv-Seminar zum Thema PKI in Hamburg durchführen.

Intensiv-Seminar „Aufbau einer PKI unter Windows Server“

Die Inhalte des Intensiv-Seminars

–    Grundsätzliche PKI-Alternativen & -Voraussetzungen
– Richtlinien und PKI (Zertifikatrichtlinie, Sicherheitsrichtlinie, Zertifikatsverwendungserklärung)
– Entwurf einer Zertifizierungsstellenhierarchie
– Organisation der ausstellenden Zertifizierungsstellen
– Auswahl einer Architektur
– Identifikation PKI-fähiger Anwendungen
– Bestimmung von Anforderungen (Sicherheit, Technik, Betrieb, Externe, Active Directory)
– Grundlagen PKI
– PKI-fähige Anwendungen identifizieren
– Aufbau und Konfiguration einer PKI Testumgebung
– Windows-Enterprise-Zertifikatsdienste effektiv nutzen und verwalten
– Webauthentifizierung und Webverschlüsselung (SSL)
– WLAN und LAN mit 802.1x-Authentifizierung
– Sichere E-Mail (S/MIME)

Termin & Ort

07. bis 09. September 2021: Hamburg
SYMPLASSON Informationstechnik GmbH
Holstenstraße 205, 22765 Hamburg

Das Intensiv-Seminar startet am ersten Tag um 10 Uhr und endet am dritten Tag gegen 16 Uhr.

Hier geht es zur Anmeldung.

IT-Administrator Workshops

In Zusammenarbeit mit dem Magazin IT-Administrator werde ich folgendes Intensiv-Seminar zum Thema PKI in München durchführen.

Intensiv-Seminar „Aufbau einer PKI unter Windows Server“

Die Inhalte des Intensiv-Seminars

–    Grundsätzliche PKI-Alternativen & -Voraussetzungen
–    Richtlinien und PKI (Zertifikatrichtlinie, Sicherheitsrichtlinie, Zertifikatsverwendungserklärung)
–    Entwurf einer Zertifizierungsstellenhierarchie
–    Organisation der ausstellenden Zertifizierungsstellen
–    Auswahl einer Architektur
–    Identifikation PKI-fähiger Anwendungen
–    Bestimmung von Anforderungen (Sicherheit, Technik, Betrieb, Externe, Active Directory)
–    Grundlagen PKI
–    PKI-fähige Anwendungen (Code-Signing, Bereitstellung von Smartcards, sichere E-Mail et cetera)
–    Wifi mit 802.1x-Authentifizierung
–    Windows-Enterprise-Zertifikatsdienste nutzen

Termin & Ort

12. bis 14. Oktober 2021: Garching bei München
Fast Lane Institute for Knowledge Transfer GmbH
Parkring 22, 85748 Garching bei München

Das Intensiv-Seminar startet am ersten Tag um 10 Uhr und endet am dritten Tag gegen 16 Uhr.

Hier geht es zur Anmeldung.

IT Beratung in Zeiten des Corona-Virus

Aufgrund der Corona Situation weisen Unternehmen in der aktuellen Bedrohungslage ihre Mitarbeiter an, dem Büro fernzubleiben und nach Möglichkeit von zu Hause zu arbeiten.  Gleiches gilt natürlich auch für mich als IT Berater. Ich habe meine Prozesse inzwischen soweit optimiert, dass ich Ihnen nahezu alle Leistungen, Beratung, Workshops und PKI Migrationen remote anbieten kann. Bitte kontaktieren Sie mich für weitere Informationen.

Workshop: Public Key-Infrastructure (PKI)

Themen, Inhalte und Dauer des Public Key-Infrastructure (PKI) Workshops können individuell vereinbart werden.

Für eine Auswahl an Themen steht Ihnen hier eine Inhaltsverzeichnis zur Verfügung: Workshop-PKI

© 2018 by Michael Buth  •   IT Berater  •  Werner Str. 29  •  44388 Dortmund  •   tel.:  +49 231 69 00 174

Workshop: FreeRADIUS & Network Policy Server  (NPS)

Themen und Inhalte

FreeRADIUS 3.x & Windows 2019 Network Policy Server  (NPS)

1. RADIUS Grundlagen 

2. RADIUS-Infrastrukturkomponenten

2.1. Zugriffsclients

2.2. RADIUS-Client (NAS) 

2.3. RADIUS-Server 

2.4. RADIUS-Proxy 

2.5. Benutzerkontendatenbank 

3. Authentifizierung, Autorisierung und Abrechnung 

3.1. Authentication 

3.1.1.Schematischer Ablauf

3.1.2.Detaillierter Ablauf

3.2. Authorization 

3.3. Accounting 

4. FreeRADIUS 3.x

4.1. Installation 

4.1.1.Installation FreeRADIUS 3.x

4.1.2.Installation des Webadministrationstool DolaRADIUS

4.1.1.Optional: Mit Firewall

4.1.2.Optional: Ohne Firewall

4.2. Konfiguration 

4.2.1.Einfaches Setup ohne MySQL DB

4.2.2.Setup mit MySQL DB

4.3. Konfigurationsdateien 

4.3.1.clients.conf

4.3.2.users

4.3.3.radiusd.conf

4.4. Authentication Protocols 

4.4.1.PAP

4.4.2.CHAP

4.4.3.MS-CHAP

4.4.4.EAP

4.5. Speicherung von Benutzern und Kennwörtern
 
4.6. FreeRADIUS MYSQL-Redundanz - Master-Master-Replokation

5. FreeRADIUS und Active Directory 

5.1. Samba Server 

5.2. NTLM Authentication (Active Directory) mit PAP 

5.3. MS-CHAP Authentication 

5.4. EAP Authentication 

5.5. AccessPiont als NAS 

5.6. FreeRADIUS und PKI 

5.6.1.TinyCA

5.6.2.Self-signed certificates

6. Windows Server 2019 

6.1. Authentifizierung 

6.2. Active Directory Zertifikatdienste 

6.2.1.Installation und Konfiguration

6.2.2.Verwaltung

6.3. Network Policy Server (NPS) 

6.3.1.Installation

6.3.2.Verwaltung

6.3.3.WiFi 802.1x Authentifizierung

6.3.4.Wired Access 802.1x Authentifizierung

6.3.5.NPS Authentifizierungsereignisse protokollieren

7. Konfiguration RADIUS NAS 

7.1. Access Point 

7.2. Switch

 

© 2017 by Michael Buth  •   IT Berater  •  Werner Str. 29  •  44388 Dortmund  •   tel.:  +49 231 69 00 174

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 wird 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 ~]# 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

Diese Webseite verwendet Cookies, um Ihnen ein angenehmeres Surfen zu ermöglichen. Mehr Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen