Schlagwort: Sicherheit

ClamAV mit eigenen Signaturen

Auf Arbeit haben wir in letz­ter Zeit ver­mehrt unter Viren­mails zu lei­den, die von kei­nem der bei uns ver­wen­de­ten Viren­scan­ner als Viren­mails erkannt wer­den.
Auf G+ wur­de ich auf ein schon älte­res Pos­ting auf­merk­sam gemacht, das erklärt, wie man eige­ne Signa­tu­ren schreibt.

Geht wun­der­bar (ich habe den Cla­mAV aus den Quel­len sel­ber über­setzt):

mailgate:/tmp # /usr/local/clamav/bin/clamscan invoice574206_1.pdf
invoice574206_1.pdf: OK

----------- SCAN SUMMARY -----------
Known viruses: 4137933
Engine version: 0.98.7
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.28 MB
Data read: 0.12 MB (ratio 2.29:1)
Time: 12.807 sec (0 m 12 s)
mailgate:/tmp #

Nix gefun­den, wir schie­ben die eige­ne Signa­tur an die rich­ti­ge Stel­le:

mailgate:/tmp # mv ISH-custumsigs.ndb /usr/local/clamav/share/clamav/
mailgate:/tmp #

Und dann noch­mal:

mailgate:/tmp # /usr/local/clamav/bin/clamscan invoice574206_1.pdf
invoice574206_1.pdf: ISH.Trojan.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 4137934
Engine version: 0.98.7
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.28 MB
Data read: 0.12 MB (ratio 2.29:1)
Time: 13.072 sec (0 m 13 s)
mailgate:/tmp #

Ich bin ent­zückt!

0

Mein Jabber-Server, und was das IM Observatory dazu meint

Die mei­nen: schlecht.
Cli­ent bzw. Ser­ver
Weiß jemand, wie ich die schwa­chen Cipher weg­be­kom­me? Das ist ein Open­fire unter

# java -version
openjdk version "1.8.0_60"
OpenJDK Runtime Environment (build 1.8.0_60-b27)
OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode)
#

jdk.tls.disabledAlgorithms in java.security zu set­zen hat jeden­falls nicht zum Erfolg geführt.
Und nmap läßt mich zwei­feln, ob die Web­site wirk­lich Recht hat:

~$ nmap --script ssl-enum-ciphers -p 5222 xmpp.sokoll.com

Starting Nmap 6.47 ( http://nmap.org ) at 2015-10-27 18:35 CET
Nmap scan report for xmpp.sokoll.com (195.110.60.28)
Host is up (0.040s latency).
rDNS record for 195.110.60.28: allinclusive.sokoll.com
PORT STATE SERVICE
5222/tcp open xmpp-client
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.1:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 9.16 seconds
~$
0

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
© Rainer Sokoll Frontier Theme