Schlagwort: Sicherheit

HTTPS only

Ab sofort erzwingt die­ses Blog HTTPS:

<VirtualHost 195.110.60.28:80>
  ServerName rainer.sokoll.com
  RedirectMatch permanent ^/(.*) https://rainer.sokoll.com/$1
</VirtualHost>

Was dann resul­tiert in:

~$ curl -I http://rainer.sokoll.com/
HTTP/1.1 301 Moved Permanently
Date: Sat, 26 Sep 2015 07:06:11 GMT
Server: A web server, what did you expect?
Location: https://rainer.sokoll.com/
Content-Type: text/html; charset=iso-8859-1

~$
0

ssh und DNSSEC

Sehr fein. Da wir ja nun DNSSEC haben und dem auch ver­trau­en, kön­nen wir gemäß RFC 4255 den Fin­ger­print unse­res Hosts im DNS ver­öf­fent­li­chen:

Bildschirmfoto 2015-03-27 um 08.31.48

In ~/.ssh/config noch schnell ein Veri­f­y­Host­KeyDNS ask rein­ge­wor­fen, und schon wird der Fin­ger­print aus dem DNS ver­wen­det:

Bildschirmfoto 2015-03-27 um 08.21.41

0

DNSSEC, für Hendrik Lipka

Und so gehts:
Sys­tem: ein Open­sue 13.1, das ist aber völ­lig Wurscht, wich­ti­ger ist es in die­sem Bei­spiel, einen halb­wegs aktu­el­len bind zu haben.
Ich hab’ das erst im Heim­netz pro­biert mit BIND 9.8.4-rpz2+rl005.12-P1 (Debi­an whee­zy) — das ist aber ziem­lich alt. Dann auf Arbeit mit BIND 9.10.1-P1 — und zuletzt eben auf der Suse umge­setzt (BIND 9.9.4-rpz2.13269.14-P2 (Exten­ded Sup­port Ver­si­on))
Das ist nichts für Eri­ka Mus­ter­frau, zumin­dest mit den Begrif­fen soll­te man ver­traut sein, eben­so mit einem nor­ma­len bind-Set­up (also ohne DNSSEC)
Das ist hier sehr kurz geschrie­ben, man­che Schrit­te mögen feh­len. Wer auf­merk­sam liest, kann die sel­ber ergän­zen.

Ein Ver­zeich­nis für die Keys anle­gen:

allinclusive:/var/lib/named/etc # mkdir dnssec-keys

ZSK erzeu­gen:

allinclusive:/var/lib/named/etc/dnssec-keys # dnssec-keygen -a RSASHA512 -b 4096 sokoll.com.
Generating key pair................................++ ..................................................++
Ksokoll.com.+010+30918
allinclusive:/var/lib/named/etc/dnssec-keys # ls -l Ksokoll.com.+010+30918.*
-rw-r--r-- 1 named named 950 Mar 23 20:41 Ksokoll.com.+010+30918.key
-rw------- 1 named named 3317 Mar 23 20:41 Ksokoll.com.+010+30918.private
allinclusive:/var/lib/named/etc/dnssec-keys #

KSK erzeu­gen:

allinclusive:/var/lib/named/etc/dnssec-keys # dnssec-keygen -a RSASHA512 -b 4096 -f KSK sokoll.com.
Generating key pair..................................................................................................................................................................................................++ ......................................................................................................++
Ksokoll.com.+010+49955
allinclusive:/var/lib/named/etc/dnssec-keys # ls -l Ksokoll.com*
-rw-r--r-- 1 named named 950 Mar 23 20:41 Ksokoll.com.+010+30918.key
-rw------- 1 named named 3317 Mar 23 20:41 Ksokoll.com.+010+30918.private
-rw-r--r-- 1 named named 951 Mar 23 20:41 Ksokoll.com.+010+49955.key
-rw------- 1 named named 3317 Mar 23 20:41 Ksokoll.com.+010+49955.private
allinclusive:/var/lib/named/etc/dnssec-keys #

named-con­fig bear­bei­ten:

allinclusive:/etc # vi named9.conf
zone "sokoll.com" {
type master;
auto-dnssec maintain;
key-directory "/etc/dnssec-keys";
inline-signing yes;
file "master/sokoll.com";

Suse-spe­zi­fisch: Beim Star­ten des named wird die named.conf aus /etc nach /var/lib/named/etc kopiert, des­halb hier ein sys­temc­tl restart named.service machen!
Dem Nut­zer named (unter des­sen Ken­nung der bind läuft, Lese­rech­te auf die Keys geben:

allinclusive:/var/lib/named/etc/dnssec-keys # chown named *
allinclusive:/var/lib/named/etc/dnssec-keys #

Zone signie­ren:

allinclusive:/var/lib/named/etc/dnssec-keys # rndc sign sokoll.com
rndc: 'sign' failed: unexpected end of input
allinclusive:/var/lib/named/etc/dnssec-keys #

Die Feh­ler­mel­dung scheint ein Bug zu sein, cf. https://bugzilla.redhat.com/show_bug.cgi?id=1114953

Zone tes­ten:

~$ dig +dnssec sokoll.com ns.sokoll.com | grep ^ns
ns.sokoll.com. 23959 IN A 195.110.60.28
ns.sokoll.com. 86337 IN RRSIG A 10 3 86400 20150422190822 20150323185355 49955 sokoll.com. F2/UZIhGiWxEZZ1Aa22mS30K1L/rz0qd8GlBppzt6Rz8OGzr+H3TPypr fDJqjrFFoMQzwSdvAyEb0E5MhCVeXFH5olKFabdlucXaXfu5CYIkcx5y KDDoaTGvyHee2RfjA/taSPpCV1a3ylVvYo3qoeY3Pd3sOf2U72dFYlp/ kznsZVFwJkee/xQF0Apk3Q+A9oeBcV7AW4VnrehRaWq7UcnkPW96gD3n UBnVSh8RnUsKs3lOqPtnqszD06Hzy+Mzq3PCR6bLTql3LPasQJ96XLnv WGUefFxOXqPk2t+pvFM0z95x31gPRckYr7YVehs9CUDidqUsswGFwz5K 1yREqPkyjVJULIMrPfx1B2FQrQ7ZvpN1t2yzQuuyynZAXasuA++OLviP 7wxOcZUIIzll9GkiV3CkjNzb7zTPxBmq+HtppcFjh/X8QhJ9EwAypFfj yp8kRZ4xDvBk6Fly8ATx9TpikYfis/+xmZwt4GCi6f7z9vvDkOnjVsD0 0ND9Ty9tJtDC18oWrq62T4UsSfxfm64XDsfKvsLUQ7VFH189E3X9NtKy ki1gGxAYqD7xXDbN9bQ9EIZf5fuqU20y0cie1rHCa6vx41gQ8pfnF7sp 0GPE4efwDqefd80JBCgNR+psRBzrdNUrTSplNBFR9xBlPernnG5F4bKA qqs/TdGNztQ=
~$

Voi­la, wir haben einen RRSIG-RR!

NSEC3 ein­schal­ten, um Zone-Wal­king zu ver­hin­dern

allinclusive:/var/lib/named/etc/dnssec-keys # rndc signing -nsec3param 1 0 10 13F92714 sokoll.com
request queued
allinclusive:/var/lib/named/etc/dnssec-keys #

Tes­ten von außer­halb:

rainer@dockstar:~$ ldns-walk sokoll.com. @ns.sokoll.com
sokoll.com. Zone does not seem to be DNSSEC secured,or it uses NSEC3.
rainer@dockstar:~$

DS-RR erzeu­gen, der dann in die com-Zone gehört:

allinclusive:/var/lib/named/etc/dnssec-keys # dnssec-dsfromkey -2 Ksokoll.com.+010+30918
sokoll.com. IN DS 30918 10 2 BAE5EE42D7729BB486B30C5658DC7322BAFDA9001F29B3328186D89471EE4918
allinclusive:/var/lib/named/etc/dnssec-keys #

Der Record muß in die Zone ein­ge­fügt wer­den!
Seri­al erhö­hen, Ände­run­gen bekannt­ma­chen

allinclusive:/var/lib/named/etc/dnssec-keys # rndc reload sokoll.com
zone reload queued
allinclusive:/var/lib/named/etc/dnssec-keys #

Auf http://dnssec-debugger.verisignlabs.com/sokoll.com gehen und freu­en 🙂

0

Wir testen DNSSEC

Und wenn schon, dann gleich rich­tig — wofür sonst gibts die TLD sokoll.? 😉

~$ dig +dnssec dockstar.sokoll.

; >> DiG 9.8.3-P1 >> +dnssec dockstar.sokoll.
;; global options: +cmd
;; Got answer:
;; ->>HEADER- opcode: QUERY, status: NOERROR, id: 23797
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dockstar.sokoll.		IN	A

;; ANSWER SECTION:
dockstar.sokoll.	86400	IN	A	192.168.1.15
dockstar.sokoll.	86400	IN	RRSIG	A 10 2 86400 20150421120415 20150322113415 38792 sokoll. fOqrX+OBgGCiynhseSTZPiCHEV8j7XJ0YGhtnCN5DsiY6EZRNrxmL68/ 0uJA5wDEWSs8GBtmpuRPrnJvCSmuWGz+v+1I3nyTeMRjsN+0YHIpn5qn Z7L+yR0NO4eHdSiWcpH49gdLZtK20jB5epVNrOii8bUo6DWIvYTJrIKY giKt6vHO0ORdxOt49FOk9iLeoFV3g3AeJHJ2QPVO0HEeDhN+Z4Buxjj8 lEK1jB8DgIHoHyQpWSnuQqLWMvrs//IQJXeZZG/VsdUV3w9FThpr5pjK o9BA7S3u223vOK9d9MkyQmZFNtmXUerYvm+VCFJUD2fGO7J5GFcSowz8 RhvMocuFm3y6dvAh3F3PQT3j+rlQ8gIwy4ZrfKqGpYns9XzFnvHHww1Y r/ARwLiKgEx9iyzby5EzZW/9Cf+PPrVYa/xCaw2d+uj4R89PCk2rpB9a jFMa0f8U/Rblb2i8c9y5h2Fj1JQBfUSD2Ar2+nKb4yo1XtW0i8xjpitt Md6YICHaGkdwcx/hGAsn5P9Hkjb2ZuXA+P3NBuhKapQ/nYt6ir0lbAhC ezjDf1Rdl/wU5QKpKJ5FGLXjei5EpCrFluyrsYB13Dvok77KRKJPLWto PNNRrvkzI+QsqnxTM/+A+D6Msy2qYGbt1FaYKdO/vuDgw4Hob2Rkvsar w7RJKpEH5Js=

;; AUTHORITY SECTION:
sokoll.			86400	IN	NS	dockstar.sokoll.
sokoll.			86400	IN	RRSIG	NS 10 1 86400 20150421113536 20150322113358 38792 sokoll. vMMfi1aO+tSpnrmydmnqQkNWCIVLINUBE/yY2jQuUtaWQvV6VVt7WxNH +65UNuN02jBsuxvIq8zfC4uVLJ9VPckfm/+4OzoQCoRF4D3E4lbq3oPn FDX9tJZa7fLXww5PkTHUgPgA/ySa7dxQounyo0s9IfNutNRWhuNMWHzi 0wy6O6Qs7uVDtEHIsJjbWPehMGWY0TaaRIIt4NcUoFE/FjItcrl/z6p3 j0A4SPTYdWO418uiQ1fXQ4qbAQnbpFGPx7Qzwh23a8FoH7qYXRI8ntNQ Kge73HKmzvLBzRqqN9x9h6QB3PC9Bi0aAJFFFy0jNZ+giDCw8Z2X5Oa4 CZAPV41t3JmRJCWb2dRxqQVg1T8/5CV5pyBnZdc5ou6ywRNySfE7EB2B ZHI1p8Ze0aYZieEDD7AL1n+lBSnE8BxJBQTD7IlzmQ9aW/7fd7fokHye KPnzIyt75PKpHbyzvn0WMaPGvKzspoPZMomhdSTq2WAGHFqPKiIQsjr6 pD5uZ95NjFKZJsWXvWmDQBnaI/kdR9fXHAPbZZoF/SJxAX3EVBCPM5cS hbK08yGoAYdHwcTFo5eMI7qBBTEtQXmxeFZIYPnEkfCBrv5cYIG36uru IC4OSgMjn9y7NWd9PIwkzXDfRlviNqIp6xuLD8bTZDyhcLm1NzVSFfop YyoIPFUcxfY=

;; Query time: 5 msec
;; SERVER: 192.168.1.15#53(192.168.1.15)
;; WHEN: Sun Mar 22 16:22:57 2015
;; MSG SIZE  rcvd: 1174

~$

Das sieht doch schon gut aus, oder?

0

IPv6, Kabel Deutschland

Ges­tern habe ich mei­nen gelieb­ten Caram­bo­la gebrickt 🙁 Hof­fent­lich nicht wirk­lich, aber um das her­aus­zu­be­kom­men, brau­che ich ein seri­el­les Kabel, was ich nicht habe.
Bildschirmfoto 2015-01-23 um 23.11.07
Alles halb so wild, über das Kun­den­cen­ter von KD habe ich dann das Modem wie­der zum Rou­ter gemacht, das ging recht flott. Dum­mer­wei­se hat der LAN-sei­tig per default ein ande­res Netz als mein Heim­netz, aber auch das läßt sich umkon­fi­gu­rie­ren.

In einem Anfall von Wahn­sinn woll­te ich dann tes­ten, ob ich nicht viel­leicht doch IPv6 hät­te, und sie­he da:

~$ ping6 -c 5 heise.de
PING6(56=40+8+8 bytes) 2a02:8108:1e00:1984:6012:d2c0:721c:4383 --> 2a02:2e0:3fe:1001:302::
16 bytes from 2a02:2e0:3fe:1001:302::, icmp_seq=0 hlim=51 time=101.131 ms
16 bytes from 2a02:2e0:3fe:1001:302::, icmp_seq=1 hlim=51 time=27.955 ms
16 bytes from 2a02:2e0:3fe:1001:302::, icmp_seq=2 hlim=51 time=31.668 ms
16 bytes from 2a02:2e0:3fe:1001:302::, icmp_seq=3 hlim=51 time=32.653 ms
16 bytes from 2a02:2e0:3fe:1001:302::, icmp_seq=4 hlim=51 time=29.657 ms

--- heise.de ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 27.955/44.613/101.131/28.306 ms
~$

Na Hos­sa!

Hm. gleich mal nach­se­hen, ob ich auch aus der Welt erreich­bar bin: http://www.ipv6tech.ch/?tcpportscan bie­tet das. Mei­ne IP ein­ge­ge­ben, und WTF??? Port 22 (ssh) und 88 (ker­be­ros) sind erreich­bar!

Lokal konn­te ich das mit sudo tcp­dump -n -i en1 ip6 and ’(port 22 or port 88)’ nach­voll­zie­hen. WTF?

Also noch­mal mit dem Brow­ser auf dem Modem­rou­ter (es ist ein CBN CH6640E) ange­mel­det und nach­ge­se­hen.

Ergeb­nis. Die Fire­wall ist per Default auf any:any allow ein­ge­stellt 🙁 Nach­dem ich die Regel deak­ti­viert habe, sieht erst­mal alles wie­der fein aus.

Wer also via Kabel Deutsch­land ange­bun­den ist und nichts wei­ter gemacht hat, könn­te sehr gut völ­lig nackig im Netz ste­hen.

0

XMPP/Jabber, jetzt aber richtig

Mein Jabber-Ser­ver (open­fire) hat­te ein selbst­si­gnier­tes Zer­ti­fi­kat, noch dazu im Okto­ber abge­lau­fen.
Und da Flo­ri­an einen Kon­takt auf jabber.ccc.de hat, der aber nicht ging, war es Zeit, das rich­tig zu machen.
Also habe ich mir einen CSR erzeugt und den bei startssl.com ein­ge­kippt. Die gaben mir dann freund­li­cher­wei­se ein Clas­s1-Zer­ti­fi­kat zurück — und nun begann der Kampf. Open­fire ist java, und das hat für das gesam­te Key­ma­nage­ment ein Drecks­tool namens key­tool. Nach Stun­den habe ich es dann doch hin­be­kom­men, die Zer­ti­fi­ka­te ein­zu­bau­en.

Man benö­tigt das Zer­ti­fi­kat natür­lich, dazu noch das Zwi­schen­zer­ti­fi­kat von starts­sl, das es hier gibt.
Wir wech­seln nach /opt/openfire/resources/security.
Dann wer­den die bei­den Zer­ti­fi­ka­te zusam­men­ge­wor­fen:

cat /etc/ssl/private/xmpp.sokoll.com.startssl.crt /etc/ssl/private/sub.class1.server.ca.pem > xmpp.pem

Und jetzt kommt der gro­ße Trick: key­tool kann zwar PEM-Zer­ti­fi­ka­te impor­tie­ren, aber kei­ne pri­va­ten Keys. Also muß ein Bund­le aus den bei­den Zer­ti­fi­ka­ten und dem pri­va­ten Key im PKCS#12-Format erzeugt wer­den, dafür neh­me ich opens­sl:

openssl pkcs12 -export -in xmpp.pem -inkey /etc/ssl/private/xmpp.sokoll.com.startssl.key -out xmpp.p12

Den alten keysto­re habe ich ein­fach mit rm keysto­re weg­ge­wor­fen.
Nun kön­nen wir auch einen neu­en keysto­re mit pri­va­tem Key und den bei­den Zer­ti­fi­ka­ten erzeu­gen:

keytool -importkeystore -deststorepass changeit -destkeypass changeit -srckeystore xmpp.p12 -srcstoretype PKCS12 -srcstorepass changeit -srcalias 1 -destalias sokoll.com -destkeystore keystore

Ja, das Paß­wort zu mei­nem keysto­re lau­tet “chang­eit”, falls jemand das braucht 😉
Open­fire neu­star­ten, die neu­en Zer­ti­fi­ka­te soll­ten in der Admin-UI auf­tau­chen.

Soweit, so gut, gleich mal nach­se­hen, wie das von außen aus­sieht. So. viel grün, könn­te aber grü­ner sein 🙂 Das “Warning: Ser­ver allows RC4 when using TLS 1.1 and/or TLS 1.2. Gra­de cap­ped to A-.” stört aber. RC4 will man mei­nes Wis­sens nicht. Und SSLv3 will man nach Pood­le auch nicht, wenn auch das für XMPP irrele­vant sein dürf­te.
Doch wo stellt man das aus? Hm, in der JRE, bei mir in /usr/lib64/jvm/java-1.7.0-openjdk-1.7.0/jre/lib/security/java.security. Ich habe ans Ende ein­fach ein jdk.tls.disabledAlgorithms=RC4, MD5, SHA1, DSA, RSA key­Si­ze < 2048 dran­ge­pappt, und ja, es sieht bes­ser aus.
Aller­dings sieht es so gut aus, daß mein Cli­ent (Jit­si) sich nicht mehr ver­bin­den mag — wahr­schein­lich wegen des feh­len­den TLSv1.1.
Für Tipps, wie ich das hin­ein­be­kom­me, aber ohne SSLv3, bin ich dank­bar.

0
© Rainer Sokoll Frontier Theme