home » search tags
Die Suche tag = security ergab 7 Treffer:

Juli
23
janitor » #useless #SSL #security
Wie bereits geschrieben läuft uselessmouse mit SSL... bei dieser Gelegenheit habe ich noch weiter Einstellungen angepasst, dabei war das observatory by Mozilla eine riesige Hilfe.

Zu Beginn wurde die Seite mit einem "F" abgestraft, nach dem aktivieren von (u.a.) SRI, XFO, HSTS und CORS wurde es dann aber doch ein grünes "A+":

Juni
16
janitor » #useless #SSL #security
Ich hatte ja bereits SSL für uselessmouse aktiviert, allerdings war CAcert nicht als trusted in den meisten - bzw. allen - Browser eingetragen, was immer wieder zu Problemen geführt hat.
Aus diesem Grund habe ich mich entschlossen alle Seiten auf Let's Encrypt umzustellen. Im gleichen Zuge hab ich noch ein paar weitere features (CSP, HSTS, XFO,...) aktiviert
Januar
30
janitor » #useless #security #gpg
Hier und da muss man den public key eines anderen Benutzers importieren, da ich dieses nur ungerne blind erledige möchte ich den Inhalt des Keys vorher sehen.

Dafür kann man den folgenden Befehl nutzen (hier die info des debmon.org Projects)
gpg repo.key

die Ausgabe sollte wie folgt sein
pub  2048R/29D662D2 2012-10-03
uid debmon.org (debmon.org repository signing key) <contact@debmon.org>
sub 2048R/575BA6B9 2012-10-03</contact@debmon.org>



Möchte man hingegen den kompletten fingerprint sehen muss die Option --with-fingerprint genutzt werden.
November
22
Wer elasticsearch in einer Produktivumgebung einsetzt der hat sicherlich mehr als einmal die fehlenden Sicherheitsmechanismen vermisst.

Wenn man elasticsearch.org glauben darf, wurde das flehen der Kunden/Community erhöht, denn mit shield soll sich einiges in dieser Richtung ändern (und hoffentlich auch verbessern).

Folgende Erweiterungen sollen u.a. in shield enthalten sein:
  • RBAC (roll based access controls)
  • Authentication (Login mit Benutzer + Passwort)
  • Encrypted Communications (verschlüsselte Kommunikation)

Leider gibt es aktuell keine Testversion, aber eins steht fest... sobald diese verfügbar ist wird ein ausführlicher Test auf uselessmouse.de erscheinen.
Oktober
25
Da stolpert man im Netzwerk eines Bekannten über ein altes WD MyBook Live auf dem (lt. WD Webseite) die aktuellste Firmware
MyBookLive 02.43.03-022 : Core F/W

installiert ist... nur um festzustellen das es anfällig für Shellshock ist:
MyBookLive:~# env x='() { :;}; echo verwundbar' bash -c ""
verwundbar
MyBookLive:~#

Wenn man nun noch bedenkt das es sich um ein Debian 5 handelt
MyBookLive:~# cat /etc/debian_version 
5.0.4
MyBookLive:~#

für das kein Support mehr besteht...

Da das System unmöglich in diesem Zustand bleiben konnte hab ich mich daran gemacht und die Bash manuell aktualisiert.

Folgende Schritte waren nötig:

benötigte Pakete installieren
apt-get update && apt-get install build-essential gettext bison


Download der sourcen
wget http://ftp.gnu.org/gnu/bash/bash-3.2.tar.gz
tar zxvf bash-3.2.tar.gz
cd bash-3.2


Download und anwenden aller Patches
for i in $(seq -f "%03g" 1 57); do
wget -nv http://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-$i
patch -p0 < bash32-$i
done


Übersetzen und installieren
./configure && make
make install

Juni
22
Nehmen wir mal an, man betreibt einen Server bei einem deutschen Hoster (dessen Namen ich vorerst nicht nennen möchte) und stellt bei einem zufälligen tail fest das dieser Server von einem anderen System penetriert wird und innerhalb von ca. 20 Minuten über 900 Logeinträge nach folgendem Muster auftauchen

Jun 22 11:44:29 localhost postfix/smtpd[13298]: connect from
static.aaa.bbb.ccc.ddd.---.de[aaa.bbb.ccc.ddd]
Jun 22 11:44:29 localhost postfix/smtpd[13298]: SSL_accept error from
static.aaa.bbb.ccc.ddd.---.de[aaa.bbb.ccc.ddd]: lost connection
Jun 22 11:44:29 localhost postfix/smtpd[13298]: lost connection after
CONNECT from static.aaa.bbb.ccc.ddd.---.de[aaa.bbb.ccc.ddd]
Jun 22 11:44:29 localhost postfix/smtpd[13298]: disconnect from
static.aaa.bbb.ccc.ddd.---.de[aaa.bbb.ccc.ddd]
Jun 22 11:44:29 localhost postfix/smtpd[13300]: connect from
static.aaa.bbb.ccc.ddd.---.de[aaa.bbb.ccc.ddd]
Jun 22 11:44:29 localhost postfix/smtpd[13300]: SSL_accept error from
static.aaa.bbb.ccc.ddd.---.de[aaa.bbb.ccc.ddd]: lost connection



Natürlich schaut man erstmal nach wohin denn die Adresse aaa.bbb.ccc.ddd gehört... und siehe da, diese gehört dem gleichen Provider!

Wer sich nun denkt perfekt dann kann ich das gleich bei dem einkippen und der wird dann schon dafür sorgen das solche Zugriffe beendet werden, der hat sich bei diesem Provider geschnitten!

Nach dem erstellen einen Supporttickets kam nur die lapidare Aussage, man solle sich an abuse@provider.tld wenden... diese Adresse sei aber nur unter der Woche von 08:00 - 16:00Uhr besetzt und mehr könne man nicht machen. ôO

Our office hours concerning abuse enquiries are Monday to Friday (except official holidays) from 08.00 to 16.00 hours (CET).


Ich bin einfach nur sprachlos, aber wie hier bereits geschrieben, schere die Provider sich meist einen **** um solche Anfragen/Hinweise. Das es aber der eigene Provider ist, der auf solche Anfrage nicht reagiert lässt einen die Zusammenarbeit grundlegend überdenken.
Januar
15
OK, das es sinnlos ist einem Hoster in China, Korea oder Russland wegen einem dictionary attack eine abuse-Nachricht zu schreiben sollte jedem bekannt bzw. bewusst sein.

Aber was ist mit Hoster die ihren Sitz in D haben?

Ganz ehrlich? Wäre es nicht so traurig, könnte man darüber lachen... egal ob (u.a.):

  • 1und1
  • Strato
  • Server4you


Von keinem bekommt man (nach nunmehr 4 Wochen) eine Nachricht das zumindest das Anliegen eingegangen ist geschweige denn das sich um das Anliegen gekümmert wird und das abwohl:

  • 1und1
  • Strato
  • Server4you


Klar ich bin kein Kunde bei denen, aber wer eine solche Ignoranz gegenüber illegalem Verhalten an den Tag legt wird mich auch niemals als Kunden haben.

Bleibt nur die Alternative:

logfiles sichten und iptables füttern