Auf der Arbeit hatte ich vor kurzem eine neue Aufgabe. Zuerst dachte ich kein Problem, das kann ich in wenigen Minuten erledigen.
Aber dann als ich versucht habe es zu implementieren, brauchte ich mehr als zwei Stunden.
Das Problem!
Du hast eine Gruppe von 20 oder mehr Entwicklern die dein Firmen Subversion Server verwenden. Alle Entwickler sind in einem Active Directory gepflegt und haben Schreibzugriff. Nun soll eine einzige Person Lesezugriff auf das Repository erhalten.
Wie kann man es lösen?
Das interne authz_svn Apache Authorisation Modul unterstützt nicht das Überschreiben von rw Rechten mit r Rechten, sodass man es nicht verwenden kann. Ich habe diverse Versuche unternommen, aber ohne Erfolg. Die einzige Möglichkeit wäre eine neue Gruppe in der Access-Listen Datei, aber diese müßte dann irgendwie mit dem Active Directory synchronisiert werden.
Die Lösung:
Nach einer kurzen Diskussion mit einem Kollegen, bekam ich eine Idee. Ich binde das SVN Repository in einem neuen Verzeichnis
mit bind mount ein:
mkdir /var/svn-ro
mount -o bind /var/svn /var/svn-ro
mount -o remount,ro /var/svn-ro
Man muss das dann in /etc/fstab eintragen und einen Remount-Aufruf in /etc/rc.local.
Es ist nicht möglich dies in einer Stab Zeile auszudrücken.
Danach habe ich das Repository nur für den Benutzer über eine Extra Active Directory Gruppe eingebunden.
Und voila, alles läuft.
Happy coding,
Waldemar
Samstag, 25. April 2015
Lesezugriff für Subversion für einzelne Benutzer
Sonntag, 18. Mai 2014
HP IRF
Auf der Arbeit haben wir zwei neue HP 5500SL Switche bekommen und nutzen nun diese zur Erhöhung der Redundanz und Performanz für die ESXi 5.5 Server. HP hat die IRF Technologie von H3C einverleibt.
Hier ein kurzer Abriss, was konfiguriert werden muss, um ein nettes HA-Setup zu realisieren, da die Dokumentation und Beispiele im Internet mal wieder einiges offen lassen:
Vorraussetzung: gleicher Firmwarestand auf beiden Switchen und zwei JD360B 2-port 10GbE Local Connect Module.
1. Schritt
Die Zusatzmodule müssen ausgebaut sein. Man meldet sich an beiden Switches an.
2. Schritt
Setze die MemberIDs für beide Switche:
Dann auf beiden:
3. Schritt
Konfiguration IRF MAC Persistenz, damit ist der "virtuelle" Switch, bei Ausfall des Master-Switches immer unter derselben MAC-Adresse erreichbar.
Konfiguration der Priorität:
Dann auf beiden:
4. Schritt
Baue die 10GE Module ein und verbinde die beiden Switche über Kreuz. Das heißt Switch1 Port1 auf Switch2 Port2 und umgekehrt.
5. Schritt
Verbinde logisch die physikalischen IRF Ports mit den logischen IRF Ports.
Interfaces herunterfahren:
IRF logische Ports erzeugen:
IRF aktivieren:
Vor dem Reboot darauf achten, das die beiden Switche nicht mit einem Netzwerkkabel verbunden sind! Ansonsten erzeugen wir eine Loop!
Nach dem Reboot sollte nur noch der Master mit seiner IP-Adresse erreichbar sein:
Konfiguration von MAD (Multiple Access Detection)
Unsere Switche beherschen leider kein MAD BFD. Für MAD LACP bräuchten wir einen weiteren Switch, der die MAD LACP Extensions unterstützt. Ist auch nicht vorhanden. Wir verwenden daher MAD ARP mit einer direkten Kabelverbindung zwischen den Switchen:
Für MAD ARP muss die Einstellung zur Persistenz der MAC Adresse geändert werden:
Dann wird ein VLAN erzeugt und MAD ARP für diesen Link aktiviert:
Jetzt können die beiden Switche mit einem Kabel auf Port 48 verbunden werden.
Konfiguration eines Aggregation Ports für die Verbindung zu einem Linuxserver
Beispiel für die Verbindung eines Linuxservers, es wird LACP (dynamische Link Aggregation) konfiguriert:
Jetzt kann das Linuxsystem mit zwei Kabeln mit Port 17 an beiden Switchen verbunden werden. Als nächstes konfiguriert man das Ethernet Bonding auf Debian Seite. In die /etc/network/interfaces trägt man folgendes ein:
Und führt folgendes aus:
Auf dem Switch sollte es dann so aussehen:
Konfiguration eines Aggregation Ports für die Verbindung zu einem ESX-Host
Beispiel für die Verbindung eines ESXi-Hosts zum DMZ-VLAN, es wird statische Link Aggregation ohne LACP konfiguriert.
Das Teaming unter ESXi muss vor der Konfiguration des Switches erfolgen.
Danach kann man den ESXi-Host mit zwei Kabeln mit den Ports 18 auf beiden Switchen verbinden. Auf dem Switch sollte es dann so aussehen:
Um die volle Performanz von 2 Gbit/s bei VMotion nutzen zu können, muss man sich an folgende Anleitung orientieren:
Vmware KB 2007467. Das funktioniert erst ab ESXi 5.5, bei 5.1 gibt es einen Bug, der bei Ausfall eines Switches dazu führt, das gar kein VMotion mehr geht. Desweiteren sollte man die Warnungen bzgl. IP Hash ignorieren, IP Hash ist bei HP IRF zwingend erforderlich.
Nach der Konfiguration kann man mal ruhig während der Migration einiger Maschinen einen der Switche ausschalten, um zu verifizieren das
HA auch funktioniert
.
Zur Messung der Performanz hat sich SNMP mit PRTG als nützlich erwiesen, mit Cacti hatte ich Probleme.
Hier ein kurzer Abriss, was konfiguriert werden muss, um ein nettes HA-Setup zu realisieren, da die Dokumentation und Beispiele im Internet mal wieder einiges offen lassen:
Vorraussetzung: gleicher Firmwarestand auf beiden Switchen und zwei JD360B 2-port 10GbE Local Connect Module.
1. Schritt
Die Zusatzmodule müssen ausgebaut sein. Man meldet sich an beiden Switches an.
2. Schritt
Setze die MemberIDs für beide Switche:
[HP-ESX-Master]irf member 1 renumber 1
[HP-ESX-Slave]irf member 1 renumber 2
Dann auf beiden:
[HP-All]quit
[HP-All]save
[HP-All]reboot
3. Schritt
Konfiguration IRF MAC Persistenz, damit ist der "virtuelle" Switch, bei Ausfall des Master-Switches immer unter derselben MAC-Adresse erreichbar.
[HP-ESX-Master]irf mac-address persistent always
Konfiguration der Priorität:
[HP-ESX-Master]irf member 1 priority 32
[HP-ESX-Slave]irf member 1 priority 30
Dann auf beiden:
[HP-All]quit
[HP-All]save
[HP-All]reboot
4. Schritt
Baue die 10GE Module ein und verbinde die beiden Switche über Kreuz. Das heißt Switch1 Port1 auf Switch2 Port2 und umgekehrt.
5. Schritt
Verbinde logisch die physikalischen IRF Ports mit den logischen IRF Ports.
Interfaces herunterfahren:
[HP-ESX-Master]interface Ten-GigabitEthernet 1/1/1
[HP-ESX-Master]shutdown
[HP-ESX-Master]quit
[HP-ESX-Master]interface Ten-GigabitEthernet 1/1/2
[HP-ESX-Master]shutdown
[HP-ESX-Master]quit
[HP-ESX-Slave]interface Ten-GigabitEthernet 2/1/1
[HP-ESX-Slave]shutdown
[HP-ESX-Slave]quit
[HP-ESX-Slave]interface Ten-GigabitEthernet 2/1/2
[HP-ESX-Slave]shutdown
[HP-ESX-Slave]quit
IRF logische Ports erzeugen:
[HP-ESX-Master]irf port 1/1
[HP-ESX-Master]port group interface Ten-GigabitEthernet 1/1/1
[HP-ESX-Master]irf port 1/2
[HP-ESX-Master]port group interface Ten-GigabitEthernet 2/1/1
[HP-ESX-Slave]irf port 2/1
[HP-ESX-Slave]port group interface Ten-GigabitEthernet 1/1/2
[HP-ESX-Slave]irf port 2/2
[HP-ESX-Slave]port group interface Ten-GigabitEthernet 2/1/2
IRF aktivieren:
[HP-ESX-Master]irf-port-configuration active
Vor dem Reboot darauf achten, das die beiden Switche nicht mit einem Netzwerkkabel verbunden sind! Ansonsten erzeugen wir eine Loop!
[HP-All]quit
[HP-All]save
[HP-All]reboot
Nach dem Reboot sollte nur noch der Master mit seiner IP-Adresse erreichbar sein:
[HP-ESX-Master]display irf
Switch Role Priority CPU-Mac Description
+1 Master 32 xxxx-yyyy-zzzz -----
2 Slave 30 xxxx-yyyy-zzzz -----
--------------------------------------------------
indicates the device is the master.
+ indicates the device through which the user logs in.
The Bridge MAC of the IRF is: xxxx-yyyy-zzzz
Auto upgrade : yes
Mac persistent : always
Domain ID : 0
[HP-ESX-Master]display irf topology
Topology Info
-------------------------------------------------------------------------
IRF-Port1 IRF-Port2
Switch Link neighbor Link neighbor Belong To
1 UP 2 UP 2 xxxx-yyyy-zzzz
2 UP 1 UP 1 xxxx-yyyy-zzzz
[HP-ESX-Master]display irf configuration
MemberID NewID IRF-Port1 IRF-Port2
1 1 Ten-GigabitEthernet1/1/1 Ten-GigabitEthernet1/1/2
2 2 Ten-GigabitEthernet2/1/1 Ten-GigabitEthernet2/1/2
Konfiguration von MAD (Multiple Access Detection)
Unsere Switche beherschen leider kein MAD BFD. Für MAD LACP bräuchten wir einen weiteren Switch, der die MAD LACP Extensions unterstützt. Ist auch nicht vorhanden. Wir verwenden daher MAD ARP mit einer direkten Kabelverbindung zwischen den Switchen:
Für MAD ARP muss die Einstellung zur Persistenz der MAC Adresse geändert werden:
[HP-ESX-Master]undo irf mac-address persistent
Dann wird ein VLAN erzeugt und MAD ARP für diesen Link aktiviert:
[HP-ESX-Master]vlan 7
[HP-ESX-Master-vlan7]description ARP-MAD-VLAN
[HP-ESX-Master-vlan7]port GigabitEthernet 1/0/48
[HP-ESX-Master-vlan7]port GigabitEthernet 2/0/48
[HP-ESX-Master-vlan7]quit
[HP-ESX-Master]interface vlan-interface 7
[HP-ESX-Master]ip address 192.168.168.168 24
[HP-ESX-Master]mad arp enable
[HP-ESX-Master]save
Jetzt können die beiden Switche mit einem Kabel auf Port 48 verbunden werden.
Konfiguration eines Aggregation Ports für die Verbindung zu einem Linuxserver
Beispiel für die Verbindung eines Linuxservers, es wird LACP (dynamische Link Aggregation) konfiguriert:
[HP-ESX-Master]vlan 9
[HP-ESX-Master-vlan9]description ESX-DMZ
[HP-ESX-Master-vlan9]port GigabitEthernet 1/0/17
[HP-ESX-Master-vlan9]port GigabitEthernet 2/0/17
[HP-ESX-Master-vlan9]quit
[HP-ESX-Master]interface bridge-aggregation 17
[HP-ESX-Master-Bridge-Aggregation17]description fw-dmz
[HP-ESX-Master-Bridge-Aggregation17]link-aggregation mode dynamic
[HP-ESX-Master-Bridge-Aggregation17]quit
[HP-ESX-Master]interface GigabitEthernet 1/0/17
[HP-ESX-Master-GigabitEthernet1/0/17]port link-aggregation group 17
[HP-ESX-Master-GigabitEthernet1/0/17]quit
[HP-ESX-Master]interface GigabitEthernet 2/0/17
[HP-ESX-Master-GigabitEthernet2/0/17]port link-aggregation group 17
[HP-ESX-Master-GigabitEthernet2/0/17]quit
[HP-ESX-Master]interface bridge-aggregation 17
[HP-ESX-Master-Bridge-Aggregation17]port access vlan 9
[HP-ESX-Master-Bridge-Aggregation17]quit
Jetzt kann das Linuxsystem mit zwei Kabeln mit Port 17 an beiden Switchen verbunden werden. Als nächstes konfiguriert man das Ethernet Bonding auf Debian Seite. In die /etc/network/interfaces trägt man folgendes ein:
auto bond0
iface bond0 inet static
address 192.168.1.1
netmask 255.255.255.0
bond-slaves eth0 eth4
bond-mode 802.3ad
bond-miimon 100
xmit_hash_policy layer2+3
Und führt folgendes aus:
ifup bond0
Auf dem Switch sollte es dann so aussehen:
[HP-ESX-Master]display link-aggregation summary
Aggregation Interface Type:
BAGG -- Bridge-Aggregation, RAGG -- Route-Aggregation
Aggregation Mode: S -- Static, D -- Dynamic
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Actor System ID: 0x8000, xxxx-yyyy-zzzz
AGG AGG Partner ID Select Unselect Share
Interface Mode Ports Ports Type
-------------------------------------------------------------------------------
BAGG17 D 0xffff, xxxx-yyyy-zzzz 2 0 Shar
..
Konfiguration eines Aggregation Ports für die Verbindung zu einem ESX-Host
Beispiel für die Verbindung eines ESXi-Hosts zum DMZ-VLAN, es wird statische Link Aggregation ohne LACP konfiguriert.
Das Teaming unter ESXi muss vor der Konfiguration des Switches erfolgen.
[HP-ESX-Master]vlan 9
[HP-ESX-Master-vlan9]port GigabitEthernet 1/0/18
[HP-ESX-Master-vlan9]port GigabitEthernet 2/0/18
[HP-ESX-Master-vlan9]quit
[HP-ESX-Master]interface bridge-aggregation 18
[HP-ESX-Master-Bridge-Aggregation18]description esx1-dmz
[HP-ESX-Master-Bridge-Aggregation18]quit
[HP-ESX-Master]interface GigabitEthernet 1/0/18
[HP-ESX-Master-GigabitEthernet1/0/18]port link-aggregation group 18
[HP-ESX-Master-GigabitEthernet1/0/18]quit
[HP-ESX-Master]interface GigabitEthernet 2/0/18
[HP-ESX-Master-GigabitEthernet2/0/18]port link-aggregation group 18
[HP-ESX-Master-GigabitEthernet2/0/18]quit
[HP-ESX-Master]interface Bridge-Aggregation 18
[HP-ESX-Master-Bridge-Aggregation18]port access vlan 9
[HP-ESX-Master-Bridge-Aggregation18]quit
Danach kann man den ESXi-Host mit zwei Kabeln mit den Ports 18 auf beiden Switchen verbinden. Auf dem Switch sollte es dann so aussehen:
[HP-ESX-Master]display link-aggregation summary
Aggregation Interface Type:
BAGG -- Bridge-Aggregation, RAGG -- Route-Aggregation
Aggregation Mode: S -- Static, D -- Dynamic
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Actor System ID: 0x8000, xxxx-yyyy-zzzz
AGG AGG Partner ID Select Unselect Share
Interface Mode Ports Ports Type
-------------------------------------------------------------------------------
BAGG18 S none 2 0 Shar
..
Um die volle Performanz von 2 Gbit/s bei VMotion nutzen zu können, muss man sich an folgende Anleitung orientieren:
Vmware KB 2007467. Das funktioniert erst ab ESXi 5.5, bei 5.1 gibt es einen Bug, der bei Ausfall eines Switches dazu führt, das gar kein VMotion mehr geht. Desweiteren sollte man die Warnungen bzgl. IP Hash ignorieren, IP Hash ist bei HP IRF zwingend erforderlich.
Nach der Konfiguration kann man mal ruhig während der Migration einiger Maschinen einen der Switche ausschalten, um zu verifizieren das
HA auch funktioniert
.Zur Messung der Performanz hat sich SNMP mit PRTG als nützlich erwiesen, mit Cacti hatte ich Probleme.
Samstag, 5. April 2014
grub2 RAID fun mit Debian wheezy
Ein Kollege von mir hat sich einen Rootserver bestellt. Dieser hat 4 500 MB Platten, aber wenn man root-Zugang haben möchte, dann installiert der
Provider nur ein Debian auf die erste Platte ohne Software RAID. Angeblich würde der Provider eine gewünschte Partitionierung vornehmen, welches uns eine Installation in eine freie erste Partition ermöglicht hätte. In der Realität war es leider wieder anders.
So sah das ganze dann aus:
Naja, als alter Windows-NT Benutzer mit C: für das System und D: für Daten sah das ganze nicht aus
Aber so leicht sollte man nicht aufgeben. Auf einer Testkiste habe ich dann zwei Shell-Skripte entwickelt, die eine Installation von Debian auf Software-RAID mit RAID Level 5 ermöglicht haben. Die Installation verlief in 3 Schritten:
1. http://www.waldemar-brodkorb.de/scripts/grub2-debian-wheezy.sh verwendet, um Debian 7 in die 8 Partition zu installieren && reboot
2. mit parted, partprobe und fdisk an der Partitionstabelle gewurschtelt bis /dev/sda1 20 GB groß war und das Intermediate System auf
/dev/sda5 in einer erweiterten Partition am Ende der Platte verblieb. Danach auf jeden Fall /etc/fstab und /boot/grub/grub.cfg korrigieren und grub-install /dev/sda erneut ausführen. Falls Fehler auftreten mit partprobe oder kpartx den Kernel davon überzeugen, das er die neue Partitionstabelle einliest! && reboot
3. http://www.waldemar-brodkorb.de/scripts/grub2-raid-debian-wheezy.sh verwenden, um Debian 7 in die erste Partition auf einem Software-RAID 5 zu installieren. && reboot
Nach der ganzen Geschichte kann man die extended Partition löschen und zwei neue Partitionen für swap und /data (D:) erzeugen und als RAID 5 einrichten. Oben drauf noch die Datenverschlüsselung per cryptsetup und alles ist gut.
Ich frage mich warum die Konfiguration von Grub2 und RAID im Internet so schlecht dokumentiert ist. Die Tests auf der Testmaschine mit 4 Platten,
haben ergeben das auch RAID 0, RAID 1, RAID 5, RAID 6 und RAID 10 wunderbar funktionieren und das System trotz Ausfall von 1-2 Platten je verwendeten RAID-Level weiterhin startet. Einzig allein bei der Verwendung von RAID 6 muß man den Grub2 in Wheezy auf die Version von Sid anheben, da ansonsten bei Ausfall einer Platte im RAID-Verbund GRUB nicht mehr startet. (Bug in Grub)
Vielleicht mach ich ein YAIFD, um das zu automatisieren und die fehlerhaften Zwischenschritte zu eliminieren.
(2005 habe ich mal das Projekt YAIFO ins Leben gerufen, um OpenBSD auf Rootserver zu installieren: https://github.com/jedisct1/yaifo)
Happy booting!
Provider nur ein Debian auf die erste Platte ohne Software RAID. Angeblich würde der Provider eine gewünschte Partitionierung vornehmen, welches uns eine Installation in eine freie erste Partition ermöglicht hätte. In der Realität war es leider wieder anders.
So sah das ganze dann aus:
Device Boot Start End Blocks Id System
/dev/sda1 2048 4095 1024 83 Linux
/dev/sda2 * 4096 206847 101376 83 Linux -> /boot
/dev/sda3 208894 976771071 488281089 5 Extended
/dev/sda5 208896 8593407 4192256 82 Linux swap / Solaris
/dev/sda6 8595456 12787711 2096128 83 Linux -> /
/dev/sda7 12789760 111482879 49346560 83 Linux -> /tmp
/dev/sda8 111484928 976771071 432643072 83 Linux -> /home
Naja, als alter Windows-NT Benutzer mit C: für das System und D: für Daten sah das ganze nicht aus
Aber so leicht sollte man nicht aufgeben. Auf einer Testkiste habe ich dann zwei Shell-Skripte entwickelt, die eine Installation von Debian auf Software-RAID mit RAID Level 5 ermöglicht haben. Die Installation verlief in 3 Schritten:
1. http://www.waldemar-brodkorb.de/scripts/grub2-debian-wheezy.sh verwendet, um Debian 7 in die 8 Partition zu installieren && reboot
2. mit parted, partprobe und fdisk an der Partitionstabelle gewurschtelt bis /dev/sda1 20 GB groß war und das Intermediate System auf
/dev/sda5 in einer erweiterten Partition am Ende der Platte verblieb. Danach auf jeden Fall /etc/fstab und /boot/grub/grub.cfg korrigieren und grub-install /dev/sda erneut ausführen. Falls Fehler auftreten mit partprobe oder kpartx den Kernel davon überzeugen, das er die neue Partitionstabelle einliest! && reboot
3. http://www.waldemar-brodkorb.de/scripts/grub2-raid-debian-wheezy.sh verwenden, um Debian 7 in die erste Partition auf einem Software-RAID 5 zu installieren. && reboot
Nach der ganzen Geschichte kann man die extended Partition löschen und zwei neue Partitionen für swap und /data (D:) erzeugen und als RAID 5 einrichten. Oben drauf noch die Datenverschlüsselung per cryptsetup und alles ist gut.
Ich frage mich warum die Konfiguration von Grub2 und RAID im Internet so schlecht dokumentiert ist. Die Tests auf der Testmaschine mit 4 Platten,
haben ergeben das auch RAID 0, RAID 1, RAID 5, RAID 6 und RAID 10 wunderbar funktionieren und das System trotz Ausfall von 1-2 Platten je verwendeten RAID-Level weiterhin startet. Einzig allein bei der Verwendung von RAID 6 muß man den Grub2 in Wheezy auf die Version von Sid anheben, da ansonsten bei Ausfall einer Platte im RAID-Verbund GRUB nicht mehr startet. (Bug in Grub)
Vielleicht mach ich ein YAIFD, um das zu automatisieren und die fehlerhaften Zwischenschritte zu eliminieren.
(2005 habe ich mal das Projekt YAIFO ins Leben gerufen, um OpenBSD auf Rootserver zu installieren: https://github.com/jedisct1/yaifo)
Happy booting!
Mittwoch, 2. April 2014
Puppet mit LDAP und eine Firewall Klasse
Samstag, 22. März 2014
OpenBSD authpf SSH gateway
Um die Angriffsfläche auf die Infrastruktur auf meiner Arbeitsstelle via Secure Shell zu minimieren, habe ich ein dediziertes Secure Shell Gateway installiert. Als Basis habe ich OpenBSD/amd64 5.4 unter VMware ESXi 5 verwendet. Der Server steht in der internen DMZ und die zentrale Firewall leitet alle Anfragen auf seine öffentliche IP-Adresse an die private DMZ-Adresse weiter.
Für die Nutzung von authpf werden lokale Benutzer angelegt:
Dann fügt man den öffentlichen SSH Schlüssel in /home/foo/.ssh/authorized_keys ein und erzeugt die userspezifischen Firewall Regeln und Nachrichten für das Anmeldefenster. Zum Beispiel wird der externe TCP Port 3389 über das SSH-Gateway auf die interne Maschine in der DMZ umgeleitet, um den Zugriff auf den Remote Desktop einer Windows Maschine zu erlauben:
( /etc/authpf/users/foo/athpf.rules )
Das SSH-Gateway befindet sich hierbei im selben Ethernet-Segment, wie die Windows-Maschine!
Dem Benutzer kann man folgende Nachricht ausgeben:
( /etc/authpf/users/foo/authpf.message )
Achtung: Anders als bei Linux iptables, werden alle Regeln auf die
IP-Pakete angewendet und die letzte Regel gilt. Ausnahme man
verwendet das Schlüsselwort "quick", dann bricht die Abarbeitung an
der Stelle ab!
Zum anschauen der erzeugten Regeln, mit ps aux die PID raussuchen:
Damit kann man wunderbar Zugriff für externe Firmen und Mitarbeiter auf seine DMZ erlauben, ohne die Services für Gott und die Welt zu öffnen.
Authpf habe ich 2002 in meiner Hacker-WG in Bonn kennengelernt. Hat ein bißchen gedauert, bis ich es erstmals produktiv einsetze
Puffy rockz!
Für die Nutzung von authpf werden lokale Benutzer angelegt:
adduser -s -class authpf -batch foo nogroup "Foo Bar"
Dann fügt man den öffentlichen SSH Schlüssel in /home/foo/.ssh/authorized_keys ein und erzeugt die userspezifischen Firewall Regeln und Nachrichten für das Anmeldefenster. Zum Beispiel wird der externe TCP Port 3389 über das SSH-Gateway auf die interne Maschine in der DMZ umgeleitet, um den Zugriff auf den Remote Desktop einer Windows Maschine zu erlauben:
pass in on em0 inet proto tcp from $user_ip to em0 port 3389 rdr-to 192.168.xxx.yyy port 3389
pass out on em0 inet proto tcp from $user_ip to 192.168.xxx.yyy port 3389 nat-to em0
( /etc/authpf/users/foo/athpf.rules )
Das SSH-Gateway befindet sich hierbei im selben Ethernet-Segment, wie die Windows-Maschine!
Dem Benutzer kann man folgende Nachricht ausgeben:
You can now access following service:
RDP to Windows machine: rdesktop foo@ssh-gateway"
( /etc/authpf/users/foo/authpf.message )
Achtung: Anders als bei Linux iptables, werden alle Regeln auf die
IP-Pakete angewendet und die letzte Regel gilt. Ausnahme man
verwendet das Schlüsselwort "quick", dann bricht die Abarbeitung an
der Stelle ab!
Zum anschauen der erzeugten Regeln, mit ps aux die PID raussuchen:
ps axw|grep authpf
pfctl -a "authpf/foo(xxx)" -s rules
Damit kann man wunderbar Zugriff für externe Firmen und Mitarbeiter auf seine DMZ erlauben, ohne die Services für Gott und die Welt zu öffnen.
Authpf habe ich 2002 in meiner Hacker-WG in Bonn kennengelernt. Hat ein bißchen gedauert, bis ich es erstmals produktiv einsetze
Puffy rockz!
