Ich habe als Anhang zum Artikel PhantomJS: Hyperlinks einer Website auflisten; mit Unterstützung für JavaScript und Frames noch Lösungen mit Selenium in Perl und Python angefügt.
PS: Es sollten nun auch alle Frames durchlaufen werden, das funktionierte Gestern nicht und es war ein Logik-Fehler.
PPS: Noch spiele ich damit etwas :-) und vielleicht tue ich das mal nach GitHub… Mehr Blogeinträge wird es über Updates aber wohl nicht geben und auch diesen werde ich später wieder löschen.
In dieser neuen Serie (nach Mutt) werde ich über die Grundlagen der Server Absicherung schreiben. Ich möchte darauf hinweisen, dass diese Serie jediglich als Grundorientierung dient. Zusätzlich ist darauf zu achten, sich immer im “Saft” zu befinden, da sich fast täglich neue Gefahren entwicklen, auf die der Admin achten sollte.
Als letztes möchte ich darauf hinweisen, dass alle hier aufgelisteten Empfehlungen auf persönlicher Erfahrung beruhen.
Im folgenden gehe ich davon aus, dass wir von einem Linux Server sprechen. Ich persönlich arbeite nicht mit Windows Servern und kann daher kein Wissen über diese Infrastruktur teilen.
Debian empfiehlt sich sehr als Betriebsystem für einen Server. Debian ist weit verbreitet und wird von vielen Menschen als Serverunterbau verwendet. Aufgrund der einzelen Release Channels (stable, testing, unstable) ist schon ein bisschen “Sicherheit” gewährleistet. Natürlich ist klar, dass nur der Channel stable verwendet werden sollte.
Dazu kann ich folgende /etc/apt/sources.list empfehlen:
deb http://deb.debian.org/debian/ stable main contrib non-free
deb-src http://deb.debian.org/debian/ stable main contrib non-free
deb http://deb.debian.org/debian/ stable-updates main contrib non-free
deb-src http://deb.debian.org/debian/ stable-updates main contrib non-free
deb http://deb.debian.org/debian-security stable/updates main
deb-src http://deb.debian.org/debian-security stable/updates main
deb http://ftp.debian.org/debian stretch-backports main
deb-src http://ftp.debian.org/debian stretch-backports mainWichtig ist das System immer auf den aktuellen Stand zu halten um bekannte Sicherheitslücken und Fehler in Software schnellst möglich zu schließen. Ich bin kein Freund von automatischen Updates, da ich selber gerne weiß was mein System macht.
Für die unter euch die gerne einen solchen Dienst nutzen wollen, empfehle euch euch das Debian Wiki.
Eine weitere Möglichkeit, die benutze ich persönlich auch, ist es sich über neue Paket per Mail informieren zu lassen. Dazu benötigt man das Paket apticron. Im Thomas Krenn Wiki ist sehr gut beschrieben, wie diese konfiguriert wird, daher gehe ich nicht weiter darauf ein.
Für die Mail Benachrichtigungen nutze ich statt mail das Programm ssmtp. Einfach zu installieren mit dem Befehl
apt install ssmtpDie Konfiguration der Datei /etc/ssmtp/ssmtp.conf sollte dann so aussehen
#Alias für root
root=root@example.de
#Server Setup
mailhub=mail.example.de:587
AuthUser=test@example.de #mailadresse
AuthPass=Password
UseSTARTTLS=YES
TLS_CA_File=/etc/ssl/certs/ca-certificates.crt
hostname=example.de #hostnameMit dem Befehl ssmtp -vt < mail.eml ist es möglich die Konfiguration zu testem. Die Datei mail.eml hat folgenden Inhalt
From: MyPBX < root@example.de >
To: harry < root@example.de >
Subject: test
MIME-Version: 1.0Lynis ist ein Secuirty Tool, was den Server mit einem “Health Scan” überprüft und dann auf Fehlerhafte oder gar nicht vorhanden Konfiguration hinweist. Das Tool ist leider bei Debian veraltet darum bietet sich an die eigne Repository hinzuzufügen. Dafür muss als erstes aber ein Paket installiert werden:
apt install apt-transport-httpsDann wird der PGP Schlüssel installiert
wget -O - https://packages.cisofy.com/keys/cisofy-software-public.key | apt-key add -Jetzt die Liste hinzufügen
echo "deb https://packages.cisofy.com/community/lynis/deb/ stable main" | tee /etc/apt/sources.list.d/cisofy-lynis.listJetzt updaten und installieren
apt update && apt install lynisMit dem Befehl lynis update info kann man den aktuellen Stand der Software prüfen
root@vps73846:~# lynis update info
== Lynis ==
Version : 2.6.4
Status : Up-to-date
Release date : 2018-05-02
Update location : https://cisofy.com/lynis/
2007-2018, CISOfy - https://cisofy.com/lynis/Als nächstes überprüfen wir das System lynis audit system auch Dockerfiles können geprüft werden mit lynis audit dockerfile
Die Ausgabe sieht dann wie folgt aus
....
================================================================================
Lynis security scan details:
Hardening index : 77 [############### ]
Tests performed : 218
Plugins enabled : 0
Components:
- Firewall [V]
- Malware scanner [V]
Lynis Modules:
- Compliance Status [?]
- Security Audit [V]
- Vulnerability Scan [V]
Files:
- Test and debug information : /var/log/lynis.log
- Report data : /var/log/lynis-report.dat
================================================================================
....An dem Hardening Index ist zu erkennen, dass noch einiges zutun ist. In den folgenden Artikel werde ich auf die Konfigurationen eingehen, so dass dieser Score noch deutlich steigen wird.
Kurz angemerkt: die Abmahnwelle ist angelaufen. Und auch die Kanzlei WBS hat auf YouTube bereits ein Video zu dem Thema veröffentlicht.
Folgenlos zieht dies an diesem Blog nicht vorbei, es gibt einige Änderungen. Zum einen ist die Kommentarfunktion nun seit einiger Zeit deaktiviert. Leserbriefe und Kommentare können gerne weiterhin gem. meiner Datenschutzerklärung an info@v-gar.de gesandt werden, ich freue mich über jeden (konstruktiven) Kommentar auf diesem Weg.
Die zweite Änderung ist etwas tiefgreifender. Im Abmahnärger geht es auch darum, dass der Datenschutzerklärung eingewilligt werden soll, bevor Daten zu Google über Google Fonts übertragen werden. Bei WordPress, dem bei mir eingesetzten Blogsystem, von dem ich demnächst weg migrieren werde, ist das schon etwas schwieriger in der Umsetzung. Daher nun die “Datenschutzerklärungs-Dampframme” oder diplomatischer, der “Privacy Consent Checker”.
Hierbei handelt es sich um ein vor mir auf GitHub open source veröffentlichtes PHP-Script, das sich insbesondere für WordPress eignet. Die Arbeitsweise ist dreckig und tut einem Softwareentwickler in der Seele weh, aber es funktioniert. Kurz zusammengefasst: wenn kein Lese-Cookie erkannt wird, wird auf jeder Seite des Blogs eine HTML-Seite mit der Datenschutzerklärung und Möglichkeit zur Kenntnisnahme angezeigt. Erst nach einer Lesebestätigung (und dem Setzen des Cookies) wird WordPress geladen. Vorteil: man kann vorher sogar schon das Matomo-Opt-Out machen. Außerdem wird die Datenschutzerklärung gezeigt, *bevor* Google Fonts geladen wird.
Umgesetzt wird dies durch Einbinden des Scripts in der index.php (das ist der besondere dreckige Part, weil ich keine Hooks nutze/nutzen kann und WordPresss das wohl bei jedem Update überschreiben wird). Dank URL-Rewriting wird diese ja jedes Mal diese bootstrap-artige index.php aufgerufen und ich kriege es global auf dem Blog umgesetzt.
Web Crawler und Feed-Parser sind von dieser Aktion nicht betroffen und dürften ungestört die Seite lesen können.
Wie gesagt, Code ist auf GitHub. Über Mitarbeit und Hilfe bei der Übersetzung in andere Sprachen würde ich mich sehr freuen. Das Script entstand sehr kurzfristig und hat demnach noch etwas Potential. Der Einsatz des Scripts erfolgt auf eigene Gefahr, es kann keine Haftung übernommen werden.
Abschließend gesagt: ich hoffe, dass sich diese Unklarheiten/Grauzonen bzgl. der Umsetzung der DSGVO zeitnah klären werden und sehe dieses Script nur als temporäre Lösung!
Ich freue mich über (E-Mail) Feedback!
Seit kurzem gibt es eine Suchmaschine für öffentliche XMPP1 MUCs2, also Gruppenchats, namens Christopher Muclumbus. Wenn ihr die MUCs auf eurem XMPP-Server indizieren lassen wollt müsst ihr einfach christopher.muclumbus@dreckshal.de in einen MUC auf eurem Server einladen. Der Bot sucht dann selbstständig nach weiteren MUCs auf diesem Server.
Dieser Artikel ist auf Wunsch von intux entstanden.
Im folgenden Artikel möchte ich darauf eingehen, wie man Prosody mit Let’s Encrypt nutzen kann, ohne Zertifikate zu kopieren, Script zu schreiben oder die Rechte auf die Zertifikate zu ändern, damit Prosody sie lesen und nutzen kann.
Im Artikel gehe ich davon aus, dass ihr Prosody bereits installiert und eingerichtet habt. Zusätzlich gehe ich davon aus, dass ihr mit LE bereits für die entsprechende Domain Zertifikate angefordert habe und zwar für:
Das lässt sich sehr schön mit der DNS Überprüfung von LE lösen.
Die Zertifikate sollten in dem Ordner
/etc/letsencrypt/live/example.de/
liegen und ihr nutzt den certbot für die Erstellung eurer Zertifikate.
Ich werde nur ganz kurz anschneiden, wie eine “sichere” SSL Konfiguration für die Verwendung mit Prosody aussehen sollte:
c2s_require_encryption = true;
s2s_require_encryption = true;
s2s_secure_auth = true;
ssl = {
protocol = "tlsv1_2";
ciphers = "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128";
options = { "no_sslv2", "no_sslv3", "no_ticket", "no_compression", "cipher_server_preference", "single_dh_use", "single_ecdh_use" };
dhparam = "/etc/prosody/dhparam.pem";
}Bitte keine Angaben in die Datei wo das Zertifikate liegt, wenn ihr diese bereits habt, könnt ihr diese löschen.
Die Datei /etc/prosody/dhparam.pem wird mit dem folgenden Befehl erstellt:
openssl dhparam -dsaparam -out /etc/prosody/dhparam.pem 4096Achtung: Das dauert sehr lange, ich empfehle es mit screen zu machen.
So jetzt kommen wir zum eigentlichen Teil, wichtig hier, dass ihr min. Version 0.10 habt:
root@vps73846:/etc/prosody# apt-cache policy prosody
prosody:
Installed: 0.10.1-1~stretch1
Candidate: 0.10.1-1~stretch1
Version table:
*** 0.10.1-1~stretch1 500Um die aktuelle Version unter Debian Stable (Stretch) zu bekommen, solltet ihr die Prosody Repo nutzen.
So jetzt führen wir einfach den folgenden Befehl aus:
prosodyctl --root cert import /etc/letsencrypt/liveWichtig, nur auf den live Ordner, nicht im example.de Ordner.
Prosody erkennt automatisch die richtigen Zertifikate und konfiguriert sich dementsprechend. Das war es eigentlich auch schon. Aber nur fast.
Das Problem, die Zertifikate müssen nach jedem neu erstellen wieder eingelesen werden. Dazu nutzen wir die Möglichkeit der globalen Konfigurationsdatei von Let’s Encrypt, /etc/letsencrypt/cli.ini
Der Inhalt sollte so aussehen, ja ihr müsste die Datei erst anlegen
# Global config for letsencrypt runs
#
# Note that these options apply automatically to all use of Certbot for
# obtaining or renewing certificates, so options specific to a single
# certificate on a system with several certificates should not be placed
# here.
renew-hook = prosodyctl --root cert import /etc/letsencrypt/live
post-hook = prosodyctl --root cert import /etc/letsencrypt/liveSo das wars. Jetzt haben wir Prosody mit den aktuellen LE Zertifikaten ausgerüstet und auch dafür gesorgt, das es immer die aktuellen Zertifikate bekommt.
In dieser neuen Serie (nach Mutt) werde ich über die Grundlagen der Server Absicherung schreiben. Ich möchte darauf hinweisen, dass diese Serie jediglich als Grundorientierung dient. Zusätzlich ist darauf zu achten, sich immer im "Saft" zu befinden, da sich fast täglich neue Gefahren entwicklen, auf die der Admin achten sollte.
Als letztes möchte ich darauf hinweisen, dass alle hier aufgelisteten Empfehlungen auf persönlicher Erfahrung beruhen.
Im folgenden gehe ich davon aus, dass wir von einem Linux Server sprechen. Ich persönlich arbeite nicht mit Windows Servern und kann daher kein Wissen über diese Infrastruktur teilen.
## Debian / Ubuntu
Debian empfiehlt sich sehr als Betriebsystem für einen Server. Debian ist weit verbreitet und wird von vielen Menschen als Serverunterbau verwendet. Aufgrund der einzelen Release Channels (stable, testing, unstable) ist schon ein bisschen "Sicherheit" gewährleistet. Natürlich ist klar, dass nur der Channel **stable** verwendet werden sollte.
Dazu kann ich folgende /etc/apt/sources.list empfehlen:
deb http://deb.debian.org/debian/ stable main contrib non-free
deb-src http://deb.debian.org/debian/ stable main contrib non-free
deb http://deb.debian.org/debian/ stable-updates main contrib non-free
deb-src http://deb.debian.org/debian/ stable-updates main contrib non-free
deb http://deb.debian.org/debian-security stable/updates main
deb-src http://deb.debian.org/debian-security stable/updates main
deb http://ftp.debian.org/debian stretch-backports main
deb-src http://ftp.debian.org/debian stretch-backports main
Wichtig ist das System immer auf den aktuellen Stand zu halten um bekannte Sicherheitslücken und Fehler in Software schnellst möglich zu schließen. Ich bin kein Freund von automatischen Updates, da ich selber gerne weiß was mein System macht.
Für die unter euch die gerne einen solchen Dienst nutzen wollen, empfehle euch euch das Debian Wiki.
Eine weitere Möglichkeit, die benutze ich persönlich auch, ist es sich über neue Paket per Mail informieren zu lassen. Dazu benötigt man das Paket apticron. Im Thomas Krenn Wiki ist sehr gut beschrieben, wie diese konfiguriert wird, daher gehe ich nicht weiter darauf ein.
Für die Mail Benachrichtigungen nutze ich statt mail das Programm ssmtp. Einfach zu installieren mit dem Befehl
apt install ssmtp
Die Konfiguration der Datei /etc/ssmtp/ssmtp.conf sollte dann so aussehen
#Alias für root
root=root@example.de
#Server Setup
mailhub=mail.example.de:587
AuthUser=test@example.de #mailadresse
AuthPass=Password
UseSTARTTLS=YES
TLS_CA_File=/etc/ssl/certs/ca-certificates.crt
hostname=example.de #hostname
Mit dem Befehl ssmtp -vt < mail.eml ist es möglich die Konfiguration zu testem. Die Datei mail.eml hat folgenden Inhalt
From: MyPBX < root@example.de >
To: harry < root@example.de >
Subject: test
MIME-Version: 1.0
Lynis ist ein Secuirty Tool, was den Server mit einem "Health Scan" überprüft und dann auf Fehlerhafte oder gar nicht vorhanden Konfiguration hinweist. Das Tool ist leider bei Debian veraltet darum bietet sich an die eigne Repository hinzuzufügen. Dafür muss als erstes aber ein Paket installiert werden:
apt install apt-transport-https
Dann wird der PGP Schlüssel installiert
wget -O - https://packages.cisofy.com/keys/cisofy-software-public.key | apt-key add -
Jetzt die Liste hinzufügen
echo "deb https://packages.cisofy.com/community/lynis/deb/ stable main" | tee /etc/apt/sources.list.d/cisofy-lynis.list
Jetzt updaten und installieren
apt update && apt install lynis
Mit dem Befehl lynis update info kann man den aktuellen Stand der Software prüfen
root@vps73846:~# lynis update info
== Lynis ==
Version : 2.6.4
Status : Up-to-date
Release date : 2018-05-02
Update location : https://cisofy.com/lynis/
2007-2018, CISOfy - https://cisofy.com/lynis/
Als nächstes überprüfen wir das System lynis audit system auch Dockerfiles können geprüft werden mit lynis audit dockerfile
Die Ausgabe sieht dann wie folgt aus
....
================================================================================
Lynis security scan details:
Hardening index : 77 [############### ]
Tests performed : 218
Plugins enabled : 0
Components:
- Firewall [V]
- Malware scanner [V]
Lynis Modules:
- Compliance Status [?]
- Security Audit [V]
- Vulnerability Scan [V]
Files:
- Test and debug information : /var/log/lynis.log
- Report data : /var/log/lynis-report.dat
================================================================================
....
An dem Hardening Index ist zu erkennen, dass noch einiges zutun ist. In den folgenden Artikel werde ich auf die Konfigurationen eingehen, so dass dieser Score noch deutlich steigen wird.
Dieser Artikel ist auf Wunsch von intux entstanden.
Im folgenden Artikel möchte ich darauf eingehen, wie man Prosody mit Let's Encrypt nutzen kann, ohne Zertifikate zu kopieren, Script zu schreiben oder die Rechte auf die Zertifikate zu ändern, damit Prosody sie lesen und nutzen kann.
Im Artikel gehe ich davon aus, dass ihr Prosody bereits installiert und eingerichtet habt. Zusätzlich gehe ich davon aus, dass ihr mit LE bereits für die entsprechende Domain Zertifikate angefordert habe und zwar für:
Das lässt sich sehr schön mit der DNS Überprüfung von LE lösen.
Die Zertifikate sollten in dem Ordner
/etc/letsencrypt/live/example.org/
liegen und ihr nutzt den certbot für die Erstellung eurer Zertifikate.
Ich werde nur ganz kurz anschneiden, wie eine "sichere" SSL Konfiguration für die Verwendung mit Prosody aussehen sollte:
c2s_require_encryption = true;
s2s_require_encryption = true;
s2s_secure_auth = true;
ssl = {
protocol = "tlsv1_2";
ciphers = "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128";
options = { "no_sslv2", "no_sslv3", "no_ticket", "no_compression", "cipher_server_preference", "single_dh_use", "single_ecdh_use" };
dhparam = "/etc/prosody/dhparam.pem";
}
Bitte keine Angaben in die Datei wo das Zertifikate liegt, wenn ihr diese bereits habt, könnt ihr diese löschen.
Die Datei /etc/prosody/dhparam.pem wird mit dem folgenden Befehl erstellt:
openssl dhparam -dsaparam -out /etc/prosody/dhparam.pem 4096
Achtung: Das dauert sehr lange, ich empfehle es mit screen zu machen.
So jetzt kommen wir zum eigentlichen Teil, wichtig hier, dass ihr min. Version 0.10 habt:
root@vps73846:/etc/prosody# apt-cache policy prosody
prosody:
Installed: 0.10.1-1~stretch1
Candidate: 0.10.1-1~stretch1
Version table:
*** 0.10.1-1~stretch1 500
Um die aktuelle Version unter Debian Stable (Stretch) zu bekommen, solltet ihr die Prosody Repo nutzen.
So jetzt führen wir einfach den folgenden Befehl aus:
prosodyctl --root cert import /etc/letsencrypt/live
Wichtig, nur auf den live Ordner, nicht im example.org Ordner.
Prosody erkennt automatisch die richtigen Zertifikate und konfiguriert sich dementsprechend. Das war es eigentlich auch schon. Aber nur fast.
Das Problem, die Zertifikate müssen nach jedem neu erstellen wieder eingelesen werden. Dazu nutzen wir die Möglichkeit der globalen Konfigurationsdatei von Let's Encrypt, /etc/letsencrypt/cli.ini
Der Inhalt sollte so aussehen, ja ihr müsste die Datei erst anlegen
# Global config for letsencrypt runs
#
# Note that these options apply automatically to all use of Certbot for
# obtaining or renewing certificates, so options specific to a single
# certificate on a system with several certificates should not be placed
# here.
renew-hook = prosodyctl --root cert import /etc/letsencrypt/live
post-hook = prosodyctl --root cert import /etc/letsencrypt/live
So das wars. Jetzt haben wir Prosody mit den aktuellen LE Zertifikaten ausgerüstet und auch dafür gesorgt, das es immer die aktuellen Zertifikate bekommt.
Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.
Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.
Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.
Was macht SLEMP?
Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.
– Installation von NGINX und MariaDB aus Entwickler-Repository
– PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf Remi’s RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
– Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let’s Encrypt-Zertifikat
– Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet
Als nächstes plane ich nun das Script um eine Installations-Option für WordPress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen – dann würde das Script aber einen neuen Namen benötigen. ?
Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! ?
Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.
Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.
Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.
Was macht SLEMP?
Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.
- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet
Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)
Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)
Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.
Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.
Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.
Was macht SLEMP?
Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.
- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet
Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)
Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)
Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.
Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.
Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.
Was macht SLEMP?
Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.
– Installation von NGINX und MariaDB aus Entwickler-Repository
– PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf Remi’s RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
– Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let’s Encrypt-Zertifikat
– Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet
Als nächstes plane ich nun das Script um eine Installations-Option für WordPress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen – dann würde das Script aber einen neuen Namen benötigen. ?
Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! ?
Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.
Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.
Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.
Was macht SLEMP?
Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.
- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet
Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)
Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)
Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.
Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.
Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.
Was macht SLEMP?
Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.
- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet
Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)
Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)
Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.
Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.
Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.
Was macht SLEMP?
Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.
- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet
Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)
Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)
Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.
Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.
Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.
Was macht SLEMP?
Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.
- Installation von NGINX und MariaDB aus Entwickler-Repository
- PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf Remi's RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
- Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let's Encrypt-Zertifikat
- Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet
Als nächstes plane ich nun das Script um eine Installations-Option für Wordpress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen - dann würde das Script aber einen neuen Namen benötigen. :-)
Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! :-)
Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.
Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.
Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.
Was macht SLEMP?
Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.
– Installation von NGINX und MariaDB aus Entwickler-Repository
– PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf Remi’s RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
– Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let’s Encrypt-Zertifikat
– Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet
Als nächstes plane ich nun das Script um eine Installations-Option für WordPress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen – dann würde das Script aber einen neuen Namen benötigen. ?
Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! ?
Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.
Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.
Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.
Was macht SLEMP?
Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.
– Installation von NGINX und MariaDB aus Entwickler-Repository
– PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf Remi’s RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
– Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let’s Encrypt-Zertifikat
– Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet
Als nächstes plane ich nun das Script um eine Installations-Option für WordPress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen – dann würde das Script aber einen neuen Namen benötigen. ?
Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke! ?
Ich bin kein großer Fan von Klickibunti-Oberflächen wie Plesk, ISPconfig, froxlor und Co.
In meinen Augen erhöhen Lösungen wie die genannten nicht nur die Angriffsfläche eines Systems, sie bringen meist auch Dinge mit, die ich gar nicht benötige. Ich persönlich bevorzuge ein möglichst einfaches, aber dennoch sicheres Setup für Webserver.
Wer ein wenig in diesem Blog herumgestöbert hat oder schon länger mitliest, weiß dass ich vor einiger Zeit für genau diesen Fall mal ein kleines Bash-Script auf Github veröffentlicht habe, welches auf den Namen SLEMP hört.
Genau dieses habe ich nun mal wieder angefasst, umgeschrieben und um Unterstützung für Subdomains erweitert.
Was macht SLEMP?
Unterstützt werden nach wie vor minimale Installationen von CentOS 7.x und Debian 9.
– Installation von NGINX und MariaDB aus Entwickler-Repository
– PHP 7.0, 7.1 und 7.2 können einzeln, auf Wunsch aber auch parallel installiert werden. Für CentOS greife ich dabei auf Remi’s RPM repository zurück, unter Debian nutze ich das Repository von deb.sury.org.
– Absicherung und 301-Weiterleitung von HTTP auf HTTPS mittels Let’s Encrypt-Zertifikat
– Auf Wunsch wird eine MariaDB (Installation aus Entwickler-Repository) mit Benutzer und zufälligen Passwort eingerichtet
Als nächstes plane ich nun das Script um eine Installations-Option für WordPress und Nextcloud zu erweitern, jeweils mit optimierten NGINX-Konfigurationen für das jeweilige System. Im weiteren Verlauf möchte ich als Installations-Option noch Apache ergänzen – dann würde das Script aber einen neuen Namen benötigen. 
Wer sich an dem Script beteiligen möchte, darf das gerne auf Github tun, es ist nicht perfekt, tut aber, was es soll. Wer Fehler findet, kann diese ebenfalls gerne auf Github melden. Danke!
Der Beitrag SLEMP 0.5 – Sicherer LEMP-Server erschien zuerst auf timscha.io.
Das folgende PhantomJS-Skript listlinks.js, listet alle Hyperlinks einer Website auf, wobei JavaScript und Frames unterstützt werden.
Damit ist es z.B. möglich…
Hinweis: Mittlerweile auch als Projekt auf Github zu finden: https://github.com/1nn3/listlinks
#!/usr/bin/phantomjs
// listlinks.js
// Lists all hyperlinks of an URL, supports JavaScript and Frames
// See also: http://phantomjs.org/api/
"use strict";
// Um Endlosrekursion in der Frametiefe zu erkennen und abzufangen
// FIXME: Make it a constant
// const FRAME_RECURSION_MAX_DEPTH = 10;
// SyntaxError: Unexpected token 'const'
// See: https://github.com/ariya/phantomjs/issues/14521
var FRAME_RECURSION_MAX_DEPTH = 10;
function getAttributesFromAllElementsByTagName(tagName, attributeList) {
var elements = window.document.getElementsByTagName(tagName);
var values = [];
for (var i = 0; i < elements.length; i++) {
values.push({});
for (var j = 0; j < attributeList.length; j++) {
values[i][attributeList[j]] = elements[i].getAttribute(attributeList[j]) || "";
}
values[i]["textContent"] = elements[i].textContent || "";
}
return values;
}
function listLinks () {
var a = page.evaluate(getAttributesFromAllElementsByTagName, "a", ["href"]);
for (var i = 0; i < a.length; i++) {
// FIXME: Use the class URL to get an absolut URL
// See: https://github.com/ariya/phantomjs/issues/14349
var href = new URL(a[i]["href"], page.url).href || a[i]["href"];
var textContent = a[i]["textContent"].replace(/\s+/g, " ");
system.stdout.writeLine(href + "\t" + textContent);
}
}
function getFrames (parrents) {
var a = page.evaluate(getAttributesFromAllElementsByTagName, "iframe", []);
var frames = [];
for (var i = 0; i < a.length; i++) {
frames.push(parrents.concat([i])); // frame position
}
return frames;
}
function walkThroughFrames (frames) {
for (var i = 0; i < frames.length; i++) {
system.stderr.writeLine("I: Switching to frame: " + frames[i].toString() + " frameName=" + page.frameName + " frameURL=" + page.frameUrl);
if (frames[i].length > FRAME_RECURSION_MAX_DEPTH) {
system.stderr.writeLine("W: FRAME_RECURSION_MAX_DEPTH reached!");
continue;
}
page.switchToMainFrame();
for (var j = 0; j < frames[i].length; j++) {
page.switchToFrame(frames[i][j]);
}
listLinks();
walkThroughFrames(getFrames(frames[i])); // subframes
}
}
var system = require('system');
if (system.args.length != 2) {
system.stderr.writeLine("Usage: " + system.args[0] + " <url>");
phantom.exit(1);
}
var page = require("webpage").create();
page.settings.javascriptEnabled = true
page.settings.userAgent = system.env["LISTLINKS_USER_AGENT"] || "";
page.open(system.args[1], function (status) {
if (status !== "success") {
system.stderr.writeLine("E: Fail to load URL: " + system.args[1]);
phantom.exit(1);
}
listLinks();
walkThroughFrames(getFrames([]));
phantom.exit(0);
});
Download: fp-content/attachs/listlinks.js
Zur Installation laden das Skript nach /usr/local/bin/ herunter und machen es ausführbar. Dies ist für die Beispiele unten notwendig!
# wget -O /usr/local/bin/listlinks https://0010100.net/blog/fp-content/attachs/listlinks.js # chmod +x /usr/local/bin/listlinks
Benutzt wird es dann so:
$ listlinks <URL>
Mit dem Shell-Skript free-games-on-steam.sh, kann man sich über Gratisaktionen von Steam informieren lassen (Free Weekend/Free For a Limited Time). Dazu erstellt man einen Cronjob: @hourly free-games-on-steam 2>/dev/null
So bekommt man alle neuen Gratisaktionen via Mail mitgeteilt.
#!/bin/sh
set -e
seen="${XDG_CACHE_HOME:-$HOME/.cache}/free-games-on-steam.seen"
listlinks="$(which listlinks)"
url="https://store.steampowered.com/news/?headlines=1"
mkdir -p "$(dirname "$seen")"
touch "$seen"
xvfb-run --auto-servernum "$listlinks" "$url" | cut -f 2 | grep -i -w "free" | while read REPLY; do
if grep -q --line-regexp "$REPLY" "$seen"; then
continue
fi
echo "$REPLY" | tee --append "$seen"
done
cut-cache "$seen"
Download: fp-content/attachs/free-games-on-steam.sh
Mit dem Shell-Skript gadclick.sh, können Werbebanner von Google Ads/Ad Scence automatisiert anklicken werden. Das funktioniert allerdings nicht immer/mit allen Websites (Ich tippe mal auf ein Timing-Problem o.ä.).
#!/bin/sh
set -e
temp="$(/bin/mktemp --tmpdir=/dev/shm/)"
trap "rm -f -- '$temp'" 0 1 2 3 15 # Lösche Datei beim Beenden, Abbruch ...
listlinks="$(which listlinks)"
log="${XDG_CACHE_HOME:-$HOME/.cache}/gadclick.log"
sites="${XDG_CONFIG_HOME:-$HOME/.config}/gadclick.sites"
mkdir -p "$(dirname "$log")"
touch "$log"
get_gad() {
local website="${1:-http://www.example.net}"
xvfb-run --auto-servernum "$listlinks" "$website" | cut -f 1 >"$temp" \
&& cat <<! | grep -E -f - "$temp" | shuf -n 1
^https?://adclick\.g\.doubleclick\.net/
^https?://googleads\.g\.doubleclick\.net/
^https?://www\.googleadservices\.com/
!
}
shuf "$sites" | while read REPLY; do
if ! wget -qO "/dev/null" "$(get_gad "$REPLY")"; then
date +"%D %T 0 $REPLY" >>"$log"
continue
else
date +"%D %T 1 $REPLY" >>"$log"
fi
done
cut-cache "$log"
Download: fp-content/attachs/gadclick.sh
#!/bin/sh
# Cache kürzen
# cut-cache <path/to/cachefile> [keep [threshold]]
set -e
cachefile="$1"
keep="${2:-100}"
threshold="${3:-500}"
if test "$( cat "$cachefile" | wc -l )" -gt "$threshold"; then
temp="$(mktemp)"
tail -n "$keep" "$cachefile" >"$temp"
mv "$temp" "$cachefile"
fi
Download: fp-content/attachs/cut-cache.sh
Wie die anderen Skripte auch, kann cut-cache.sh nach /usr/local/bin/ installiert und ausführbar gemacht werden:
$ wget -O /usr/local/bin/listlinks https://0010100.net/blog/fp-content/attachs/listlinks.js
$ wget -O /usr/local/bin/free-games-on-steam https://0010100.net/blog/fp-content/attachs/free-games-on-steam.sh
$ wget -O /usr/local/bin/gadclick https://0010100.net/blog/fp-content/attachs/gadclick.sh
$ wget -O /usr/local/bin/cut-cache https://0010100.net/blog/fp-content/attachs/cut-cache.sh
$ chmod +x /usr/local/bin/{listlinks,free-games-on-steam,gadclick,cut-cache}
Die Skripte nutzen z.Z. Chromium, aber Firefox sollte auch funktionieren (entsprechenden Code aktivieren).
PhantomJS funktioniert z.Z. nicht (könnte aber einzurichten sein):
Message: Error - Unable to load Atom ‘find_elements’ from file ‘:/ghostdriver/./third_party/webdriver-atoms/find_elements.js’
Ich bin ein ziemlicher Fan von Markdown. Alle Dokumente, ob privat oder geschäftlich, verfasse ich in Markdown und speichere sie dann im PDF Format, bzw. gebe sie so auch weiter.
Eine zeitlang, habe ich meine Dokumente mit VIM geschrieben oder einigenen anderen Markdown Editoren, doch war ich nie zu 100% zufrieden mit der Lösung, jedoch hat sich das heute morgen geändert. Durch Zufall bin ich auf Typora gestoßen.
Es gibt Installationspakete für Windows, Mac OSX (Beta) und für Linux. Für Debian/Ubuntu müsst ihr folgendes machen:
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys BA300B7755AFCFAE
sudo add-apt-repository 'deb https://typora.io/linux ./'
sudo apt-get update
sudo apt-get install typoraFür Archlinux gibt es ein AUR Package
pacaur -S typoraEin RPM Package gibt es nicht, allerdings hat sich jemand die Mühe gemacht ein Script zu erstellen, das immer aus der aktuellsten Version ein RPM Paket baut:
Dazu müssen wir folgendes tun:
git clone https://github.com/RPM-Outpost/typora
cd typora
./create-package.sh x64
Das Script lädt die aktuellste Version herunter und baut dann das Paket. Zum Schluß biete es die Installation an. Danach liegt Typora im /opt Ordner. Eine .desktop Datei wird angelegt und sollte damit im Gnome/KDE auftauchen.
Dieses Programm beschleundigt mein Schreiben noch deutlicher, nicht nur das ich durch Hotkeys zum Beispiel Tabellen hinzufügen kann, nein auch raffinierte Programmierung erledigt viel Arbeit. So wird zum Beispiel ein markierter Text nach der der Tastenkombination Strg + K direkt zu einem Link, wenn bereits ein Link in der Zwischenalage ist, wird dieser automatisch eingefügt.
Ich bin einfach total begeistert. Alleine diesen Blogartikel habe ich in unter 5 Minuten geschrieben.
Ich bin ein ziemlicher Fan von Markdown. Alle Dokumente, ob privat oder geschäftlich, verfasse ich in Markdown und speichere sie dann im PDF Format, bzw. gebe sie so auch weiter.
Eine zeitlang, habe ich meine Dokumente mit VIM geschrieben oder einigenen anderen Markdown Editoren, doch war ich nie zu 100% zufrieden mit der Lösung, jedoch hat sich das heute morgen geändert. Durch Zufall bin ich auf Typora gestoßen.
Es gibt Installationspakete für Windows, Mac OSX (Beta) und für Linux. Für Debian/Ubuntu müsst ihr folgendes machen:
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys BA300B7755AFCFAE
sudo add-apt-repository 'deb https://typora.io/linux ./'
sudo apt-get update
sudo apt-get install typora
Für Archlinux gibt es ein AUR Package
pacaur -S typora
Ein RPM Package gibt es nicht, allerdings hat sich jemand die Mühe gemacht ein Script zu erstellen, das immer aus der aktuellsten Version ein RPM Paket baut:
Dazu müssen wir folgendes tun:
git clone https://github.com/RPM-Outpost/typora
cd typora
./create-package.sh x64
Das Script lädt die aktuellste Version herunter und baut dann das Paket. Zum Schluß biete es die Installation an. Danach liegt Typora im /opt Ordner. Eine .desktop Datei wird angelegt und sollte damit im Gnome/KDE auftauchen.
Dieses Programm beschleundigt mein Schreiben noch deutlicher, nicht nur das ich durch Hotkeys zum Beispiel Tabellen hinzufügen kann, nein auch raffinierte Programmierung erledigt viel Arbeit. So wird zum Beispiel ein markierter Text nach der der Tastenkombination Strg + K direkt zu einem Link, wenn bereits ein Link in der Zwischenalage ist, wird dieser automatisch eingefügt.
Ich bin einfach total begeistert. Alleine diesen Blogartikel habe ich in unter 5 Minuten geschrieben.
Nach aktueller Planung wird Firefox 62 einen deutlich erweiterten Tracking-Schutz besitzen. Erste Erweiterungen zeigen sich bereits in der Nightly-Version von Firefox 62.
Wer eine aktuelle Nightly-Version von Firefox 62 nutzt, dem ist unter Umständen bereits aufgefallen, dass Mozilla einen Schalter zur Aktivierung respektive Deaktivierung des Tracking-Schutzes prominent im Hauptmenü von Firefox integriert hat.
Der Tracking-Schutz ist in privaten Fenstern standardmäßig aktiviert und kann vom Nutzer auch für reguläre Fenster aktiviert werden. Der neue Schalter im Hauptmenü erfüllt den gleichen Zweck wie die entsprechende Option in den Firefox-Einstellungen für den gerade aktiven Fenstermodus (regulär vs. privat), ist für den Anwender aber schneller erreichbar. Außerdem gelangt man hierüber schnell zu den Anti-Tracking-Einstellungen von Firefox.
Eine weitere Neuerung in der Nightly-Version von Firefox 62 zeigt sich bei Klick auf das Info-Symbol in der Adressleiste. Unter den speziellen Berechtigungen für die Domain des aktiven Tabs gibt es hier nun eine Schaltfläche, um alle Cookies und Seitendaten zu löschen, welche in Zusammenhang mit der Domain inklusive aller Subdomains des aktiven Tabs stehen.
Beide Neuerungen sind Teil eines für Firefox 62 geplantes Projektes, den Tracking-Schutz des Mozilla-Browsers zu verbessern. So soll bei Klick auf das Info-Symbol in der Adressleiste bei den Berechtigungen auch noch ein Link integriert werden, um direkt zu den Berechtigungs-Einstellungen zu gelangen, bei deaktiertem Tracking-Schutz soll es hier Informationen geben, was für Tracking-Scripts auf der Seite entdeckt worden sind.
Aber auch die Einstellungen des Tracking-Schutzes sollen überarbeitet werden. Konkret ist hier eine Unterteilung möglicher Tracking-Scripts in die folgenden Kategorien geplant: Werbung, Analyse, Fingerprinting, Crypto Mining sowie Sozial. Für jede einzelne dieser Kategorien soll der Nutzer separat einstellen können, ob diese Art von Tracker nur in privaten Fenstern, immer oder nie blockiert werden soll.
Der Beitrag Mozilla plant aufgebohrten Tracking-Schutz für Firefox 62 erschien zuerst auf soeren-hentzschel.at.
Bereits vor einiger Zeit hat Parrot Security mit der Version 4.0 einen neuen Meilenstein erreicht.
Die italienische Sicherheitsdistribution bringt mit einer experimentellen Netzinstallation und einer Docker Unterstützung zwei neue Installationsmethoden mit. Beide Methoden werden die Verwendung um einiges vereinfachen und die eigene Bedürfnisse besser bedienen. Dockerfiles lassen sich leicht anpassen und eine Core Installation bietet zusätzliche Installationsoptionen an.
Desweitern wurde ein aktueller Kernel 4.16 eingebunden und die Oberfläche auf MATE 1.20 aktualisiert.
Im Hintergrund werkelt nun eine firejail Sandbox, sowie NGINX anstatt Apache.
Insgesamt wurden über 1500 Pakete aktualisiert.
Das System ist schnell aktualisiert.
sudo apt update
sudo apt purge tomoyo-tools
sudo apt full-upgrade
sudo apt autoremove
Die bekannteste Distribution für Sicherheitsexperten und Penetration Tester hat ebenfalls nachgelegt und mit der neuen Version den Kernel 4.15 implementiert, um den Spectre und Meltdown Lücken den Garaus zu machen. Hier werden in Zukunft, wohl noch einige Fixes folgen müssen.
Die Unterstützung für AMD GPUS wurde verbessert, sowie AMD Secure Encrypted Virtualization integriert, was euch erlaubt den Hauptspeicher zu verschlüsseln.
Anwender des Metasploit Frameworks erhalten mit dem neuen Release einfacheren Zugang zu Scripten. Diese sind normalerweise unter "/usr/share/metasploit-framework/tools/exploit/" zu finden, sind nun aber Dank PATH direkt mit "msf-scriptname" aufrufbar.
Andere Tools wie BurpSuite, hashcat oder JoomScan wurden ebenfalls aktualisiert. Der komplette Changelog verrät alle Details.
| Name | Version | Tools | Besonderes | Basis | GUI |
|---|---|---|---|---|---|
| Autopsy | 4.0 | ??? | The Sleuth Kit | Windows | |
| BackBox | 5 | 70+ | eigenes Repo | Ubuntu | Xfce |
| BlackArch | 2017.11.24 | 1750+ | ArchLinux | ArchLinux | Gnome |
| CAINE | 9 | 100+ | WinUFO | Ubuntu | Mate |
| DracOS | 3.0 | 100+ | CLI | LFS | DWM |
| DEFT | 2017.1 | 250+ | Dart2 | Lubuntu 14.04 | Lxde |
| Kali Linux | 2018.2 | 300+ | ARM fähig | Debian Testing | Multi |
| LionSec | 5.0 | ??? | Ubuntu | ||
| NST | 26 | ??? | Server integriert | Fedora | |
| NetSecLOS | 6.0 | 50+ | OpenSuse | Lxde | |
| Parrot Sec | 4.0 | 700+ | Cloud fähig | Debian Buster | MATE |
| Pentoo | 2015.0 RC5 | ??? | 64bit | Gentoo | Xfce |
| Sans SIFT | 3.0 | 20+ | Ubuntu |
Dank Synchronisationsmöglichkeit können Firefox-Nutzer ihre Chronik, Lesezeichen und mehr auf verschiedenen Geräten gleichzeitig nutzen. Wer sich auf einem Gerät von Firefox Sync wieder abmeldet, wird ab Firefox 62 gefragt, ob die lokalen Daten gelöscht werden sollen.
Nach Angaben von Mozilla haben einige Firefox-Nutzer die Erwartung, dass eine Abmeldung von Firefox Sync gleichbedeutend damit ist, dass Daten wie Chronik und Lesezeichen anschließend auch aus Firefox gelöscht werden. Um diesen Nutzern gerecht zu werden, fragt Firefox ab Version 62 nach der Abmeldung von Firefox Sync nach, ob die Daten gelöscht werden sollen und bietet dabei zwei Optionen, die entweder einzeln oder zusammen ausgewählt werden können: ein Löschen synchronisierter Daten wie Chronik und Lesezeichen oder aber auch ein Löschen anderer privater Daten, die nicht synchronisiert werden, wie Cookies und Cache.
Von den Sync-Servern werden die Daten dabei nicht gelöscht, wie auch in dem neuen Abmelde-Dialog klar kommuniziert wird. Wer das tun will, kann dies über accounts.firefox.com machen. Von dort aus können übrigens sämtliche Geräte von Firefox Sync getrennt werden, die derzeit verbunden sind, ohne dass man das entsprechende Gerät dafür bei sich haben muss.
Tipp: für mehr Sicherheit lässt sich hierüber jetzt auch eine Zwei-Schritt-Authentifizierung für Firefox Sync aktivieren.
Der Beitrag Firefox 62: Firefox bietet nach Abmeldung von Firefox Sync Löschen der Daten an erschien zuerst auf soeren-hentzschel.at.
Der eine oder andere wird es schon mitbekommen haben, dass ich in Punkto Messenger große Hoffungen in der Protokoll Matrix lege. Der offizielle Client Riot war bisher aber immer ein großer Kritikpunkt bei vielen Nutzern.
Anfang 2018 haben die Entwickler von Matrix / Riot 5 Millionen von Status erhalten. Diese Summe sollte unter anderem in die Verbesserung des Referenz-Client Riot investiert werden. Heute wurden nun die ersten Screenshots des neuen Clients veröffentlicht
Wer nichts mit dem offiziellen Client anfangen kann, kann ich zum Beispiel die alternativen Clients Quaternion, nheko oder fractal ansehen. Diese sind vom Funktionsumfang her aber meist noch eingeschränkt, so dass bei nheko beispielsweise die Verschlüsselung noch nicht implementiert ist.