Author: yahe

twastosync: Synchronize Mastodon Toots to Twitter

18.11.2019 yahe code

Ever since I built up my own Mastodon instance and created my own account I wanted to be able to cross-post messages between the two platforms. I searched for different solutions like IFTTT but I never got them to work properly - until I found dlvr.it which worked right out of the box for me. Well, at least at the beginning...

I have to admit that I did not use Mastodon regularly for quite some time and even thought about deleting my instance, but I wanted to give it another try now and wanted to use the synchronization feature - which did not work anymore. So I checked my dlvr.it account and found out that the synchronization had silently broken when Mastodon switched from providing Atom feeds to providing RSS feeds. So I reconfigured the synchronization, just to find out that dlvr.it now has limited the free tier to three posts per day. Think about it: three. posts. per day.

Looking at the pricing of dlvr.it I just had to laugh. They want me to pay $8.29 per month for an unlimited amount of messages. In comparison, the server that my Mastodon instance is running on is cheaper than that. My next step was to look for alternatives: circleboom also allows only three posts from an RSS feed per day and for an unlimited number of posts they want to charge you $17.00 per month or $5.99 per month if you are on an annual subscription. socialoomph does not even provide RSS feed synchronization in the free tier and comes at $15.00 per month or $162.00 per year. Finally, I also looked at Hootsuite, which is the strangest of them all. In order to auto-publish posts from an RSS feed you actually have to subscribe to the paid RSS AutoPublisher app which wants to charge you $5.99 per month.

That was the point where I decided to build something on my own. Because, what is better than writing code? Writing code and saving money by doing so. I took one of my previous Twitter tools as a basis and created twastosync. The tool uses the TwitterOAuth library to communicate with the Twitter API and the simplexml_load_string() function of PHP to parse the RSS feed that you can find at the URL https://mastodon-instance-url/@username.rss. Finally, it uses my unchroot library to prevent concurrent executions.

When you installed and configured the script you can use something like CRON to call the twastosync script regularly. Thanks to the concurrency prevention you can even call it every minute. One step that might be a bit scary is to use the app registration page of Twitter to register your own bot. I did this myself and there did not pop up any problem.

There we are: With a small script we are able to synchronize our Mastodon toots to Twitter without relying on a third party platform and by doing it ourselves we are even saving real money. ūü§Ď


.local, .home.arpa and .localzone.xyz

11.11.2019 yahe administration update

35 years ago the IETF defined special IPv4 addresses in RFC 1597 to be used solely in private intranets and with that created the separation between internal networks and the internet. 5 years later they proceeded to define special-use top-level domains like .example, .invalid and .test in RFC 2606. However, the IETF did not reserve a top-level domain to be used within the private intranets that they had introduced before. This lead to confusion with administrators that still persists to the current day.

Every time an administrator was tasked to design a network structure they also had to think about naming conventions within the network. As there was a pre-defined set of "valid" top-level domains within the internet, it was rather easy to just select an "invalid" TLD and use that for the private network. At least, until the ICANN decided to delegate new TLDs to anyone who was willing to apply and pay the required fees. The ICANN even provided a paper on how to identify and mitigate name collisions to be used by professionals.

With RFC 6762 the .local TLD was approved as a special-use TLD to be used in internal networks and many administrators thought that this would solve the problems, but unfortunately, it did not. .local was designated to be used with multicast DNS, meaning that each device in a network could grab its preferred hostname. At the beginning this was not a big deal, but as more and more devices implemented Apple's Bonjour protocol (also known as zeroconf) interoperability problems started to pop up. Appendix G of said RFC even mentioned alternative TLDs that might be used, however, the ICANN did not accept any of them as special-use domain names.

Years later the new RFC 7788 defined .home as a potential local-only TLD, but it was changed to the rather unusual .home.arpa domain name with RFC 8375. This domain is safe to be used in local networks and was accepted as a special-use domain name by the ICANN. Unfortunately, due the word "home" in the domain it is not quite fitting for business environments.

There are two more TLDs that might be safe to use: .corp and .home are not officially recognized special-use domain names but the ICANN has refrained from delegating them to bidders as the risk of breaking internal networks is deemed to be too big.

As of today, most tutorials still propose to use a publicly registered domain for internal networks. This is why I registered .localzone.xyz about half a year ago. It is explicitly meant to be used locally, has public DNS records set to prevent any public CA from issuing trusted TLS certificates for that domain as well as DNS records defining all mails using that domain as SPAM and will not be used for publicly accessible services as long as it is owned by me. I am using this domain internally myself and am also trying to get the domain added to the public suffix list. This list defines domain and cookie boundaries so that e.g. example-a.com is not able to set cookies for example-b.com.

So if you are looking for a domain that you can use for internal domain names then look no further: Either use the special-use domain name .home.arpa (which might not be fitting for businesses) or use .localzone.xyz as I am. It makes clear that you are in a local environment without being too specific about whether it is a private or business network.

Update

On October 6th, 2020 localzone.xyz has finally been added to the public suffix list.


Yahe.sh wechselt ins Englische

04.11.2018 yahe legacy

Im letzten Artikel hatte ich erklärt, weshalb ich mich dazu entschieden habe, von der Domain "weizenspr.eu" hin zur Domain "yahe.sh" zu wechseln. Hintergrund ist der Fokus der Webseite, der sich in den letzten fast 10 Jahren von Alltagserfahrungen hin zu technischen Themen gewandelt hat. Mit dem Wechsel des Themenfeldes geht jedoch auch ein Wechsel des Zielpublikums einher.

In der IT ist Englisch die Sprache der Wahl, um ein m√∂glichst gro√ües Publikum zu erreichen. Daher habe ich mich nach langem Ringen dazu entschlossen, auch diesen Blog zuk√ľnftig auf Englisch zu f√ľhren. Meine Hoffnung ist, dass die Leute, die auch bisher schon meine technischen Inhalte gelesen haben, der englischen Sprache m√§chtig sind. Zumindest in meinem Bekanntenkreis stellt der Sprachwechsel kein Problem dar, er√∂ffnet mir jedoch die M√∂glichkeit einer internationalen Leserschaft.

Daher bleibt mir an dieser Stelle nur noch zu sagen: Welcome to Yahe.sh!


Goodbye WeizenSpr.eu

28.10.2018 yahe legacy

Am 02.02.2009 habe ich die Domain "weizenspr.eu" registriert. Der Blog, der sich dahinter verbarg, durchlebte die Bl√ľtezeit des Bloggens in Deutschland. Damals brauchten Blogs unbedingt ein Motto und so entschied ich mich f√ľr "trennt Spreu vom Weizen". Ich wollte sowohl die guten Dinge ("Weizen"), als auch die schlechten Dinge ("Spreu") im Alltag thematisieren.

Der unbeschwerte Studentenalltag wich dem stressigen Berufsalltag und damit auch die allt√§glichen Themen aus dem Blog und genauso wandelten sich die kurzen Wortmeldungen zu l√§ngeren Themenartikeln. Um dem gerecht zu werden, begann ich, nicht mehr passende Artikel offline zu nehmen, um eine ausgewogenere Webseite zu erhalten. Doch die kleineren Arbeiten hier und da f√ľhrten eher dazu, dass die Seite immer inkonsistenter wurde. Und das urspr√ľngliche Spreu-vs.-Weizen-Konzept machte keinen Sinn mehr. Ein Neuanfang musste her.

Der begann damit, dass ich mich auf Github und auf Twitter umbenannte. Der Nickname, den ich mir ausgesucht habe, basiert entfernt auf meinem Nachnamen und nicht mehr auf einem thematischen Konzept.

Wenn ich schon dabei war, alles neu zu machen, wollte ich in dem Zuge auch gleich die technische Basis meiner Onlinepr√§senz √ľberarbeiten. Seit ich mit WeizenSpr.eu begonnen habe, verwende ich f√ľr alle Webseiten WordPress, was an vielen Stellen eher √ľbertrieben ist. Ich wollte etwas kleineres, schlankeres, schnelleres haben. Ich schaute mir verschiedene dateibasierte Content-Management-Systeme an, war jedoch mit keinem wirklich zufrieden. Also begann ich, in meiner Freizeit das CMS Urlaube zu entwerfen und zu programmieren.

Als das CMS nun im Juli 2018 halbwegs Fortschritte gemacht hatte, begann ich, die Artikel von WeizenSpr.eu zu √ľbertragen. Ich nahm mir jeden Artikel einzeln vor und √ľberlegte, ob er zur neuen Webseite passen w√ľrde. Falls ja, migrierte ich ihn h√§ndisch von HTML zu Markdown. Dabei nahm ich mir die Zeit, Formulierungen zu verbessern, defekte Links zu reparieren und veraltete Inhalte zu aktualisieren. Von den urspr√ľnglich 667 Artikeln haben es 111 Artikel auf die neue Webseite geschafft. All diese Artikel befinden sich in der Legacy-Kategorie.

Die n√§chste Zeit werde ich nun daf√ľr nutzen, neue Artikel zu verfassen, die ich bereits ewig vor mir hergeschoben habe, weil ich unbedingt bis zum Relaunch der Seite warten wollte.

Wie euch aufgefallen sein d√ľrfte, gibt es aktuell noch keine Kommentarfunktion. Ich bin bereits am √ľberlegen, ob und wie diese am besten implementiere. Bis dahin habt ihr nat√ľrlich die M√∂glichkeit, mich per Mastodon, Twitter oder √ľber das Mailkontaktformular zu erreichen.


Vermeiden. Erkennen. Beheben.

21.08.2017 yahe legacy security thoughts

Bereits seit einiger Zeit orientiere ich mich bei der Auswahl von Sicherheitsma√ünahmen an einer Einteilung, die ich bereits im Artikel √ľber die aktive Verteidigung gegen Kryptotrojaner einmal verwendet hatte: Vermeiden. Erkennen. Beheben.

Bisher war ich davon ausgegangen, dass es sich dabei um ein g√§ngiges Modell handelt, schlie√ülich wird es in vielen Bereichen eingesetzt, in denen es um Fehlervermeidung geht. Bezogen auf das Management der Informationssicherheit habe ich jedoch keine relevanten Quellen ausfindig machen k√∂nnen, die sich mit dieser Klassifizierung von Sicherheitsma√ünahmen besch√§ftigt. Aus diesem Grund habe ich mir √ľberlegt, einfach einmal aufzuschreiben, was ich mit den drei Punkten meine und wie deren Anwendung einem helfen kann, die Absicherung der eigenen Informationssicherheit ganzheitlicher zu gestalten.

tl;dr

Anstatt sich im risikoorientierten Sicherheitsmanagement nur mit der Frage zu besch√§ftigen, wie man Sch√§den vermeidet, sollte man in seinen Prozessen auch die Frage ber√ľcksichtigen, wie man entstandene Sch√§den erkennt und wie man diese entstandenen Sch√§den behebt.

Grundsätzliches

Sicherheitsmanagement, wie es heutzutage praktiziert wird, ist prim√§r risikoorientiert. Man baut sich einen Pool an potentiellen Bedrohungen auf; pr√ľft, ob ein spezifisches Asset Schwachstellen hat, die durch eine Bedrohung zu tats√§chlichen Gef√§hrdungen werden; bewertet das daraus entstehende Risiko und √ľberlegt sich, wie man mit diesem Risiko umgehen m√∂chte. M√∂glichkeiten sind die √úbernahme des Risikos, man lebt also damit, dass das Risiko existiert; man transferiert das Risiko auf jemand anderen, z.B. indem man eine Versicherung abschlie√üt; man vermeidet das Risiko, z.B. indem man eine andere technische L√∂sung w√§hlt; oder man reduziert das Risiko, indem man Ma√ünahmen ergreift, die dabei helfen, die Eintrittswahrscheinlichkeit oder die Auswirkung zu verringern.

Wie man erkennt, beschr√§nkt sich diese Form der Betrachtungsweise prim√§r auf die Vermeidung von Sch√§den. Was fehlt, ist die Betrachtung von Ma√ünahmen, die dabei helfen, eingetretene Sch√§den zu erkennen und diese zu beheben. Meiner Erfahrung nach f√ľhrt diese einseitige Herangehensweise dazu, dass sich Unternehmen darauf versteifen, Gefahren abzuwehren und sich zu wenig damit auseinander setzen, was passiert, wenn ein Schaden trotzdem eintreten sollte. Erst in j√ľngerer Zeit scheint es hier ein Umdenken zu geben. Nachdem sogar Sicherheitsunternehmen wie z.B. Antivirenhersteller und Sicherheitsbeh√∂rden gehackt werden, entsteht langsam das Mantra "es stellt sich nicht die Frage, ob man gehackt wird, sondern wann".

Die Klassifizierung von Sicherheitsmaßnahmen in die Kategorien Vermeidung, Erkennung und Behebung, wobei Mehrfachklassifizierungen je nach Nutzungsart durchaus möglich sind, kann dabei helfen, einen ganzheitlichen Ansatz des Sicherheitsmanagements zu etablieren.

Vermeiden

Meiner Erfahrung nach handelt es sich bei der Vermeidung von Sch√§den um den Ma√ünahmenkomplex, den Unternehmen als erstes betrachten, wenn sie sich mit dem Thema Sicherheits- oder Risikomanagement besch√§ftigen. Als ich begonnen habe, mich mit der IT-Security zu besch√§ftigen, ist man h√§ufig noch davon ausgegangen, dass es ausreichend ist, gen√ľgend technische Ma√ünahmen zu ergreifen, um sich vollst√§ndig abzusichern. Das Nutzen von Verschl√ľsselung, der Einsatz von Antivirenscannern und Firewalls, das Nutzen von RAIDs, das Erstellen von Backups, sowie das regelm√§√üige Patchen von Anwendungen waren die klassischen zu ergreifenden Ma√ünahmen. Wie bereits weiter oben beschrieben, f√ľhren auch die klassischen Risikomanagementmethoden dazu, sich prim√§r mit Ma√ünahmen zur Vermeidung von Sch√§den zu besch√§ftigen.

Erkennen

Die Erkennung von Sch√§den ist, so zumindest meine Erfahrung, selten vom Gedanken des Risikomanagements getrieben, daf√ľr aber umso h√§ufiger vom Gedanken der operativen Funktionst√ľchtigkeit. Die klassische Erkennungsmethode ist der Einsatz einer Monitoringl√∂sung im IT-Umfeld. Diese beschr√§nkt sich jedoch sehr h√§ufig auf Themen wie die Verf√ľgbarkeit von Services und der Ressourcenauslastung von Hardware.

Nur selten wird sie genutzt, um regelm√§√üig nach ver√§nderten Dateien, unzul√§ssigen Netzwerkverbindungen, unbekannten Prozessen oder bekannten Prozessen mit unbekannten Parameterlisten zu scannen. Hintergrund d√ľrfte auch sein, dass sich das Erkennen von Verf√ľgbarkeitsproblemen recht einfach standardisieren l√§sst, w√§hrend Verhaltensmuster von Systemen und Anwendungen sehr unterschiedlich sein k√∂nnen und eines individuelles Profiling bed√ľrfen. Das f√ľhrt dazu, dass solche komplexeren Erkennungen in Form von IDS- und IPS-L√∂sungen erst dann zum Einsatz kommen, wenn das gesamte Sicherheitsmanagement des Unternehmens einen gewissen Reifegrad erreicht hat.

Eine andere klassische Ma√ünahme ist die Einf√ľhrung einer zentralen Logging-Infrastruktur, die es prinzipiell erm√∂glicht, durch das Analysieren einer Vielzahl von Systemevents einen m√∂glichen Schaden zu erkennen. Aber auch hier m√ľssen erst im Zuge einer SIEM-L√∂sung entsprechende Trigger definiert werden, bevor ein tats√§chlicher Nutzen aus der Ma√ünahme gezogen werden kann.

Doch auch abseits der Technik sollte man sich im Zuge seines Risikomanagements immer die Frage stellen, welche Ma√ünahmen ergriffen werden, um das Eintreten eines Schadens √ľberhaupt erkennen zu k√∂nnen.

Beheben

Nachdem man sich Gedanken gemacht hat, wie man eingetretene Sch√§den erkennt, besteht die schlussendliche Arbeit darin, sich zu √ľberlegen, wie man den Schaden wieder beheben kann. Eine klassische Ma√ünahme zur Behebung von Sch√§den ist das Wiedereinspielen von Backups oder das Neuaufsetzen von kompromittierten Systemen. Doch evtl. muss je nach Anwendung granularer vorgegangen werden oder es ergibt sich die M√∂glichkeit, die Behebung einzelner Sch√§den automatisiert durchzuf√ľhren.

Meiner Erfahrung nach bestehen viele Ma√ünahmen zur Behebung von Sch√§den im ersten Schritt aus spontanen Ideen, die im tats√§chlichen Ernstfall umgesetzt werden. Diese verfestigen sich anschlie√üend durch die Formulierung von Wiederherstellungspl√§nen oder, gr√∂ber gefasst, durch Notfallpl√§ne im Zuge der Etablierung eines Notfallmanagements. Die erstellten Pl√§ne st√ľtzen sich anfangs oft vor allem auf h√§ndische Prozesse. Erst bei zunehmender Reife werden manuelle Arbeiten durch automatisierte Tasks abgel√∂st. Denn auch hier m√ľssen viele individuelle Aspekte ber√ľcksichtigt werden.

Auch abseits der Technik sollte man sich Gedanken √ľber die Behebung von Sch√§den machen. Wie reagiert man als Unternehmen, wenn essentielle Ressourcen nicht zur Verf√ľgung stehen oder wie w√ľrde man beim Abhandenkommen sensibler Daten vorgehen?

Praxisbeispiel

Um diese Dreiteilung an Ma√ünahmen einmal im Zusammenspiel zu zeigen, m√∂chte ich einmal Antivirensoftware als plakatives Beispiel w√§hlen, unabh√§ngig von der Diskussion √ľber deren tats√§chlichen Nutzen.

Wir beginnen mit der Hauptaufgabe von Antivirensoftware, dem Erkennen von Viren. Im ersten Schritt wird man nur einzelne Dateien gepr√ľft haben und diese Ma√ünahme St√ľck f√ľr St√ľck erweitert haben; um das Scannen ganzer Ordner, um das Scannen des ganzen Systems und schlussendlich auch um das Scannen des Bootsektors. Die Erkennung erfolgte fr√ľher allein auf Basis einer Virensignatur, sprich, der Information dar√ľber, wie der kompilierte Quelltext des Virus aussieht.

Als man Viren erkennen konnte, stellte sich die Frage, wie man mit ihnen umgeht, sprich, wie das Beheben eines Virenbefalls aussehen k√∂nnte. Man k√∂nnte sie z.B. in Quarant√§ne schieben, sie direkt l√∂schen oder, mit entsprechend viel Wissen √ľber den Virus, diesen evtl. sogar aus einer infizierten Datei entfernen.

Als man nun weiter fortschritt, Festplatten gr√∂√üer und die Scans damit zeitaufw√§ndiger wurden, kam man evtl. nicht mehr dazu, regelm√§√üig alle Dateien h√§ndisch zu pr√ľfen. Trotzdem war es wichtig, zu verhindern, dass eine virenverseuchte Datei ge√∂ffnet oder verteilt wird. Also begann man damit, Dateien noch vor einem tats√§chlichen Zugriff zu pr√ľfen. Das Live-Scannen von Dateien half, das Ausf√ľhren von Viren zu vermeiden, optimierte gleichzeitig aber auch das Erkennen von Viren.

Viren wurde intelligenter und polymorph, ihr Quelltext √§nderte sich regelm√§√üig, sodass einfache Virensignaturen nicht mehr in der Lage waren, diese zu erkennen. Erst durch die Einf√ľhrung von Heuristiken kam Antivirensoftware dazu, auch diese neuen, komplexeren Viren √ľberhaupt erkennen zu k√∂nnen.

Das Internet hielt Einzug und verdr√§ngte Wechseldatentr√§ger als prim√§res Einfallstor f√ľr Viren. Die Hersteller von Antivirensoftware gingen mit und begannen, sich in den Datenkanal einzuklinken. Man wollte Viren bereits erkennen k√∂nnen, noch bevor sie auf der Festplatte des Nutzers gespeichert werden. Das sollte auch vermeiden, dass Nutzer √ľberhaupt die M√∂glichkeit haben, irgendetwas mit der virenverseuchten Datei anstellen zu k√∂nnen.

Im Businessumfeld sind die Risiken, die von einem Virenbefall ausgehen, sogar noch gr√∂√üer, als in anderen Bereichen. Virenschreiber haben es vor allem auch auf diesen Bereich abgesehen, mitunter sogar mit speziell entwickelten Viren. Aber auch Antivirenhersteller haben dies erkannt und bieten spezifische L√∂sungen f√ľr solche Unternehmen an. Eine L√∂sung ist, Anwendungen vor ihrem Download auf einen Nutzerrechner in einer VM einer Scanning-Appliance gezielt zur Ausf√ľhrung zu bringen, um ein verd√§chtiges Verhalten dieser Anwendung bereits im Vorfeld erkennen zu k√∂nnen. Hiermit will man die Ausf√ľhrung eines Virus auf einem Nutzerrechner vermeiden.

Fazit

Wie man am Beispiel der Antivirensoftware gut erkennen kann, kann die Klassifizierung von Maßnahmen in die Themenfelder Vermeidung, Erkennung und Behebung dabei helfen, diese besser in einem gesamtheitlichen Sicherheitsansatz zu begreifen. Je nach Reifegrad des Sicherheitsmanagements im eigenen Unternehmen sollte man sich einmal ansehen, in welchem der drei Themenkomplexe noch Nachholbedarf bzgl. der geplanten und umgesetzten Maßnahmen besteht.


Search

Links

RSS feed

Categories

administration (43)
arduino (12)
calcpw (2)
code (37)
hardware (16)
java (2)
legacy (113)
linux (29)
publicity (7)
review (2)
security (62)
thoughts (22)
update (9)
windows (17)
wordpress (19)