October 2018 - Admin - Freifunk Nordwest

srv who is who - key fingerprint
by picard 20 Jan '24

20 Jan '24

moin, beim login auf den srv01 passierte heute # ssh srv01 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:LX0xpviTs3pSYWtibqspcjoqDDxrkzA1kw0F+4ZmXps. Please contact your system administrator. was ist hier los? The authenticity of host 'srv01.ffnw.de (37.120.176.207)' can't be established. RSA key fingerprint is SHA256:LX0xpviTs3pSYWtibqspcjoqDDxrkzA1kw0F+4ZmXps. RSA key fingerprint is MD5:97:7f:f3:b0:7f:57:04:d1:96:15:7f:eb:bc:de:17:6e. es macht sinn das man weiss das man sich auf den richtigen srv verbindet, wieso hat sich was am key geändert? wo stehen die fingerprints zum vergleichen? -- Freifunk Gruß pic Www: https://fr32k.de Xmpp: picard(a)fr32k.de & picard(a)ffnw.de Keybase: https://keybase.io/picard -- Gruß pic Xmpp: picard(a)ffnw.de & picard(a)fr32k.de @ME https://wiki.nordwest.freifunk.net/picard

5 6

Fwd: Systemd is bad parsing and should feel bad [security] [systemd]
by Jan-Tarek Butt 30 Oct '18

30 Oct '18

FYI Via: https://blog.erratasec.com/2018/10/systemd-is-bad-parsing-and-should-feel.h… Systemd has a remotely exploitable bug in it's DHCPv6 client. That means anybody on the local network can send you a packet and take control of your computer. The flaw is a typical buffer-overflow. Several news stories have pointed out that this client was written from scratch, as if that were the moral failing, instead of reusing existing code. That's not the problem. The problem is that it was written from scratch without taking advantage of the lessons of the past. It makes the same mistakes all over again. In the late 1990s and early 2000s, we learned that parsing input is a problem. The traditional ad hoc approach you were taught in school is wrong. It's wrong from an abstract theoretical point of view. It's wrong from the practical point of view, error prone and leading to spaghetti code. The first thing you need to unlearn is byte-swapping. I know that this was some sort epiphany you had when you learned network programming but byte-swapping is wrong. If you find yourself using a macro to swap bytes, like the be16toh() macro used in this code, then you are doing it wrong. But, you say, the network byte-order is big-endian, while today's Intel and ARM processors are little-endian. So you have to swap bytes, don't you? No. As proof of the matter I point to every other language other than C/C++. They don't don't swap bytes. Their internal integer format is undefined. Indeed, something like JavaScript may be storing numbers as a floating points. You can't muck around with the internal format of their integers even if you wanted to. An example of byte swapping in the code is something like this: In this code, it's taking a buffer of raw bytes from the DHCPv6 packet and "casting" it as a C internal structure. The packet contains a two-byte big-endian length field, "option->len", which the code must byte-swap in order to use. Among the errors here is casting an internal structure over external data. From an abstract theory point of view, this is wrong. Internal structures are undefined. Just because you can sort of know the definition in C/C++ doesn't change the fact that they are still undefined. From a practical point of view, this leads to confusion, as the programmer is never quite clear as to the boundary between external and internal data. You are supposed to rigorously verify external data, because the hacker controls it. You don't keep double-checking and second-guessing internal data, because that would be stupid. When you blur the lines between internal and external data, then your checks get muddled up. Yes you can, in C/C++, cast an internal structure over external data. But just because you can doesn't mean you should. What you should do instead is parse data the same way as if you were writing code in JavaScript. For example, to grab the DHCP6 option length field, you should write something like: The thing about this code is that you don't know whether it's JavaScript or C, because it's both, and it does the same thing for both. Byte "swapping" isn't happening. We aren't extracting an integer from a packet, then changing it's internal format. Instead, we are extracting two bytes and combining them. This description may seem like needless pedantry, but it's really really important that you grok this. For example, there is no conditional macro here that does one operation for a little-endian CPU, and another operation for a big-endian CPU -- it does the same thing for both CPUs. Whatever words you want to use to describe the difference, it's still profound and important. The other thing that you shouldn't do, even though C/C++ allows it, is pointer arithmetic. Again, it's one of those epiphany things C programmers remember from their early days. It's something they just couldn't grasp until one day they did, and then they fell in love with it. Except it's bad. The reason you struggled to grok it is because it's stupid and you shouldn't be using it. No other language has it, because it's bad. I mean, back in the day, it was a useful performance optimization. Iterating through an array can be faster adding to pointer than incrementing an index. But that's virtually never the case today, and it just leads to needless spaghetti code. It leads to convoluted constructions like the following at the heart of this bug where you have to both do arithmetic on the pointer as well as on the length which you are checking against. This nonsense leads to confusion and ultimately, buffer overflows. In a heckofalot of buffer overflows over the years, there's a construct just like this lurking near the bug. If you are going to do a rewrite of code, then this is a construct you need to avoid. Just say no to pointer arithmetic. In my code, you see a lot of constructs where it's buf, offset, and length. The buf variable points to the start of the buffer and is never incremented. The length variable is the max length of the buffer and likewise never changes. It's the offset variable that is incremented throughout. Because of simplicity, buffer overflow checks become obvious, as it's always "offset + x < length", and easy to verify. In contrast, here is the fix for the DHCPv6 buffer overflow. That this is checking for an external buffer overflow is less obvious: Now let's look at that error code. That's not what ENOBUFS really means. That's an operating system error code that has specific meaning about kernel buffers. Overloading it for userland code is inappropriate. That argument is a bit pedantic I grant you, but that's only the start. The bigger issue is that it's identifying the symptom not the problem. The ultimate problem is that the code failed to sanitize the original input, allowing the hacker to drive computation this deep in the system. The error isn't that the buffer is too small to hold the output, the original error is that the input was too big. Imagine if this gets logged and the sysadmin reviewing dmesg asks themselves how they can allocate bigger buffers to the DHCP6 daemon. That is entirely the wrong idea. Again, we go back to lessons of 20 years that this code ignored, the necessity of sanitizing input. Now let's look at assert(). This is a feature in C that we use to double-check things in order to catch programming mistakes early. An example is the code below, which is checking for programming mistakes where the caller of the function may have used NULL-pointers: This is pretty normal, but now consider this other use of assert(). This isn't checking errors by the programmer here, but is instead validating input. That's not what you are supposed to use asserts for. This are very different things. It's a coding horror that makes you shriek and run away when you see it. In my fact, that's my Halloween costume this year, using asserts to validate network input. This reflects a naive misunderstanding by programmers who don't understand the difference between out-of-band checks validating the code, and what the code is supposed to be doing validating input. Like the buffer overflow check above, EINVAL because a programmer made a mistake is a vastly different error than EINVAL because a hacker tried to inject bad input. These aren't the same things, they aren't even in the same realm. Conclusion Rewriting old code is a good thing -- as long as you are fixing the problems of the past and not repeating them. We have 20 years of experience with what goes wrong in network code. We have academic disciplines like langsec that study the problem. We have lots of good examples of network parsing done well. There is really no excuse for code that is of this low quality. This code has no redeeming features. It must be thrown away and rewritten yet again. This time by an experienced programmer who know what error codes mean, how to use asserts properly, and most of all, who has experience at network programming.

1 0

help
by robert＠famkoes.de 23 Oct '18

23 Oct '18

help

1 0

Wartungsarbeiten VLAN Fra - Ber
by Stefan Dunkel 22 Oct '18

22 Oct '18

Hallo zusammen, aufgrund von Wartungsarbeiten ist die Verbindung zwischen FRA und BER gerade nicht möglich und dadurch die MAP nicht erreichbar. Heute Nacht bringen wir ein neues VLAN online und dazu ist dies leider nötig. Vermutlich wird die map morgen erst wieder online sein. Von meinem iPhone gesendet

1 0

vec01 kompromittiert
by Bjoern Franke 18 Oct '18

18 Oct '18

Moin, vec01 war anscheined einen Monat lang kompromittiert, Zugang wurde wahrscheinlich per VNC erlangt, da dieser auch von außen erreichbar war und ein mieses Passwort hatte. Ebenso hatte wahrscheinlich einer der User ein schlechtes Passwort. Installiert wurden im kompromittierten System dropbear, ein Socks-Server sowie tor, von dort wurden vermutlich weitere Scans etc. ausgeführt. Und nicht zu vergessen: grub2-setpassword. Aus einem alten vec01-Klon stand letztes Jahr wurde eine VM erstellt, diese läuft momentan noch auf jessie. Ein gestriger Check auf unseren VMHosts brachte keine weiteren offenen VNCs zu Tage, ebenso ist angedacht, "sudo ohne Passwort" für unsere Benutzer abzuschalten. Grüße bjo

5 6

Grub Passwort vec01
by Bjoern Franke 17 Oct '18

17 Oct '18

Moin, wer hielt es denn vor ca. 10 Tagen für eine gute Idee, den Grub von vec01 mit einem Passwort zu versehen? Grüße bjo

1 0

Re: [Dev] Re: täglicher hoodkurschluss default02 <-> Delmenhorst
by Simon Kurka 16 Oct '18

16 Oct '18

Kann ich mir kaum vorstellen und hätte das gerne nachgesehen, aber das git gibt einen 503. Wer hat da wie dran herumgespielt? Stefan Dunkel via Dev <dev(a)lists.ffnw.de> schrieb am Di., 16. Okt. 2018, 12:57: > Hi, > > nope, das hatten wir damals nicht so implementiert... > > Ich überlege mir was. > > > Von meinem iPhone gesendet > > Am 16.10.2018 um 12:45 schrieb Simon Kurka via Dev <dev(a)lists.ffnw.de>: > > Müsste über die common.yml im puppet-data repo gehen. > > lrnzo via Dev <dev(a)lists.ffnw.de> schrieb am Di., 16. Okt. 2018, 12:44: > >> Moin, >> >> hatte heute früh testweise mal die /etc/fastd/blacklist.json auf >> default02.sn.ffnw.de um einen Eintrag für den Kurzschlussrouter mit MAC >> 8e:83:b2:79:67:3f und key 4ff1ae9a58fe95290290eb4d7826c91675fe1614990472 >> erweitert, allerdings hat vermutlich puppet meine Änderung wieder >> rückgängig gemacht. Wie kann der genannte key dauerhaft geblacklisted >> werden? >> >> LG Lorenz >> _______________________________________________ >> Dev mailing list -- dev(a)lists.ffnw.de >> To unsubscribe send an email to dev-leave(a)lists.ffnw.de >> > _______________________________________________ > Dev mailing list -- dev(a)lists.ffnw.de > To unsubscribe send an email to dev-leave(a)lists.ffnw.de > > _______________________________________________ > Dev mailing list -- dev(a)lists.ffnw.de > To unsubscribe send an email to dev-leave(a)lists.ffnw.de >

1 0

Verwendung srv03, srv09, srv10, srv11
by Bjoern Franke 16 Oct '18

16 Oct '18

Moin, ein Bytemine-Kollege und ich waren am Donnerstag und Freitag zwecks RZ-Arbeiten in Frankfurt und haben von dort einen Haufen abgeschalteter Hardware mitgenommen, u.a. unsere alten Server srv03, srv09, srv10 und srv11. srv03 könnte man vermutlich noch für irgendwas nützliches verwenden, die restlichen Kisten taugen vermutlich nur noch als Heizung - oder haben wir dafür noch irgendeine Verwendung? Grüße bjo

1 1

Gateway für neue Freifunk Untergruppe einrichten
by Niklas (Freifunk Lingen) 15 Oct '18

15 Oct '18

Hallo zusammen, wir sind gerade dabei, in Lingen (im Landkreis Emsland) eine lokale Freifunk Gruppe zu gründen und haben auch bereits erste Router aufgestellt. Nun wollen wir uns mit der Server Infrastruktur näher beschäftigen, um für Lingen zukünftig eine eigene Hood einrichten zu können. Wir haben auch bereits eine KVM VM vorbereitet, um dort ein Freifunk Gateway einzurichten. Gibt es hierzu Anleitungen bzw. Tipps für die Vorgehensweise? Wir haben schon im FFNW Wiki geschaut und im Gitlab das Puppet Repository entdeckt (worauf wir jedoch nicht zugreifen können). Wie läuft die Anbindung an das FFNW Netz bzw. an das Internet über den Freifunk Rheinland? Besten Dank für eure Hilfe schon im Voraus! Gruß Niklas

4 9

Geschäfts- / Projektkredit bei 1,3%
by Access Business Capital 11 Oct '18

11 Oct '18

-- Grüße Herr / Frau. Sind Sie auf der Suche nach einem Geschäfts- oder Projektkredit? Wir unterstützen wachsende Unternehmen / Unternehmen bei der Finanzierung, die sie benötigen, um zu expandieren, mit unserem Cashflow-Finance-Fast-Service-Darlehen in Höhe von 1,3% Wenn Sie interessiert sind, senden Sie uns Ihre Bewerbungsdetails wie unten angegeben, und wir werden Ihnen mit weiteren Informationen und allen rechtlichen Dokumenten antworten, um Ihnen einen Kredit zu sichern. Vollständiger Name:.............................. Darlehensbetrag: .............................. Darlehensdauer: .............................. Darlehen Zweck:.............................. Telefon:.............................. Wir erwarten Ihre dringende Antwort. Freundliche Grüße. Morris Horace. Kreditberater. Access Business Capital UK 40 Bloomsbury Way, Lower Ground Floor, London WC1A 2SE, United Kingdom

1 0