kein bergloewe fuer mein altes macbook

20130524_mounain_lion

🙁

d’mond

image

Share:

dns amplification (3)

passend zu meiner plage mit dns amplification (1,2) bzw dns allgemein findet sich aktuell bei heise material:

Bericht: DDoS-Service als legitimes Geschäft mit Segen des FBI
DNS-Attacken: Denic schließt das Kappen von DNS-Antwortraten nicht aus
A Common Operational Problem in DNS Servers – Failure To Respond.
RIPE: Angriffe auf das Domain Name System nehmen zu

Share:
Tagged

media upload verzeichnis aendern ab wordpress 3.5

ab wordpress 3.5 fehlt im backend die moeglichkeit, das upload verzeichnis zu aendern. diese funktion wurde entfernt, weil sie wenig genutzt, aber immer viel aerger eingebracht hat, wenn nutzer das im nachhinein aenderten.

wenn man das verzeichnis nun aendern will, muss man diese zeile in der wp-config.php einfuegen und natuerlich den eigenen gegebenheiten anpassen:

define( 'UPLOADS', 'wp-content/files' ); 

der default wert war frueher “wp-content/uploads”.

owncloud howto

luftballons, kleber, watte… so kriegt jeder seine cloud. die, die hier gelandet sind wegen der anderen owncloud… hier lang.

20130523_owncloud_howto

whatsapp spam

ah ja… nun auch spam bei whatsapp… natuerlich von einer nummer, die nicht im adressbuch ist.

20130522_whatsapp_spam

da ich von natur aus neugierig bin, hab ichs mal angeklickt. selbstverstaenlich nicht auf dem handy, sondern in einer vmware mit snapshot usw…

20130522_whatsapp_spam2

war ja klar. sex goes mobile… bitte “KOSTENLOSEN” erkennungsanruf starten. “Sie müssen dabei das Telefon nicht ans Ohr halten”… hm… ja … nee. mit sicherheit nicht.

microsoft spam?

also mal ganz ehrlich… da hat sich microsoft viel muehe gegeben, die email wie spam aussehen zu lassen. die spammer und phisher kriegen es mittlerweile besser hin, dass ihr spam wie eine echte mail aussieht.

20130522_ms_spam

ja, die email ist “echt”. ich habe tatsaechlich was bei denen bestellt. mal so kurz zusammen gefasst, was mir an der mail suspekt erscheint und/oder microsoft besser machen kann:

  1. der absender ist nicht microsoft, sondern bertelsmann
  2. der absendende mailserver (im header ..servicemail24.de) gehoert der arvato systems GmbH. fuer laien kein zusammenhang zu microsoft oder bertelsmann erkennbar
  3. die anrede fehlt
  4. keinerlei referenznummer (nur ihr “juengster” kauf)
  5. “bitte keine antwort”. das kann man im jahre 2013 anders loesen
  6. kontaktieren sie bitte “irgendwen”, den sie sich auf irgendeiner webseite aussuchen koennen
  7. was bitte ist mpn? (ja, “microsoft partner network”. aber warum kann man das nicht hinschreiben?)
  8. die rechnung kam erst viele tage nach der bestellung
  9. mit freundlichen gruessen, “microsoft”. wieso so unpersoenlich? und der absender ist doch bertelsmann…
  10. keine signatur (ist das nicht sogar pflicht bei geschaeftlichen mails?)
  11. es ist ein anhang an der mail, den man sich garnicht traut zu oeffnen bei dieser komischen email. wird ja immer gepredigt.. “bloss nicht die anhaenge oeffnen, wenn die die email suspekt vorkommt”

wenn ich mal genauer drueber nachdenke, finde ich bestimmt noch ein paar sachen 😉
schlimm, dass microsoft und bertelsmann das heutzutage nicht besser koennen. leistet euch doch mal nen praktikanten, der das ordentlich fuer euch macht. oder gilt im gegensatz zu spam und phishing mails bei echten mails mittlerweile das motto “die sieht so stuemperhaft aus, die muss echt sein”?

dns amplification (2)

den kram von gestern wollte ich noch ein wenig verfeinern. im logfile des bind konnte ich auf einen blick erkennen, dass diese beiden die groesste menge der (mittlerweile “sinnlosen”) abfragen darstellt:

[...] query: deniedstresser.com IN ANY +E
[...] query: . IN RRSIG +E

um nur genau diese per iptables raus zu filtern, muss man erstmal im netzwerkverkehr mithorchen, um sich dann die genauen strings rauszusuchen. das macht man am einfachsten mit dem tool tcpdump, welches anders als der name vermuten laesst auch udp und icmp mitschneiden kann 😉

tcpdump -i eth0 -s 0 -w /tmp/tcpdump.dump udp port 53

die damit erzeugte datei schaut man sich am besten mit wireshark an und sucht sich die entsprechenden teile der pakete raus:

20130521_iptables_string2

20130521_iptables_string1

die relevanten (im screenshot markierten) teile, nach denen ich filtern wollte, sind dann in hexadezimaler schreibweise diese:

# hex fuer "deniedstresser.com: type ANY, class IN"
0e 64 65 6e 69 65 64 73 74 72 65 73 73 65 72 03 63 6f 6d 00 00 ff 00 01 00
# hex fuer ": type RRSIG, class IN"
00 00 2E 00 01 00 00 29

die abfrage des typs ANY kann ich bedenkenlos komplett rausfiltern, da ich den abgefragten namen (deniedstresser.com) mit reingenommen habe. niemals hat dieser dns server genau diese abfrage zu beantworten.

iptables -I INPUT 1 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 30 --algo bm --hex-string '|0e 64 65 6e 69 65 64 73 74 72 65 73 73 65 72 03 63 6f 6d 00 00 ff 00 01 00|' -j DROP

die abfrage nach der “recource record signature” der root zone darf ich nicht komplett rausfilter, da dem dns server vertrauete ipadressen sehr wohl genau diese abfrage machen koennen und duerfen. dafuer ist diese loesung mit iptables eigentlich eher ungeeignet. aber da ich weiss, dass die server mit den “vertrauten” ipadressen noch nichts mit DNSSEC am hut haben, nutze ich die regel erstens nur temporaer und zweitens sicherheitshalber nur wenn “geflutet” wird – sprich mehr als vier abfragen pro minuten von einer ipadresse kommt.

erst wieder die ip “taggen”:

iptables -I INPUT 2 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 35 --algo bm --hex-string '|00 00 2E 00 01 00 00 29|' -m recent --name dnsrootrrsig --set

und die anfrage wegschmeissen, wenn der counter in 60 sekunden die vier erreicht hat, :

iptables -I INPUT 3 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 35 --algo bm --hex-string '|00 00 2E 00 01 00 00 29|' -m recent --name dnsrootrrsig --rcheck --seconds 60 --hitcount 4 -j DROP

klar muessen die “angreifer” nur eine kleinigkeit an einer der abfragen aendern, um diese regeln zu umgehen. aber so schickt der dns server wenigstens nicht mal das “REFUSED” an den gefaelschten absender zurueck. ich hoffe ja, dass dieser “angriff” irgendwann vorueber ist, da der bind sowieso kein offener resolver mehr ist und somit fuer die angreifer uninteressant wird.

wordpress plugin wp-syntax und zeilenumbruch

ACHTUNG UPDATE: mist… funktioniert wohl doch nicht so toll… siehe UPDATE unten!!

das plugin wp-syntax ist ganz nett, um code jeglicher art in wordpress darzustellen. jeder, der mal versucht hat, z.b. html code zu posten, wird das plugin zu schaetzen wissen. und je nach sprache machts das per syntaxhighlighting auch noch buntig. standardmaessig macht das teil aber keinen zeilenumruch, was theoretisch nicht schlimm waere. allerdings koennen manche browser diesen horizontalen scrollbalken nicht anzeigen:

20130521_wpsyntax1

wenn der scrollbalkenfehlt, sieht man ggf. informationen nicht. abhilfe schafft das editieren des stylesheets (datei wp-syntax/css/wp-syntax.css) des plugins. aus diesem eintrag:

white-space          : pre !important;

einfach diesen machen:

white-space          : pre-wrap !important;

…und schon sieht man wieder alles was man sehen will:

20130521_wpsyntax2

dank angabe der zeilennummer sollten die leser es auch kapieren, dass das eine zeile sein soll 😉

############
!!! UPDATE !!!
############

tschja.. schade… das funktioniert woh nur schoen, wenn man eine zeile hat. bei zwei zeilen steht die nummerierung an der falschen stelle. der erste befahl sollte eigentlich ueber drei zeilen gehen:

20130521_wpsyntax3

muss ich mich doch mal auf die suche nach einem anderen plugin machen… vielleicht weiss ja ein hier mitlesender html-css-junkie eine loesung und hinterlaesst diese nettweise in den kommentaren? 😉

dns amplification und pfingsten

der nameserver eines kunden war versehentlich noch offen fuer anfragen aus aller welt und wurde fuer ddos attacken missbraucht. er kriegt eine kleine anfrage rein und schickt eine grosse antwort an die gefaelschte absende ip raus. dieses “verfahren” ist auch als “dns amplification” bekannt.

um eine gute amplification attacke zu machen, braucht es zwei dinge. das protokoll sollte keinen handshake benoetigen, damit man die absendeadresse faelschen kann. also entweder icmp oder udp um die (gefaelschte abfrage nach dem motto “fire and forget” los zu jagen. und dann sollte natuerlich die antwort um ein vielfaches groesser sein als die abfrage selber.

in dem mir vorliegenden falle wurde z.b. eine abfrage vom typ “ANY” auf die domain “deniedstresser.com” gemacht. so schaut das ganze dann aus: (das x.x.x.x repraesentiert den “offenen resolver”)

dig ANY deniedstresser.com @x.x.x.x

20130520_dnsddosdie antwort habe ich als verkleinertes bild (klick zum vergroessern) eingefuegt und auch noch etwas gekuerzt, weils einfach noch viel mehr ist. aufgrund der etwas ausgefallenen antwort vermute ich mal, dass diese domain genau fuer diesen einen zweck uebrhaupt existiert.

solche anfragen kamenzwischen 10 und 50 stueck pro sekunde von unterschiedlichen ipadressen (die gefaelschten natuerlich), wobei ungefaehr immer 10 die gleiche absende ip hatten. die menge ist nichts, womit ein einzelner dns server mit bind nicht fertig wuerde. aber da es wahrscheinlich noch hunderttausende offene dns resolver gibt, koennen die angreifer damit wunderbare attacken fahren.

aber wie wird man diese dinger nach dem beseitigen des problems wieder los? selbst wenn man den dns server so konfiguriert, dass er diese rekursiven anfragen nicht mehr aufloest, sendet er immerhin noch ein “REFUSED” mit ein bischen overhaed drumherum zurueck. das ist dann immernoch eine ddos attacke, aber wenigstens ohne nennenswerte “amplification”.

ein einfaches blocken per iptables ist auch nicht das wahre, denn:
die gefaelschten ips des absenders sind halt einfach gefaelscht. man blockt also jemanden, der eigentlich garnichts dafuer kann, sondern das opfer ist. den traffic auf der leitung mindert das etwas, da die antworten nicht mehr raus geschickt werden. beobachtungen haben aber gezeigt, dass sofort neue ipadressen als absender erschienen, sobald man welche geblockt hat.

beim suchen bin ich auf eine loesung gestossen, die in meinem falle erst einmal ausreichend ist. dabei wird mit iptables in das paket “reingeschaut”.

die erste regel schaut in die udp pakete an port 53, ob darin eine dns any anfrage steckt und setzt fuer die ip einen tag “dnsanyquery”:

iptables -I INPUT 1 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|' -m recent --name dnsanyquery --set

die zweite regel prueft, ob die erste regel noch weitere vier mal in der letzten minute angewandt wurde. wenn ja, dann wird die anfrage weggeworfen:

iptables -I INPUT 2 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|' -m recent --name dnsanyquery --rcheck --seconds 60 --hitcount 5 -j DROP

mit diesen regel funktionieren “normale” dns any abfragen weiterhin und alle anderen abfragen bleiben davon sowieso unberuehrt. da die absender ips ohnehin gefaelscht sind, wird auch niemand “unnoetig” ausgesperrt.

leider bekommen die “angreifer” nicht mit, dass der dns server kein offener resolver mehr ist und feuern steandig weiter. so habe ich naemlich gerade eben den naechsten mist im logfile gefunden, der sich im sekundentakt vermehrt:

20-May-2013 22:43:08.459 client 69.140.111.56#27203: view external: query: . IN RRSIG +E

na toll.. da wird als “amplification packet” der “signature resource record” der root zone abgefragt. *seufz* …darum kuemmere ich mich aber heute nicht mehr.

und was hat das ganze nun mit pfingsten zu tun? nix.. war halt nur heute passiert und so musste ich mich wenigestens nicht ueber das wetter aufregen, weil ich einen guten teil des tages vor der kiste gesessen habe 😉