Schlagwort: Sicherheit

HomeAssistant nun am Internet

Das hat­te ich schon län­ger vor: Home­As­si­stant ans Inter­net zu hän­gen. Dann kann ich auch aus der Fer­ne die lie­be Fami­lie erschre­cken 🙂
Nor­ma­ler­wei­se wür­de man auf dem Rou­ter ein Port­for­war­ding ein­rich­ten und gut. Aber das wird dann ganz schnell eklig mit HTTPS und des­sen Zer­ti­fi­ka­ten. Außer­dem spricht mein Home­As­si­stant kein HTTPS, und ich woll­te mög­lichst wenig dar­an rum­kon­fi­gu­rie­ren. Letzt­lich muße ich dort (HA) gar nichts machen.

Mei­ne Lösung: HA läuft auf einem Raspi, auf dem auch ein Apa­che läuft. Der stellt einen rever­se Pro­xy mit HTTPS (selbst­si­gnier­te Zer­ti­fi­kat) zur ver­fü­gung, der dann mit plain HTTP auf HA wei­ter­ver­mit­telt. Bleibt aber das Pro­blem mit den Zer­ti­fi­ka­ten.
Aber ich habe ja noch einen Root-Ser­ver im Inter­net! Und der hat ein rich­ti­ges Wild­card-Zer­ti­fi­kat. Also habe ich auch dort einen rever­se Pro­xy instal­liert, der dann per HTTPS auf mei­nen Heim-IP geht, dort gibt es dann in der Tat ein Port­for­war­ding auf den HTTPS-Pro­xy auf dem Raspi.
Funk­tio­niert!
Der Apa­che auf dem Raspi:


  ServerName hass.sokoll.com
  ServerAdmin webmaster@sokoll.com
  ErrorLog ${APACHE_LOG_DIR}/hass.sokoll.com-error.log
  CustomLog ${APACHE_LOG_DIR}/hass.sokoll.com-access.log combined
  SSLEngine on
  SSLCertificateFile /etc/ssl/private/raspi.crt
  SSLCertificateKeyFile /etc/ssl/private/raspi.key
  ProxyPreserveHost On
  ProxyRequests off
  ProxyPass /api/websocket ws://localhost:8123/api/websocket
  ProxyPassReverse /api/websocket ws://localhost:8123/api/websocket
  ProxyPass / http://127.0.0.1:8123/
  ProxyPassReverse / http://127.0.0.1:8123/
  RewriteEngine on
  RewriteCond %{HTTP:Upgrade} =websocket [NC]
  RewriteRule /(.*)  ws://localhost:8123/$1 [P,L]
  RewriteCond %{HTTP:Upgrade} !=websocket [NC]
  RewriteRule /(.*)  http://localhost:8123/$1 [P,L]

Der auf dem Root-Ser­ver:


  Protocols h2 http/1.1
  ServerName hass.sokoll.com
  ServerAlias home.sokoll.com
  ServerAdmin webmaster@sokoll.com
  ErrorLog ${APACHE_LOG_DIR}/hass.sokoll.com-error.log
  CustomLog ${APACHE_LOG_DIR}/hass.sokoll.com-access.log combined
  SSLEngine on
  SSLCertificateFile  /etc/dehydrated/certs/wildcard_sokoll.com/fullchain.pem
  SSLCertificateKeyFile /etc/dehydrated/certs/wildcard_sokoll.com/privkey.pem
  ProxyRequests off
  ProxyPreserveHost On
  ProxyPass /api/websocket wss://91.66.58.188/api/websocket
  ProxyPassReverse /api/websocket wss://91.66.58.188/api/websocket
  ProxyPass / https://91.66.58.188/
  ProxyPassReverse / https://91.66.58.188/
  SSLProxyEngine on
  SSLProxyCheckPeerCN off
  SSLProxyCheckPeerExpire off
  SSLProxyCheckPeerName off


  ServerName hass.sokoll.com
  ServerAlias home.sokoll.com
  ServerAdmin webmaster@sokoll.com
  RedirectMatch permanent ^/(.*) https://hass.sokoll.com/$1

Die webso­cket-Geschich­ten habe ich mir aus dem Inter­net zusammengeklau(b)t, natür­lich. Bis­lang habe ich kei­ne Feh­ler bemerkt.

0

Roomba

Da steht er nun unschul­dig in der Ecke, der neue Haus­halts­hel­fer.

Mit Cloud!

Aber nicht lan­ge. Auf dem Rou­ter sieht das näm­lich momen­tan so aus:

        rule 40 {
            action reject
            description "Roomba bleibt zu Hause!"
            log disable
            source {
                mac-address d0:c5:d3:bd:c4:f1
            }
        }

Mac-Adres­se aus zwei Grün­den:

    • IPv6 mit pri­va­cy exten­si­ons (das Teil scheint aber kein v6 zu kön­nen)
    • DHCP (IP ist zwar fest­ge­tackert, aber wer weiß…)
    • IPX/SPX ja viel­leicht? 😉

Und ein tcpdump meint dazu:

18:47:16.280486 IP 192.168.1.254 > 192.168.1.93: ICMP 52.2.109.246 tcp port 8883 unreachable, length 52

Und was meint das IoT so zu 52.2.109.246:8883?
Das hier:

Ah — ja. Syman­tec.
Immer­hin hat der Staub­sauger sel­ber kei­ne Ports offen.

0

Homebrew

Nach Instal­la­ti­on von Home­brew sehen die Eigen­tü­mer­schaf­ten in /usr/local/ so aus:

~$ ls -la /usr/local/
total 0
drwxr-xr-x   16 root     wheel    512  8 Mai 10:00 .
drwxr-xr-x@   9 root     wheel    288 16 Jan 01:30 ..
-rw-r--r--    1 root     wheel      0  2 Mai 12:22 .com.apple.installer.keep
drwxrwxr-x    4 rsokoll  admin    128  7 Mai 13:55 Caskroom
drwxrwxr-x   67 rsokoll  admin   2144  6 Mai 17:01 Cellar
drwxrwxr-x    3 rsokoll  admin     96  3 Mai 17:19 Frameworks
drwxrwxr-x   20 rsokoll  admin    640  3 Mai 17:14 Homebrew
drwxr-xr-x    7 root     wheel    224 20 Sep  2018 MacGPG2
drwxrwxr-x  368 rsokoll  admin  11776  8 Mai 10:00 bin
drwxrwxr-x   10 rsokoll  admin    320  5 Mai 10:12 etc
drwxrwxr-x  100 rsokoll  admin   3200  6 Mai 07:52 include
drwxrwxr-x  257 rsokoll  admin   8224  6 Mai 07:54 lib
drwxrwxr-x   84 rsokoll  admin   2688  6 Mai 17:01 opt
drwxrwxr-x    9 rsokoll  admin    288  5 Mai 10:12 sbin
drwxrwxr-x   35 rsokoll  admin   1120  6 Mai 17:01 share
drwxrwxr-x    4 rsokoll  admin    128  3 Mai 17:18 var
~$

Gehts noch?
Wer an Sys­tem­ver­zeich­nis­sen rum­fum­melt, wird mit Deinstal­la­ti­on nicht unter 3 Jah­ren bestraft. Also doch wie­der Mac­Ports.

0

Das Tolle an Linux/postfix

ist ja, daß die Waf­fen gela­den und aus­ge­rich­tet sind.
Und root hat die Macht über den Abzugs­hahn.

Heu­te also Fol­ge 4711 #Sel­flart.

Da der Exchan­ge hin­ten sowie­so .exe und Co. nicht ent­ge­gen­nimmt, muß mein Post­fix vor­ne das ja auch nicht tun. So dann! Mut!

root@mx1:~# grep ^mime_header_checks /etc/postfix/main.cf
mime_header_checks = regexp:/etc/postfix/mime_header_checks
root@mx1:~# cat /etc/postfix/mime_header_checks
/name=[^>]*\.(bat|com|exe|dll|mht|vbs)/ REJECT
/name=[^>][0-9]+\.docx{,1}/ REJECT
root@mx1:~#

So soll es sein (Die zwei­te Zei­le bezieht sich auf die­se Hei­se-Mel­dung)
Doch was ist das?

root@mx1:~# grep E81BF5FFE3 /var/log/mail.info
May  7 11:04:53 mx1 postfix/smtpd[30608]: E81BF5FFE3: client=sonic328-45.consmr.mail.ne1.yahoo.com[66.163.191.20]
May  7 11:04:54 mx1 postfix/cleanup[30568]: E81BF5FFE3: message-id=<1557213647.728781@dmarc.yahoo.com>
May  7 11:04:54 mx1 postfix/cleanup[30568]: E81BF5FFE3: reject: header Content-Disposition: attachment; filename="aol.com!example.net!1557100800!1557187199.xml.gz" from sonic328-45.consmr.mail.ne1.yahoo.com[66.163.191.20]; from=<noreply@dmarc.yahoo.com> to=<dmarc-report@example.net> proto=ESMTP helo=: 5.7.1 message content rejected
root@mx1:~#

Hä? Wie­so das denn? Ist doch alles in Ord­nung?
Kopf­kratz. Nein, es ist nicht alles in Ord­nung. Im Namen des Attach­ments steht aol.com.

Die kor­rek­te Zei­le muß also lau­ten, *trom­mel­wir­bel*

/name=[^>]*\.(bat|com|exe|dll|mht|vbs)$/ REJECT

Und alles ist wie­der schön.

OT: Wür­de post­fix mit­tels jour­nald log­gen, hät­te ich den Feh­ler wohl nie gese­hen…

0

Herr, wirf Hirn vom Himmel!

Kübel­wei­se bit­te!

Es gibt also ein Pro­blem: Medi­zin­ge­rä­te sind übers Netz angreif­bar. Ach! Nun, was wür­de jemand emp­feh­len, der noch alle Tas­sen im Schrank hat? Rich­tig: Die Gerä­te vom Netz neh­men. Doch was wür­de jemand ohne Tas­sen oder Schrank emp­feh­len? Nun:

In Zukunft pla­nen wir eine Cloud-Anbin­dung spe­zi­ell für Medi­zin­ge­rä­te“, ergänzt Hei­den­reich. „So kön­nen wir die Kom­po­nen­ten bes­ser schüt­zen.“

Georg Hei­den­reich ist übri­gens bei Sie­mens Healt­hi­neers für IT-Stan­dards und Secu­ri­ty zustän­dig. Kei­ne Iro­nie, kein Pos­til­li­on

3+

API-Tokens

Von einem Teil die­ser Kon­ten sol­len unter ande­rem User­na­men und gehash­te Pass­wör­ter offen­ge­legt gewe­sen sein, außer­dem Git­Hub- und Bit­bu­cket-Tokens für Docker Auto­builds

Das ist wohl ein Pro­blem, das kaum jemand auf dem Schirm hat: Wir haben beim Spei­chern von Paß­wör­tern mitt­ler­wei­le ein ordent­li­ches Level an Sicher­heit erreicht: Shadow-sys­te­me, AES statt DES, Hash­es statt Klar­text, Salz, 2FA

Und dann kam Dev­Ops und gab uns REST-APIs, auf die man mit Tokens zugrei­fen kann. Ein Token ist dabei eine lan­ge, genü­gend zufäl­li­ge Zei­chen­ket­te. Solan­ge man Trans­port­ver­schlüs­se­lung ver­wen­det, ist zumin­dest die­ser Weg sicher, doch wer in der Pra­xis kann wirk­lich sagen, wo über­all ein Token für wen les­bar gespei­chert ist? Wel­che Rech­te die­ses Token hat? Ob es abläuft und wenn ja, wann?

Platt: Wenn in mei­ner DB mein Git­Hub-Paß­wort gesal­zen und gehasht abge­spei­chert ist: Gut. Aber wenn dane­ben ein Token für den Git­hub-Zugriff liegt, dann ist ja nichts gewon­nen.

0

Omnibus-Packages

Omni­bus ist ein Instal­ler für kom­ple­xe Soft­ware-Stacks wie Git­lab. Es bringt einen kom­plet­ten Stack mit, in Fal­le Git­lab post­gres, ruby, nginx… Das ist wun­der­bar, hat aber einen Nach­teil: Es gibt kei­ne Del­tas, auch bei kleins­ten Ände­run­gen muß der kom­plet­te Stack neu instal­liert wer­den.
Git­lab hat zwei Edi­tio­nen: Die kos­ten­pflich­ti­ge Enter­pri­se Edi­ti­on (EE) und die freie Com­mu­ni­ty Edi­ti­on (CE). gitlab.sokoll.com hat letz­te­re.
Heu­te gab es mal wie­de rein Update:

The Git­Lab EE ver­si­ons con­tain an important secu­ri­ty fix, and we stron­gly recom­mend that all Git­Lab EE instal­la­ti­ons be upgraded imme­dia­te­ly. Git­Lab CE is not affec­ted, but the ver­si­on num­bers were increa­sed to be con­sis­tent with EE ver­sio­ning.

Bei mei­ner Ver­si­on wur­de also bis auf die Ver­si­ons­num­mer gar nichts geän­dert. Aber die wur­de eben geän­dert, und das resul­tiert in:

The following packages will be upgraded:
  gitlab-ce grafana wpasupplicant
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 637 MB of archives.

Ca. 600MB für die Ände­rung einer Ver­si­ons­num­mer 🙂

0

DNS-over-HTTPS

Mozil­la pusht also DoH. War­um zum Gei­er? Das Pro­blem der Echt­heit von DNS-Ant­wor­ten löst DNSSEC bes­ser. Ver­trau­lich­keit? Wenn der “Part­ner” sämt­li­che Anfra­gen bekommt? Da wäre es doch sinn­vol­ler, den DNS-Ser­ver des ISP zu ver­wen­den. Zumal es dann bei SNI ohne­hin vor­bei ist mit der Ver­trau­lich­keit — der Host-Hea­der geht im Klar­text übers Netz.
Und die Archi­tek­tur ist natür­lich kaputt: Ers­tens gehört der (vali­die­ren­de) Resol­ver so dicht wie mög­lich an den Nut­zer, also auf dien loka­len Rech­ner. Und zwei­tens ist es ein­fach bescheu­ert, einen Resol­ver für einen Brow­ser zu haben, und getaddrinfo() für den Rest des Sys­tems.

Nie­der mit DoH!

0

Windows-Telemetrie, der gesunde Menschenverstand

Ich lese inter­es­siert einen Arti­kel zur Tele­me­trie in Win­dows 10 und kom­me aus dem Stau­nen nicht her­aus. Die Bun­des­be­hör­de BSI erforscht das Nach-Hau­se-Pet­zen von Win­dows 10. War­um? Wegen

der poli­tisch-stra­te­gi­schen Ent­schei­dung für Win­dows 10 als Betriebs­sys­tem für die Bun­des­ver­wal­tung

Mit ande­ren Wor­ten: Win­dows 10 ist alter­na­tiv­los, und hin­ter­her schau­en wir mal, wie wir uns unse­re Ent­schei­dung schön­for­schen kön­nen. Seit 2 Jah­ren wird da geforscht (ich habe eine ande­re Defi­ni­ti­on von „For­schung“, aber das nur neben­bei), und die For­scher

kön­nen mitt­ler­wei­le recht genau nach­voll­zie­hen, was dort pas­siert.

Wow! Doch schon! Nein, ich unter­stel­le den For­schern kei­ne Inkom­pe­tenz, ganz im Gegen­teil. Ich unter­stel­le aber Micro­soft, daß sie sehr gut dar­in sind zu ver­schlei­ern, was Win­dows 10 alles so tut  — und dafür sicher Grün­de haben.

In einer Stan­dard­in­stal­la­ti­on waren über 1.000 sol­cher Mess­punk­te aktiv — an denen wie­der­um ver­schie­de­ne Daten ermit­telt und an Micro­soft gesen­det wer­den.

In Wor­ten: über EINTAUSEND Sen­so­ren, die an Micro­soft repor­ten! Inklu­si­ve einer API für Key­log­ger.
Aber es kommt noch schlim­mer: Micro­soft kann zum Bei­spiel einen

Memo­ry-Dump einer Soft­ware

anfor­dern. Das heißt: Sie kön­nen jedes Doku­ment, was der Nut­zer gera­de offen hat, abzie­hen. Der feuch­te Traum aller Straf­ver­fol­gungs­be­hör­den, Geheim­diens­te und sons­ti­ger Kri­mi­nel­len.
Das inter­es­siert die For­scher, und so wol­len sie

eine Tele­me­trie, um die Tele­me­trie zu über­wa­chen

bau­en. Immer­hin haben sie Juve­nal gele­sen 😉 Quis cus­to­diet ipsos cus­to­des?
Dann kom­men ein paar Gedan­ken, wie man das Pet­zen wirk­sam unter­bin­den kön­ne, mit einer genia­li­schen Idee: Das Win­dows kom­plett vom Inter­net abklem­men. Gute Idee, nur gibts dann eben kei­nen Inter­net­zu­griff mehr, was heut­zu­ta­ge nun wirk­lich ein Nogo ist. Aus­weg?

Mit dem Bun­des­cli­ent, eine stan­dar­di­sier­te Platt­form, über die in Zukunft Ver­wal­tung und Behör­den ihre Com­pu­ter­ar­bei­ten ver­rich­ten sol­len, soll genau dies umge­setzt wer­den. Gesurft wird dann über einen vir­tua­li­sier­ten Brow­ser oder ein Ter­mi­nal.

Der Bun­des­cli­ent ist offen­sicht­lich ein umge­la­bel­ter RDP-Cli­ent, dann petzt eben der Win­dows Ser­ver 2016, auf den der Bun­des­cli­ent zugreift.🤦‍♂️

Und damit kom­me ich zu mei­nem eigent­li­chen Auf­re­ger: 5G und Hua­wei. Der Chi­na­mann! Darf man den in Deutsch­land Netz­in­fra­struk­tur bau­en las­sen? Wo der Chi­na­mann doch unse­re Indus­trie abhört?
Mal ernst­lich: Wie soll das gehen? Wir reden über 5G, also Mobil­funk. Dar­über wird eh nur trans­port­ver­schlüs­sel­tes Zeug trans­por­tiert. Eher ist die Gefahr, daß die Ame­ri­ka­ner in die TLS-Imple­men­tie­run­gen Soll­bruch­stel­len ein­ge­baut haben — womit wir wie­der bei Win­dows 10 sind.

Wenn man For­scher­kol­lek­ti­ve braucht, die nach mehr­jäh­ri­ger Tätig­keit immer­noch nicht wis­sen, was Win­dows 10 tut — dann ver­dammt setzt man kein Win­dows 10 ein!
Die­ses wasch mich, aber mach mich nicht naß — das ist pein­lich, gera­de fürs BSI. Win­dows in wel­cher Ver­si­on auch immer ist NICHT gott­ge­ge­ben!

PS: War da nicht mal was mit DSGVO?

 

0