Autor: Sebastian van de Meer (Seite 32 von 49)

ownCloud und Kalender / Kontakte synchronisieren

30. Januar 2014 / Sebastian van de Meer / Keine Kommentare

Meine Frau führt schon immer den „Familienkalender“…. Vor der Smartphonezeit war dieses ein kleines Büchlein in ihrer Tasche und ein größerer Kalender an der Wand. Es gab natürlich immer mal wieder Unterschiede zwischen dem kleinen Büchlein in der Tasche und dem Kalender an der Wand. Am meisten störte mich immer, dass ich sie anrufen musste wenn ich nach einem freien Termin gefragt wurde. Hatte immer so ein bisschen was von: „Bei Mama fragen ob ich mit meinen Freunden spielen gehen kann.“

Mit den Smartphone bot sich nun endlich die Möglichkeit Termine synchron zu halten. Natürlich war es nie eine Option die Daten bei irgendjemandem abzulegen, sondern dann schon unter eigener Kontrolle. Daher in die ownCloud 🙂

Somit sehe ich nun den Kalender meiner Frau, welchen sie für mich freigegeben hat und sie natürlich auch meinen. Dieses nicht nur im Webfrontend der ownCloud und auf dem Android Smartphone sondern zusätzlich noch auf unseren Computer. Egal ob kmail, Evolution oder oder…. Überall ist nun alles gleich!

Dabei setzten wir auf unseren Androiden die Apps CalDAV-Sync und CardDAV-Sync ein. Bisher arbeiten diese Apps sehr gut auf unseren Geräten.

Man braucht Google wirklich nicht um seine Geräte im „Gleichgewicht“ zu halten. Ok, die Konfiguration ist etwas aufwendiger als wenn man das vorgegebene nutzt…. Der Gewinn ist aber aus unserer Sicht riesig.

DMARC und das Problem mit den Mailinglisten

29. Januar 2014 / Sebastian van de Meer / Keine Kommentare

Wenn man etwas nicht ausprobiert oder am besten damit arbeitet, dann kommt man mit einigen Problemen nicht in Berührung. Warum nicht? Na, viele Probleme treten erst in einer gewissen Kombination auf oder man denkt erst überhaupt nicht dran.

Über so etwas bin ich vor kurzem „gestolpert“. Problem? Joar, in Verbindung mit Mailinglisten. Mailman ist da ja ganz vorne! Im Grunde ist DMARC nicht der Hauptverantwortliche. DMARC hat mehr dafür gesorgt dass dieses Problem „bewusst“ wird.

DKIM signiert, anders als z.B.: GPG, nicht nur den E-Mail Body (sprich den eigentlichen Text und ggf. noch Anhang), sondern unter anderem auch den Betreff einer E-Mail. Publiziert man nun eine DMARC Policy, welche E-Mails zurückweist wenn der DKIM Check fehlschlägt… Ja dann werden oft E-Mails die man über eine Mailingliste schickt zurückgewiesen. Das liegt daran dass die DKIM-Signatur durch den Mailinglisten-Manager gebrochen wird. Es wird z.B.: der Betreff verändert und eine Fußnote (Werbung und oder Infos für die Mailingliste) an den E-Mailtext angehangen.

Fast alle Mailinglisten-Manager (auch Mailman) erweitern die E-Mail ebenfalls um einen Header. Liste-id: Früher gab es diesen Header nicht. Früher wurde also meist vor den Betreff noch ein Identifier für die Mailingliste gestellt. Zum Beispiel etwas wie: „[tollte-Mailingliste] eigentlicher Betreff“. Nun konnte jeder Abonnent einfach in seinem Mailclient einstellen dass alle E-Mails die im Betreff diesen Identifier enthalten an eine besondere Stelle sortiert werden. Heute kann/sollte man es über den List-id Header umsetzten. Die meisten Mailclients erkennen diesen Header und man kann die Regel schon mit der rechten Maustaste verwirklichen.

Nun könnten die Betreiber einer Mailingliste ihren Mailinglisten-Manager so konfigurieren dass die DKIM Signatur nicht gebrochen wird. Das größte Hindernis scheint dabei denn noch zu sein, dass sie gerne diesen Identifier behalten wollen. Oft ist ihnen das Problem einfach nicht bewusst. Ich habe dieses Thema natürlich bereits bei einigen großen Listen angesprochen. Es scheint im Moment nicht genügend Druck für eine Umsetzung zu geben. Wird sicher noch… Schon alleine weil Microsoft und Google mit hinter DMARC stehen. Beide haben zwar einen DMARC-RECORD, geben eine keine klare Policy vor. Ob dieses ein Grund sein könnte?

Bleibt also wieder, wie so oft, dieses Problem zu thematisieren. Nachfragen, aufklären und hoffen. Sicherheit muss leider oft Bequemlichkeit weichen.

Postfix SSL/TLS sichern mit TLSA, DANE und DNSSEC

28. Januar 2014 / Sebastian van de Meer / Keine Kommentare

Mein Domains sind nun schon seit langem per DNSSEC gesichert. Schnell habe ich auch TLSA-RECORDS für mein SSL/TLS X.509 Zertifikat des Webservers Apache veröffentlicht, damit die verschlüsselte Verbindung zu meiner Webseite ebenfalls per DANE gesichert ist.

DNSSEC: https://www.kernel-error.de/dnssec

DANE: https://www.kernel-error.de/dnssec/tls-ssl -zertifikatschecksummen-im-dns

Seit Januar diesen Jahres beherscht nun Postfix ebenfalls die Möglichkeit TLSA Records zu prüfen. Da mache ich natürlich mit!

Zuerst muss die Postfix Version natürlich passen. Kleiner 2.11 sollte es nicht sein, die Postfixversion zeigt sich schnell per:

$ postconf -d | grep mail_version
mail_version = 2.11.0

Mein Mailserver bietet natürlich schon immer die Möglichkeit einer verschlüsselten Verbindung an. Daher gehe ich einfach mal nicht näher darauf ein, wie man sein Postfix dazu überredet. Ganz kurz… Aktivieren lässt sich die Unterstützung für DANE / TLSA mit folgenden drei Konfigurationsänderungen:

$ postconf -e "smtpd_use_tls = yes"
$ postconf -e "smtp_dns_support_level = dnssec"
$ postconf -e "smtp_tls_security_level = dane"

Keine Sorge, alles bietet einen Failback an, so leidet die Kommunikation mit _nicht_ DANE fähigen Systemen nicht.

Zum erstellen des TLSA-RECORDS muss selbstverständlich nicht unbedingt der von mir in früheren Beiträgen erwähnte Hash-slinger eingesetzt werden. Openssl macht dieses fast genau so schnell.

$ openssl x509 -in postfix.pem -outform DER | openssl sha256
(stdin)= 94c8e1bdfff4f6d3fec0c4e2f26293d78870650bfd3534e77b93cdaccb77eb95

Aus diesem Hash erstelle ich nun den TLSA RECORD. Für die E-Mail Kommunikation ist es mir lieb, wenn der TTL (Lebensdauer) des Records nicht ZU lange ist. Bei einem Zertifikatswechsel dauert es sonst unnötig lange bis der neue Record gültig ist. Daher setzte ich ihn auf 1 Stunde.

_25._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
_465._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

Wie zu sehen ist biete ich den TLSA RECORD direkt für Port TCP 25 und TCP 465 an. Schnell nur noch testen ob der TLSA RECORD mit dig auch sauber abgefragt werden kann.

$ dig _25._tcp.smtp.kernel-error.de +dnssec +m

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> _25._tcp.smtp.kernel-error.de +dnssec +m
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_25._tcp.smtp.kernel-error.de. IN A

;; AUTHORITY SECTION:
kernel-error.de.        86400 IN SOA ns1.kernel-error.de. root.kernel-error.de. (
                                20140102708 ; serial
                                10000      ; refresh (2 hours 46 minutes 40 seconds)
                                1800       ; retry (30 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
kernel-error.de.        86400 IN RRSIG SOA 7 2 86400 20150511054702 (
                                20140516054702 38150 kernel-error.de.
                                QXUpVl3myVAUGn/ox8J5aihAySHdWpojyPuhV5QKgDUy
                                qYRPyryWyBoGG+x5cGs0JpPBqQA3lRovAM4JFvC3hRmO
                                FU3fVTiYlvAJK7WsTSgPJLYpXrBnS+NN0O2UW3W+Ru1K
                                2P5dj+BWNO1wqXs+VU7WpMPwq/ESlK88hxXE1Gc= )
_25._tcp.smtp.kernel-error.de. 86400 IN NSEC _465._tcp.smtp.kernel-error.de. RRSIG NSEC TLSA
_25._tcp.smtp.kernel-error.de. 86400 IN RRSIG NSEC 7 5 86400 20150511054702 (
                                20140516054702 38150 kernel-error.de.
                                ToC8GtXFenieGjA32eoHACNGCg+tFr05vz6w9yiHYrDj
                                rHGBabc7MMjqUWNsf7L059YhR7dLoAPqhy2ZThWqFbRD
                                ZsfPQSgHIazEuKvOE7i2Ee/znU2d57X8nVkp8scUKZ1R
                                kGdK5DUDlAcYn0YdpjYaUTn2STdbM9IDcdrASPE= )

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mo Jan 27 08:50:36 2014
;; MSG SIZE  rcvd: 506

Schon lässt sich im Postfix Logfile erkennen ob Verbindungen getraut wird oder nicht.

Jan 27 08:32:02 mailserver postfix/smtp[3779]: Verified TLS connection established to mx02.example.de[99.88.12.167]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jan 27 08:33:19 mailserver postfix/smtp[3779]: Untrusted TLS connection established to smtp2.example.de[2001:333:6661:99::34]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)

Wenn man mich fragt, ist die Kombination aus DNSSEC, DANE / TLSA deutlich besser als dieses hässliche EmiG. EmiG benötigt eine unnötig teure Zertifizierung durch den TüV, dieses kann sich nicht jeder leisten. Damit ist dieses „sichere“ Verfahren fast nur durch Unternehmen zu realisieren die genug Kohle haben. Kleinere werden damit einfach abgehängt. Verfahren die Sicherheit nur für „reiche“ zur Verfüfung stellen sollte man aus meiner Überzeugnung nicht unterstützen.

Eine weitere schnelle und einfache Möglichkeit seinen TLSA-RECORD des Mailservers / Postfix zu testen ist posttls-finger:

$ posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de
posttls-finger: initializing the client-side TLS engine                                                                                                                                                                          
posttls-finger: using DANE RR: _25._tcp.smtp.kernel-error.de IN TLSA 1 0 1 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95                                                       
posttls-finger: setting up TLS connection to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25                                                                                                                                  
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"                                                                                        
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA                      
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA                      
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 verify=1 subject=/description=y0xkuso3gx7t8h0o/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=smtp.kernel-error.de/emailAddress=postmaster@kernel-error.de                                                                                                                                                                                                   
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 matched end entity certificate sha256 digest 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95         
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: subject_CN=smtp.kernel-error.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=E1:92:93:D4:CA:E9:5D:44:B5:CC:A4:15:1F:12:A6:E0:B5:C2:97:56, pkey_fingerprint=E9:84:8E:51:47:99:90:53:0B:2C:2E:1E:70:6E:DE:CA:A4:65:8A:C5                                                                                                                                             
posttls-finger: Verified TLS connection established to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

So bei Fragen, einfach fragen 🙂

09-08-2014 Update

Ich habe zur Auswertung den Mailgraph etwas angepasst ( mailgraph Graphen um DANE erweitern ). Dieser wirft mir nun den unten stehenden Graphen für ausgehende Verbindungen raus.

Zum Dumm, zum Zum: Eine humorvolle Reflexion

27. Januar 2014 / Sebastian van de Meer / Keine Kommentare

Na, mal wieder Lust auf etwas aus der: „Mein Gott, van de Meer!“ Ecke? OK…
Ich werfe also gerade einige Domains auf einen neuen DNS Server. Alles prima, nur saugt sich der Slave die Zonen nach einer Änderung nicht vom Master. Ich teste alles durch renne wild umher und gehe schon anderen Leuten auf den Sack. Bis mir jemand sagt… Kommen die Notifys vielleicht noch vom alten Server? Der PTR von der IPv4 Adresse ist….. Gott bin ich doof. Mein Gott bin ich blöde…

Der neue DNS Server hat mehrere IPv4 Adressen. Der Bind hört natürlich auf eine, nur ist es nicht die primäre IPv4 Adresse des Servers. Der Bind schickt folglich die Notifys über eine andere IPv4 Adresse zum Slave. Der denkt sich… Ok tolle Info aber ich soll auf ne andere Adresse hören. Also interessiert er sich nicht und zieht sich die Zone nicht. Ist ja ich richtig so!

Ich Wurst habe nämlich vergessen dem Bind zu sagen dass er bitte einfach alles über eine bestimmte IPv4 Adresse versenden soll. Ich muss den Bind im Grunde an eine ausgehende IP Adresse binden.
Kann Bind natürlich, schon alleine wegen IPv6. Denn da hat man ja schnell mehrere Adressen.
Nun kann man dem Bind viele verschiedene Vorgaben machen, wie er denn bitte den Weg nach draußen zu nehmen hat. Man kann sagen über welche IP Adresse er selbst anfragen rausschicken soll, über welche Adresse er bitte die Zonen durchreichen soll und auch über welche Adresse er das Notify an den Slave schicken soll.

options {
......
transfer-source 1.2.3.4;
notify-source 1.2.3.4;
query-source 1.2.3.4;
......
};

Alles einfach in den Optionsblock und fertig ist:

So einfach kann es sein, WENN MAN DARAN DENKT! Damit bewegt sich Bind fast nur noch über die angegebene Adresse nach draußen. Man bin ich blöde und wieviel Zeit ich damit wieder verbrannt habe *heul*!

ownCloud und Mozilla-Sync

26. Januar 2014 / Sebastian van de Meer / Keine Kommentare

Wem kann man schon trauen? Richtig, niemandem! Man kann also nur das geringste Übel wählen… Im Moment vertraue ich dem Mozilla Browser mehr als dem Google-Browser. Die Browser über verschiedene Geräte und Platformen zu synchronisieren ist eine wunderbare Erleichterung. Nur damit diese Daten immer auf allen Geräte gleichermaßen zur Verfügung stehen müssen sie an einem zentralen Ort vorgehalten werden. Nun habe ich verständlicherweise ein Problem damit diese Daten einfach auf irgendeinen Server, irgendwo in der Welt zu packen. Ich meine… Das sind meine Browserdaten und damit ebenfalls die gespeicherten Kennwörter, meine Leserzeichen, wo ich herumsurfe usw. usw…. OK, die Daten werden dort verschlüsselt abgelegt. Es hinterlässt denn noch ein unangenehmes Gefühl.

Zum Glück gibt es eine Möglichkeit die Daten einfach mit in die ownCloud zu werfen. Einfach als Admin die App „Mozilla Sync“ aktivieren. Schon lässt sich im Firefox die Verbindung zu einem eigenen Server einstellen. Weitere Geräte werden dann so verbunden als wenn man den Mozilla Server nutzen würde.

Contabo VPS

26. Januar 2014 / Sebastian van de Meer / Keine Kommentare

Lange habe ich nach einem ordentlichen Anbieter für einen neuen vServer gesucht. Dabei galt es folgende Kriterien zu erfüllen:

– Min. 2 IPv4 Adressen
– Ein kleines IPv6 Netz
– Unbegrenzter Traffic
– Min. 100Mbit/s Anbindung
– Min. 2 CPUs
– Min. 4 GB RAM
– Min. 200 GB HDD
– Linux als OS

Natürlich habe ich zuerst die Großen abgeklappert.

– 1und1 kein IPv6 (warum nicht? Ich meine 2014 HALLO!?!?)
– Strato nur EINE IPv6 Adresse (Ö_ö eine IPv6 Adresse…. eine?)
– Host Europe kein IPv6 bei den vServer nur bei den Root Server EINE (tz..)
– 1blue kein IPv6
– Server4you kein IPv6 beim vServer, sonst soll es wohl gehen…
– Serverloft… Joar, die Kosten sind mir zu hoch. Sind aber auch keine vServer.
– usw. usw. usw…

IPv6 scheint noch immer ein größeres Problem zu sein, ist nicht voll integriert oder ist (wie auch meherer IPv4 Adressen) hochpreisigen Produkten vorbehalten.

Dann bin ich auf Contabo gestoßen. Ich war Opfer der Werbung im Linux Magazin 🙁 Preis/Leistung sah dabei einfach zu gut aus. Daher habe ich angerufen. Ohne lange Hoteline sprach ich mit einem Menschen. Diesem stellte ich direkt meine Fragen und er konnte sie überraschenderweise direkt und sicher beantworten. Mit sicher meine ich, dass man nicht das Gefühl hatte er würde es irgendwo nachlesen oder wäre nach einer kurzen Schulung auf die Hotline losgelassen worden. Nein, es war wirklich gut!

Natürlich habe ich abschließend die Frage gestellt wie es klappt dass die angegebene Leistung so gut ist, der Support so schön zu funktionieren scheint und die Ausstattung und Randbedingungen ebenfalls so gut erscheinen. Nach hörbarem Schmunzeln bekam ich die Antwort: Das würde oft gefragt…. Ich müsse es so sehen. Contabo selbst stellt wirklich nur die Hardware und die Infrastruktur. Für das System selbst ist man selbst verantwortlich. Wenn es da mal Probleme gibt, könnte der Support zwar helfen diese wäre dann aber Kostenpflichtig (er meinte damit wenn man seine Kiste mal zerfriemelt hat). Man müsse schon wissen was man tut, dieses würden Contabo bei seinen Produkten einfach voraussetzten.

Schien also genau das zu sein was ich gesucht habe! Daher habe ich bestellt… Wobei ich genau eine solche Antwort von jedem Root-Server erwarten würde.

Alles ging schnell und für mich verständlich online. Ich bekam eine E-Mail mit der Bitte Geld zu überweisen (wer konnte damit nur rechnen 😀 ). Kurz nach meiner Überweisung flatterten bereits die Zugangsdaten in mein Postfach.

Wie bei der Bestellung angeklickt hatte ich schon eine zweite IPv4 Adresse und konnte die PTR-Records flott im Webmenü eintragen. Um die PTR-Records der IPv6 Adressen zu ändern musste ich kurz den Support per E-Mail bemühen. Freitags um 23:36 Uhr habe ich ihn angemailt als ich morgens aufgewacht bin hatte ich schon die Bestätigung in meinem Postfach. Das System selbst ist genau wie bestellt und hat mehr Leistungsreserven als erwartet. Ich habe 8GB Arbeitsspeicher, 400Gb Festplattenplatz und zwei CPUs mit 3,4GHz. Auf der Webseite war nur etwas von 3,2GHz zu lesen. Ok ok… die paar MHz machen den Braten jetzt nicht fett, das es Core I7 CPUs sind hat mich denn noch überrascht!

Ich habe natürlich Speicher und CPU mal mit Arbeit beworfen um zu testen ob es nicht nur Schein ist. Alles prima…. Die Storage Anbindung ist ja gerne mal etwas zu genau auf den Punkt dimensioniert. Bei meinem System kann ich nicht klagen. Performance und I/Os sind wunderbar und mehr als ausreichend.

100Mbit/s sind auch 100Mbit/s… Wobei man hier auf das „Kleingedruckte“ achten muss: Keine zusätzlichen Kosten durch Traffic (bei einem Durchschnittsverbrauch über 40 Mbit/s in einem zusammenhängenden Zeitraum von mindestens 5 Tagen erfolgt eine Umstellung der Anbindung auf 10 Mbit/s).

Zu dem Thema muss ich dann wohl mal eine kleine Auswertung vom Support anfordern. Sollte doch machbar sein, oder?

Ob mich dieses noch ärgert, werde ich herausfinden 🙂 Ob mich noch mehr ärgert wird sich zeigen!

SSH Brute Force

15. Januar 2014 / Sebastian van de Meer / Keine Kommentare

Es ist ja nicht zu glauben… Da scheint eine ganze Chinabude nichts weiter zutun zu haben als SSH Burte Force Attacken durchlaufen zu lassen. Dieser Netzowner geht mir gerade tierisch auf die Nerven. Ich bekommen durchgehen Angriffe aus Netzen bei dem er der Eigentümer ist. Das ist im Moment auch echt massiv 🙁

netname: CHINANET-JS
descr: CHINANET jiangsu province network
descr: China Telecom
descr: A12,Xin-Jie-Kou-Wai Street
descr: Beijing 100088
country: CN
admin-c: CH93-AP
tech-c: CJ186-AP
mnt-by: MAINT-CHINANET
mnt-lower: MAINT-CHINANET-JS
mnt-routes: maint-chinanet-js
changed: hostmaster@ns.chinanet.cn.net 20020209
changed: hostmaster@ns.chinanet.cn.net 20030306
status: ALLOCATED non-PORTABLE
source: APNIC

role: CHINANET JIANGSU
address: 260 Zhongyang Road,Nanjing 210037
country: CN
phone: +86-25-86588231
phone: +86-25-86588745
fax-no: +86-25-86588104
e-mail: ip@jsinfo.net
remarks: send anti-spam reports to spam@jsinfo.net
remarks: send abuse reports to abuse@jsinfo.net
remarks: times in GMT+8
admin-c: CH360-AP
tech-c: CS306-AP
tech-c: CN142-AP
nic-hdl: CJ186-AP
remarks: www.jsinfo.net
notify: ip@jsinfo.net
mnt-by: MAINT-CHINANET-JS
changed: dns@jsinfo.net 20090831
changed: ip@jsinfo.net 20090831
changed: hm-changed@apnic.net 20090901
source: APNIC
changed: hm-changed@apnic.net 20111114

person: Chinanet Hostmaster
nic-hdl: CH93-AP
e-mail: anti-spam@ns.chinanet.cn.net
address: No.31 ,jingrong street,beijing
address: 100032
phone: +86-10-58501724
fax-no: +86-10-58501724
country: CN
changed: dingsy@cndata.com 20070416
mnt-by: MAINT-CHINANET
source: APNIC

HTML-5 Video

8. Januar 2014 / Sebastian van de Meer / Keine Kommentare

Mal schauen was da so geht… *test*

{bo_videojs width=[640] height=[264] controls=[1] autoplay=[0] preload=[auto] loop=[0] video_mp4=[http://video-js.zencoder.com/oceans-clip.mp4] video_webm=[http://video-js.zencoder.com/oceans-clip.webm] video_ogg=[http://video-js.zencoder.com/oceans-clip.ogg] poster=[http://video-js.zencoder.com/oceans-clip.png] text_track=[captions|/video-js/captions.vtt|en|English]}

Was ist denn hier wieder los?

6. Januar 2014 / Sebastian van de Meer / Keine Kommentare

Warum zum Eimer werde ich neuerdings auf Port 445/tcp angepümmelt?

Ist wieder irgendein Rotz unterwegs der da etwas Neues ausnutzt? Ich meine, wer macht schon smb/samba ins Internet? Etwas Traffic ist ja immer klopfend auf dem Port… Kaum ist es 2014 schon brennt hier der Baum?!? Ich habe alleine heute 9k Versuche geloggt. Können wir nicht langsam mal dieses hässliche IPv4 Protokoll abschalten, damit diese Bots aufhören Ranges abzuklopfen?

TCP SYN/Normal scan from host: 1.2.3.4/1.2.3.4 to TCP port: 445

$ grep -w 445/tcp /etc/services
microsoft-ds 445/tcp # Microsoft Naked CIFS

Irgendwas kommt da doch wieder, wenn mir mein snort so auf die Nerven geht, oder?

Grobe Schnitzer im der DNS Konfiguration testen.

3. Dezember 2013 / Sebastian van de Meer / Keine Kommentare

Da habe ich doch gerade noch einen Tipp bekommen (danke Felix). Möchte man „mal eben“ seine DNS Konfiguration inkl. Mailserver testen wird einem ein solcher Test über die Webseite www.dnsinspect.com angeboten.

Der Test geht natürlich jetzt nichts ins absolute Detail aber die ganz groben Fehler findet er dann schon. Auch so Dinge wie PRT – HELO/EHLO – Hostname oder postmaster und abuse Adresse. Zu gesprächige Nameserver usw. usw. usw…

Einfach zum Spaß mal eure Domain reinwerfen und schauen was passiert .-)

http://www.dnsinspect.com/kernel-error.de