From vab at bb-c.de Thu Sep 13 10:55:54 2018 From: vab at bb-c.de (Volker A. Brandt) Date: Thu, 13 Sep 2018 10:55:54 +0200 Subject: [sage] Vortrag "Zertifikatsverteilung mit Hashicorp Vault" bei der FRAOSUG am 18.09.2018 (Dienstag) Message-ID: <23450.9754.765902.759454@shelob.bb-c.de> Hallo allerseits! Nächste Woche Dienstag findet wieder unser monatliches FRAOSUG-Treffen statt. Diesmal erklärt Christopher Ruwe die Zertifikatsverteilung mit Hashicorp Vault: Im Continuous Deployment Umfeld stellt das Management von Secrets eine besondere Herausforderung dar. In den Deployment-Code eingescheckt werden können/sollen sie nicht, aber der Deployment- Automat benötigt eine Möglichkeit, auf alle Komponenten des abzusichernden Kommunikations-Systems Secrets auszurollen. Hashicorp Vault bietet eine Lösungsmöglichkeit für dieses Problem an: Es kann als statischer Secret-Store für den Deployment-Automaten dienen und dem Provisionierungs-Automaten auditierbar secrets bereitstellen. Geschickter aber ist es, Secrets dynamisch mit sehr beschränkter Gültigkeit zu erzeugen und diese nur den beteiligten Komponenten über One-Time Passwords bekanntzugeben. Im Vortrag will ich einen Überblick über die Anforderungen an Secrets in einem CI/CD-Umfeld darstellen und danach die (nicht-technischen) Protokolle für die Zertifikats-Verteilung (TLS und ssh) zeigen. Wenn wir bei der ganzen Theorie dazu kommen (hoffentlich) möchte ich zeigen, wie mit Hashicorp Vault Systeme mit sehr kurzlebigen Zertifikaten aus einer eigenen CA versorgt werden können. Wir sind auch diesmal zu Gast bei der Frankfurter Uni-Bibliothek im Juridicum (danke Uwe!!!): https://fraosug.de/ Anmeldung über unser Umfrage-Tool: https://owncloud-002.qutic.com/index.php/apps/polls/poll/BgOTxQVcNGaQEB1i Die Veranstaltung ist kostenlos, und wie immer gilt: Das Verwenden von Solaris ist keine Vorbedingung für die Teilnahme... Viele Grüße -- Volker A. Brandt -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Solaris-based Systems Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From dirk.wetter at guug.de Wed Sep 26 08:57:19 2018 From: dirk.wetter at guug.de (Dirk Wetter) Date: Wed, 26 Sep 2018 08:57:19 +0200 Subject: [sage] BSD printf Message-ID: Hi, ich habe da ein kleines Problem. Wie einige vielleicht wissen, habe ich da ein FOSS-Projekt namens testssl.sh. Eine Kernfunktion sind Sockets. Das Projekt ist abseits ein paar weniger Unix-Tools drumherum in bash -- der kleinste gemeinsamste Nenner für BSDs (inkl. OS X), WSL, Cygwin etc. Auch die Sockets sind in bash programiert über /dev/tcp/*. Das klappt sogar recht gut. Leider nur hat das bash interne printf, womit die Bytes in die Sockets gesendet werden, das Problem, dass es bei jedem "\x0a" ein write flush macht wird, und das ein neues Netzpaket wird -- mit dem Resultat, dass TCP-Fragmentierung auftritt. Eine elegante Lösung wäre ein externes printf zu benutzen. Das klappt für Linux, da es genauso funktioniert wie das bash-Interne, also: /usr/bin/printf -- "\x16\x03\x01\x02\x00\x01\x00\x01\xfc\x03" | xxd --> 0000000: 1603 0102 0001 0001 fc03 .......... aber leider nicht für BSD, hier FreeBSD: --> 00000000: 7831 3678 3033 7830 3178 3032 7830 3078 x16x03x01x02x00x 00000010: 3031 7830 3078 3031 7866 6378 3033 01x00x01xfcx03 Frage: geht das mit dem FreeBSD printf überhaupt? Solaris sollte ein ähnliches, externes printf haben IIRC. VG, Dirk From vab at bb-c.de Wed Sep 26 09:34:57 2018 From: vab at bb-c.de (Volker A. Brandt) Date: Wed, 26 Sep 2018 09:34:57 +0200 Subject: [sage] BSD printf In-Reply-To: References: Message-ID: <23467.13985.255479.493385@shelob.bb-c.de> Hi Dirk! > /usr/bin/printf -- "\x16\x03\x01\x02\x00\x01\x00\x01\xfc\x03" | xxd > --> 0000000: 1603 0102 0001 0001 fc03 .......... > > aber leider nicht für BSD, hier FreeBSD: [...] > > Frage: geht das mit dem FreeBSD printf überhaupt? Solaris sollte > ein ähnliches, externes printf haben IIRC. Das Solaris-printf kann das auch nicht, denn das Linux-printf ist eben eigentlich ein Gnu-printf und hat 1000 Extensions gegenüber Posix... Unter Solaris 11.x gibt es immerhin das Gnu-printf, wenn man das Paket "file/gnu-coreutils" installiert hat: $ /usr/gnu/bin/printf -- "\x16\x03\x01\x02\x00\x01\x00\x01\xfc\x03" | od -x 0000000 0316 0201 0100 0100 03fc Viele Grüße -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Solaris-based Systems Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From wolfgang at lyxys.ka.sub.org Wed Sep 26 09:36:29 2018 From: wolfgang at lyxys.ka.sub.org (Wolfgang Zenker) Date: Wed, 26 Sep 2018 09:36:29 +0200 Subject: [sage] BSD printf In-Reply-To: References: Message-ID: <20180926073629.GA65813@lyxys.ka.sub.org> Hi, * Dirk Wetter [180926 08:57]: > ich habe da ein kleines Problem. Wie einige vielleicht > wissen, habe ich da ein FOSS-Projekt namens testssl.sh. > Eine Kernfunktion sind Sockets. Das Projekt ist abseits > ein paar weniger Unix-Tools drumherum in bash -- der kleinste > gemeinsamste Nenner für BSDs (inkl. OS X), WSL, Cygwin etc. ich vermute, Du meinst /bin/sh, denn bash ist zumindest bei FreeBSD eine optionale Erweiterung. Die /bin/sh ist eine Bourne Shell (ohne "again") und kann nur POSIX.1 plus wenige BSD Erweiterungen. > Auch die Sockets sind in bash programiert über /dev/tcp/*. > Das klappt sogar recht gut. > Leider nur hat das bash interne printf, womit die > Bytes in die Sockets gesendet werden, das Problem, > dass es bei jedem "\x0a" ein write flush macht wird, und > das ein neues Netzpaket wird -- mit dem Resultat, dass > TCP-Fragmentierung auftritt. > Eine elegante Lösung wäre ein externes printf zu benutzen. > Das klappt für Linux, da es genauso funktioniert wie das > bash-Interne, also: > /usr/bin/printf -- "\x16\x03\x01\x02\x00\x01\x00\x01\xfc\x03" | xxd > --> 0000000: 1603 0102 0001 0001 fc03 .......... > aber leider nicht für BSD, hier FreeBSD: > --> > 00000000: 7831 3678 3033 7830 3178 3032 7830 3078 x16x03x01x02x00x > 00000010: 3031 7830 3078 3031 7866 6378 3033 01x00x01xfcx03 > Frage: geht das mit dem FreeBSD printf überhaupt? Solaris sollte > ein ähnliches, externes printf haben IIRC. Sollte gehen, laut Manual (gibts auch im Web unter https://www.freebsd.org/cgi/man.cgi?query=printf&apropos=0&sektion=1&manpath=FreeBSD+11.2-RELEASE+and+Ports&arch=default&format=html ) kann das Teil im Format-String keine Hex-Konstanten mit \x sondern nur Octal Gruß, Wolfgang From pi at c0mplx.org Wed Sep 26 09:50:49 2018 From: pi at c0mplx.org (Kurt Jaeger) Date: Wed, 26 Sep 2018 09:50:49 +0200 Subject: [sage] BSD printf In-Reply-To: References: Message-ID: <20180926075049.GT10573@home.opsec.eu> Hi! > aber leider nicht für BSD, hier FreeBSD: > > --> > 00000000: 7831 3678 3033 7830 3178 3032 7830 3078 x16x03x01x02x00x > 00000010: 3031 7830 3078 3031 7866 6378 3033 01x00x01xfcx03 > > Frage: geht das mit dem FreeBSD printf überhaupt? Solaris sollte > ein ähnliches, externes printf haben IIRC. Aus den Ports, sysutils/coreutils, dort gprintf, kann das. Du verwendest \xHH, und das ist nicht Teil von FreeBSD printf. Waere evt. keine schlechte Idee, das hinzuzufuegen, aber nachdem eine andere Ergaenzung schon laenger (seit 2014) in der Queue haengt: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194466 wird das wohl schwierig. -- pi at opsec.eu +49 171 3101372 2 years to go ! From Juergen.Kahnert at desy.de Wed Sep 26 10:39:00 2018 From: Juergen.Kahnert at desy.de (Juergen Kahnert) Date: Wed, 26 Sep 2018 10:39:00 +0200 Subject: [sage] BSD printf In-Reply-To: References: Message-ID: <20180926083900.GA95689@cthulhu.desy.de> Moin Dirk, On Wed, Sep 26, 2018 at 08:57:19AM +0200, Dirk Wetter wrote: > /usr/bin/printf -- "\x16\x03\x01\x02\x00\x01\x00\x01\xfc\x03" | xxd > --> 0000000: 1603 0102 0001 0001 fc03 .......... > > aber leider nicht für BSD, hier FreeBSD: > > --> > 00000000: 7831 3678 3033 7830 3178 3032 7830 3078 x16x03x01x02x00x > 00000010: 3031 7830 3078 3031 7866 6378 3033 01x00x01xfcx03 das '\x' wird als 'x' erkannt, hast Du es mal Octal probiert? # printf -- "\026\003\001\002\000\001\000\001\374\003" | xxd 00000000: 1603 0102 0001 0001 fc03 .......... Mit freundlichem Gruß Jürgen Kahnert -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3634 bytes Desc: not available URL: From martin.schulte at guug.de Wed Sep 26 11:15:59 2018 From: martin.schulte at guug.de (Martin Schulte) Date: Wed, 26 Sep 2018 11:15:59 +0200 Subject: [sage] BSD printf In-Reply-To: References: Message-ID: <20180926111559.ececa4dbd382470c18e16e7e@guug.de> Hallo Dirk! > Leider nur hat das bash interne printf, womit die > Bytes in die Sockets gesendet werden, das Problem, > dass es bei jedem "\x0a" ein write flush macht wird, und > das ein neues Netzpaket wird -- mit dem Resultat, dass > TCP-Fragmentierung auftritt. Was passiert denn, wenn Du den Output von printf noch durch ein cat pipest? Viele Grüße, Martin From dirk.wetter at guug.de Wed Sep 26 11:22:45 2018 From: dirk.wetter at guug.de (Dirk Wetter) Date: Wed, 26 Sep 2018 11:22:45 +0200 Subject: [sage] BSD printf In-Reply-To: <20180926083900.GA95689@cthulhu.desy.de> References: <20180926083900.GA95689@cthulhu.desy.de> Message-ID: <0c922142-3677-98f5-bebc-4f563ea05533@guug.de> On 9/26/18 10:39 AM, Juergen Kahnert wrote: > Moin Dirk, > > On Wed, Sep 26, 2018 at 08:57:19AM +0200, Dirk Wetter wrote: >> /usr/bin/printf -- "\x16\x03\x01\x02\x00\x01\x00\x01\xfc\x03" | xxd >> --> 0000000: 1603 0102 0001 0001 fc03 .......... >> >> aber leider nicht für BSD, hier FreeBSD: >> >> --> >> 00000000: 7831 3678 3033 7830 3178 3032 7830 3078 x16x03x01x02x00x >> 00000010: 3031 7830 3078 3031 7866 6378 3033 01x00x01xfcx03 > > das '\x' wird als 'x' erkannt, hast Du es mal Octal probiert? > > # printf -- "\026\003\001\002\000\001\000\001\374\003" | xxd > 00000000: 1603 0102 0001 0001 fc03 .......... dann kann ich gleich dd nehmen, weil oktal würde bedeuten, dass wir vieles umschreiben müssen. BG, Dirk From dirk.wetter at guug.de Wed Sep 26 11:44:06 2018 From: dirk.wetter at guug.de (Dirk Wetter) Date: Wed, 26 Sep 2018 11:44:06 +0200 Subject: [sage] BSD printf In-Reply-To: <20180926111559.ececa4dbd382470c18e16e7e@guug.de> References: <20180926111559.ececa4dbd382470c18e16e7e@guug.de> Message-ID: <22851dc2-2b2a-8da1-4b5d-1d777a435bbe@guug.de> On 9/26/18 11:15 AM, Martin Schulte wrote: > Hallo Dirk! > >> Leider nur hat das bash interne printf, womit die >> Bytes in die Sockets gesendet werden, das Problem, >> dass es bei jedem "\x0a" ein write flush macht wird, und >> das ein neues Netzpaket wird -- mit dem Resultat, dass >> TCP-Fragmentierung auftritt. > > Was passiert denn, wenn Du den Output von printf noch durch ein cat > pipest? das gibt falsche Resultate und dauert ewig. Dirk From martin.schulte at guug.de Wed Sep 26 12:05:35 2018 From: martin.schulte at guug.de (Martin Schulte) Date: Wed, 26 Sep 2018 12:05:35 +0200 Subject: [sage] BSD printf In-Reply-To: <22851dc2-2b2a-8da1-4b5d-1d777a435bbe@guug.de> References: <20180926111559.ececa4dbd382470c18e16e7e@guug.de> <22851dc2-2b2a-8da1-4b5d-1d777a435bbe@guug.de> Message-ID: <20180926120535.f453bb56fa67cab63dd08ad7@guug.de> Hallo Dirk! > > Was passiert denn, wenn Du den Output von printf noch durch ein cat > > pipest? > > das gibt falsche Resultate und dauert ewig. Die Zeitproblematik verstehe ich, die falschen Resultate noch nicht, aber ich werde mal forschen... Viele Grüße, Martin From dirk.wetter at guug.de Wed Sep 26 12:34:49 2018 From: dirk.wetter at guug.de (Dirk Wetter) Date: Wed, 26 Sep 2018 12:34:49 +0200 Subject: [sage] BSD printf In-Reply-To: <20180926120535.f453bb56fa67cab63dd08ad7@guug.de> References: <20180926111559.ececa4dbd382470c18e16e7e@guug.de> <22851dc2-2b2a-8da1-4b5d-1d777a435bbe@guug.de> <20180926120535.f453bb56fa67cab63dd08ad7@guug.de> Message-ID: <7d7420e4-688d-1c17-4021-2df16e00cdc8@guug.de> On 9/26/18 12:05 PM, Martin Schulte wrote: > Hallo Dirk! > >>> Was passiert denn, wenn Du den Output von printf noch durch ein cat >>> pipest? >> >> das gibt falsche Resultate und dauert ewig. > > Die Zeitproblematik verstehe ich, die falschen Resultate noch nicht, aber > ich werde mal forschen... ich habe einfach nur cat genommen. Wahrscheinlich muss man cat -A o.ä. beim GNU cat nehmen (BSD ist wieder anders). Es ist dann immer noch das ~dreifache der Scanzeit --> KO-Kriterium. Dirk From jenslink at quux.de Thu Sep 27 08:28:34 2018 From: jenslink at quux.de (Jens Link) Date: Thu, 27 Sep 2018 08:28:34 +0200 Subject: [sage] Adminstammtisch 04.10.2018 Message-ID: <878t3nbgj1.fsf@pc8.berlin.quux.de> Hallo, auch im Oktober gibt es wieder einen Adminstammtisch. Diesmal wird Maximilan Wilhelm uns Contemporary Linux Networking am praktischen Beispiel erklären. Abstract siehe unten. Sollte das ganze auch für Freunde / Bekannte / Kollegen von Interesse sein, leitet diese Mail doch einfach weiter. Jens Ort: Beuth-Hochschule Berlin Haus Bauwesen, Raum D 102 /H2 Luxemburger Straße 9, 13353 Berlin (ÖPNV: U9 Amrumerstr. U9/U6 Leopoldplatz Bus 142 (Hauptbahnhof), Bus 221 Luxemburgerstr.) Zeit: 19:00 Anmeldung für das Bier danach / if you want to have drinks and foods afterwards: https://wolke.quux.de/index.php/apps/polls/poll/xi6O50wKuvQ3THid Abstract: Wir bauen ein Atomkraftwerk äh Netzwerk und zwar Live! Diesmal gibt es kein reines Powerpoint-Waterboarding sondern wir ziehen zusammen Live, in Farbe und vor Ort ein kleines Netzwerk hoch. Dafür bauen wir GRE-Tunnel in dieses Internet – das durch VRFs von unserem internen Netz getrennt ist – und annoucen darüber unsere Prefixe per BGP zu unserem Upstream und verteilen sie in unserem lokalen Netz per iBGP + OSPF. Die Grundlagen für die Aufzucht und Pflege all dieser Dinge wird nur angerissen werden können, da sie in der kürze der Zeit nicht artgerecht vermittelt werden kann. Es werden für alle Themen Videos/Slides zur Verfügung gestellt werden, die die theoretischen Grundlagen vermitteln. Je nach Neugierde, Fragen, Zeit und Hunger bauen wir uns noch VXLAN-Tunnel über unser Netzwerk und stecken diese in (VLAN-aware) Bridges. Wer schon vorher sein theoretisches Wissen zu Netzwerkthemen auffrischen möchte, der werfe einen Blick auf https://blog.sdn.clinic/2018/09/froscon-13-network-track/