Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 31 von 48)

SSH Brute Force

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

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?

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.

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

Schönes Tool zum Testen / Prüfen seines SPF oder DMARC RECORDS

Die Webseite https://dmarcian.com stellt zwei sehr schöne Möglichkeiten zur Verfügung um seinen >> DMARC-RECORD << und oder seinen >> SPF-RECORD << zu testen.

Am besten gefällt mir dabei der SPF Test, denn dieser sammelt auch gleich alle nötigen DNS Lookups zusammen und visualisiert sie einem recht ansprechend.

Bunte Bilder *wwwööööööööööhhhhhhhhhyyyyyyyyy*

Ja, wenn es hilft schick mir eine E-Mail und ich sage dir ob deine Konfiguration sauber ist 😀

Viel Spaß!

VLAN mit den iproute Tool ip.

Früher also man noch ifconfig nutzte, da gab es vconfig um VLANs auf einem Linux Rechner zu konfigurieren. Wenn ich mich richtig erinnere ist die Verwendung von ifconfig inzwischen unter Strafe gestellt 😀

Also BITTE nutzt ip. Es kann mehr, es zeigt auch alles an und es ist viel einfacher. Vertraut mir…

Hier einmal kurz VLAN mit command ip!

Anlegen des VLAN Interfaces:

$ ip link add link eth0 name eth0.10 type vlan id 10

Vergeben eine IPv4 Adresse auf dieses neue VLAN Interface:

$ ip -4 addr add 192.168.10.1/24 dev eth0.10

Aktivieren des neuen VLAN Interfaces:

$ ip -4 addr add 192.168.10.1/24 dev eth0.10

Damit haben wir nun ein VLAN Interface mit der VLAN ID 10 und der IPv4 Adresse 192.168.10.1 und der Netzmaske 255.255.255.0. Die .10 im Interfacenamen hat nichts mit der VLAN ID zutun. Ich nenne es nur gerne so um es für mich einfacher zu machen 🙂

Ein Tool, sinnvoll aufgebaut, für fast alles nutzbar, funktioniert, geil. Benutzt es 🙂

SPF-Record erklärt: Schutz vor gefälschten E-Mails

Ich bin in der letzten Zeit immer mal wieder zu meinem SPF Record Beispiel gefragt worden. Ihr wisst schon… Diese beiden:

kernel-error.de.    IN  TXT "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"
kernel-error.de.    IN  SPF "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

Ich versuche das ganze noch einmal etwas aufzuschlüsseln. Die genannten Beispiele sollen die Möglichkeiten zeigen, welche man hat um den SPF-RECORD zu erstellen. Der echte SPF-RECORD sollte aber so schlank wie irgendwie möglich sein. Denn er wird ja theoretisch bei jeder eingehenden E-Mail geprüft. Um so länger er ist und umso mehr geprüft werden muss umso mehr DNS Lookups müssen gemacht werden. Man hat nach RFC nur maximal 10 DNS Abfragen, eine davon hat man schon verbrannt um den eigentlichen SPF RECORD zu holen. Es bleiben also noch 9 🙂 Kommt man über diese 10 Abfragen stirbt alles mit der Meldung:
Results – PermError SPF Permanent Error: Too many DNS lookups

Ist auch OK so, denn wenn der empfangende Mailserver für jede eingehende E-Mail hunderte DNS lookups durchführen muss, tut er ja nichts anders mehr!

Gut, nun zu meinem Beispielrecord.

v=spf1 ==> Ist die Protokollversion
ip4:212.23.142.146 ==> Von dieser IPv4 Adressen dürfen E-Mails kommen.
ip6:2001:7d8:8001:100::2 ==> Von dieser IPv6 Adresse dürfen E-Mails kommen.
ptr:smtp.kernel-error.de ==> Es dürfen E-Mails von den PTR Adresse“n“ des Hosts smtp.kernel-error.de kommen.
mx ==> Es dürfen E-Mails vom MX (Mail Exchange) der Domäne kernel-error.de kommen.
a:smtp.kernel-error.de ==> Es dürfen E-Mails von den IPv4 / IPv6 Adressen des Hosts smtp.kernel-error.de kommen.
==> Kommt die E-Mail von einem -nicht zutreffenden- System gilt der SPF-Test immer als Fehlschlag
all ==> Das ganze passiert immer.

Bei den IP-Adressen kann ebenfalls ein ganzes Netz angegeben werden. Zum Beispiel: 212.23.142.146/24

Beim mx könnte eine andere Domäne oder Subdomäne stehen. Zum Beispiel: mx:smtp.kernel-error.de damit dürften dann E-Mails vom MX der Domäne smtp.kernel-error.de kommen. Natürlich muss es diesen MX auch geben!!! Es geht noch mehr… Zum Beispiel habe ich in einer weiteren Domain von mir nur folgendes stehen:
v=spf1 include:kernel-error.de -all

include:kernel-error.de ==> Gibt an das bitte der SPF RECORD von der Domain kernel-error.de abgefragt und angewandt werden soll. Damit gilt die SPF-Policy der Domain kernel-error.de. Ich muss also nur eine Policy pflegen und lasse alle anderen Domains nur auf diese verweisen 🙂

Die Abfrage würde dann so aussehen:

DNS record(s):
    vandemeer.de. 86400 IN SPF "v=spf1 include:kernel-error.de -all"
    kernel-error.de. 86400 IN SPF "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 -all"

Würde man nun den oben stehenden RECORD in die Zone kernel-error.de. werfen und ihn aktiv nutzen; Dann wird er funktionieren und absolut gültig sein. Das empfangende E-Mail System wird aber eine ganz Hand voll DNS Abfragen machen müssen um diese SPF Policy zu prüfen. Jetzt beantwortet sich sicher die Frage, warum ich einen anderen SPF-RECORD einsetzte als hier aufgeführt 😀 Denn die aufgeführten RECORDS sind schlicht ein Beispiel und keine Copy & Paste Vorlagen. Ok ok… Ich hätte das direkt genauer beschreiben sollen, hm?

Weniger ist im SPF RECORD also mehr. Man darf sich also überlegen welcher RECORD für seine Domain und sein System gerade der beste ist. Wenn es wechselnde IP Adresse gibt ist sicher ein A/AAAA RECORD besser, wenn sich dieser oft ändert dann ggf. ein MX der Domain oder ein ganzes Netz oder oder…

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt

DMARC: Domain-Based Message Authentication, Reporting & Conformance (DMARC) einrichten

Habt ihr eigentlich schon etwas von DMARC (Domain-based Message Authentication, Reporting & Conformance) gehört? Nein… Dann dann haben wir das ja nun aufgeholt 😛

Im Grunde „erweitert“ DMARC die beiden Systeme SPF (Sender Policy Framework) und DKIM (DomainKeys Identified Mail). Warum und wie?!? Nun ja, beide Techniken sind erstmal ~nicht schlecht~. Setzt man sie ausgehend ein, fehlen dem Admin denn noch etwas die „Rückmeldungen“. OK, wenn etwas schief geht, jammern die User. Setzt man sie eingehend ein, würde es hin und wieder helfen wenn der „Absender“ einem etwas genauer sagen würde wie denn nun mit seinen Nachrichten umgegangen werden soll.

Hier springt nun DMAC -in die Bresche- (woher kommt eigentlich diese Redensart?). DMARC wird, wie bei SPF oder DKMI möglich, einfach als TXT-RECORD in der DNS Zone versenkt. Dort finden sich nun Informationen für den empfangenden Mailserver. Zum Beispiel kann angegeben werden wie viel Prozent der eingehenden E-Mails überhaupt gefiltert werden soll (pct), wie hart bei Fehlern im SPF (aspf) und DKIM (adkim) umgegangen werden soll, wie mit E-Mails der Haupt- (p) oder Subdomänen (sp) umgegangen werden soll und was tierisch geil für den Admin des Absendenden E-Mail Systems ist…. An welche E-Mail Adresse ein forensischer (das Wort trifft es, ich finde es aber doof :-P) Bericht (ruf) und wohin eine tägliche Zusammenfassung (rua) gesendet werden soll.

Diese Berichte schlagen normalerweise als E-Mail mit einem komprimierten ZIP-File im Gebäck auf. In diesem ZIP-File steckt dann ein XML-File (*würk* XML.. für die Auswertung denn noch geil). Diese kann man nun auswerten. So kann der Admin des absendenden E-Mail Systems sehen wie gut oder schlecht seine Bemühungen greifen. Er wird schnell über Probleme informiert und kann erkennen ob und wie stark seine Domain gerade -missbraucht- wird.

Eine E-Mail mit ZIP-File lässt sich sehr einfach automatisch auspacken und die XML Datei wird dann von irgendeinem Stück Software gefressen. Heraus kommt ein täglicher Bericht für den Admin. Ok, man könnte es schön bunt machen, dann kann man es auch einer Krawatte zum klicken geben 🙂

Klar muss der Empfänger es unterstützen, sonst bringt das alles nix. Aber jeder Absender, der bereits SPF und DKIM einsetzt, kann seinen DMARC Record schon mal erstellen, hm?

Ich probiere eine kurze Erklärung des DMARC TXT RECORDS an meinem…

_dmarc.kernel-error.de  IN TXT  "v=DMARC1; pct=100; rua=mailto:postmaster@kernel-error.de; ruf=mailto:postmaster@kernel-error.de; adkim=s; aspf=s; p=quarantine; sp=quarantine"

_dmarc. ==> ist halt der „Bezeichner“
kernel-error.de ==> japp die Domain
IN TXT ==> Internet und Text
„“ ==> Dazwischen ist der Text
; ==> Trennt die Optionen
v=DMARC1 ==> Protokollversion, hier also 1
pct=100 ==> 100% meiner vermeintlichen Nachrichten sollen gefiltert werden
rua=mailto:postmaster@kernel-error.de ==> Zusammenfassung geht an postmaster@kernel-error.de
ruf=… ==> der forensiche Bericht geht ebenfalls an den Postmaster
adkim=s ==> DKIM soll nicht relaxed (r) sondern strict (s) ausgewertet werden
aspf=s ==> auch strict
p=quarantine ==> Fehlgeschlagenes der Hauptdomäne sollen als SPAM markiert werden.
sp=quarantine ==> bei der Subdomäne auch.

Noch eine Kleinigkeit. Wenn man mehrere Domains betreut und die Berichte an eine zentrale E-Mail Adresse senden möchte dann muss man noch etwas beachten. Denn sollen die Berichte an eine E-Mail Adresse außerhalb der Domain des DMARC RECORDS gesendet werden, dann muss dieses in der Empfängerdomäne „erlaubt“ werden. Dieses geht über einen gesonderten TXT RECORD.

kernel-error.com._report._dmarc.kernel-error.de TXT "v=DMARC1"

Wenn man diesen RECORD als Beispiel nimmt, würde er in der Zone kernel-error.DE stehen. Damit würden die Berichte aus der Zone kernel-error.COM an die Adresse xyz@kernel-error.de zugestellt werden können.

Noch Fragen? Na dann fragen 😀


UPDATE 12.12.2013

Ok ok… da die Frage jetzt ein paar mal aufgekommen ist, wie ein solcher Report aussieht…. Hier ein Beispiel: >> klick <<

Zur besseren Ansicht kann ich auch hier nur wieder auf dmarcian.com verlinken. Hier gibt es einen XML du Human Konverter 🙂 

Frage beantwortet?

Mein Debian Keychain und einem geschenkten Gaul…

Einem geschenkten Gaul schaut man ja bekanntlich nicht ins Maul (man kann an den Zähnen das Alter vom Pferd recht gut schätzen). Inzwischen sind ein paar Keychains auf meinen „Hilferuf“ hin bei mir angekommen und ähm naja… Schaut mal selbst:

So wirklich was ich mir erhoffte ist noch nicht dabei. Ich gebe sie also gerne weiter 🙂 Wer eines haben will -MELDEN-!

Vielleicht findet sich ja noch ein passendes für mich? 

Version bei BIND nicht anzeigen lassen: Schritt-für-Schritt-Anleitung

Es gibt viele gute Gründe warum man die Version seines DNS Servers unkenntlich machen sollte. Viele Roboter und noch mehr Scriptkiddies suchen nach Versionen mit Sicherheitslöchern. Natürlich sollte man seine Version immer auf dem aktuellen Stand der Sicherheitsupdates halten… Denn noch kommt es vor dass man auch mal ein paar Tage auf einer „kaputten“ Version läuft. Dieses muss man ja nicht jedem unter die Nase reiben, hm?

Beim Bind ist es extrem einfach. Man reißt einfach mit dem Editor seiner Wahl die named.conf auf und wandert zum Options-Bereich. Dort ergänst man einfach die Option version:

options
{

[Zeugs und andere Optionen]
version "unknown";
[noch mehr Zeugs und andere Optionen]

};

Nun einfach Bind seine Konfiguration neu laden lassen:

$ rndc reconfig

Schon wird keine Version mehr angezeigt. Testen kann man alles wie immer mit dig:

$ dig -c CH -t txt version.bind +short @dns1.telekom.de
"SORRY"

Sorry finde ich gut liebe Telekom 🙂

Bock auf ein kleines Spiel? Wer mir zuerst sagt auf welchem Schiff mein primärer DNS Server stehen müsste, der bekommt eine Dose Dr Pepper Cola geschenkt.


Update 26.11.2013 19:53

Glückwunsch Dome, du bekommst die Dose. Bekomme ich ein Foto wie alles ausschaut nachdem DHL das Paket (oder besser Maxibrief *grübel*) bei dir abgegeben hat? Ich löse aber mal nicht, dann können die anderen noch mitspielen!

« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑