Tag: software

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:

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:

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:

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? 😉

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

die 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 😉

buuwhahahaha… die belustigung des tages auf heise: “Chaos im Stromnetz durch verirrte Zählerabfrage”

“Der Kreislauf aus Anfragen und Antworten überforderte schließlich das System, woraufhin die zentrale Steuerung des europäischen Stromnetzes nicht mehr zu erreichen war. Das läuft ab wie bei einer DDos-Attacke. Allerdings seien in diesem Fall keine Hacker am Werk gewesen, wie der Geschäftsführer von E-Control, Walter Boltz, dem ORF versicherte. Bei den gesendeten Daten handelte es sich nicht etwa um “sinnlose Anfragen”, sondern um “normale Messdaten”. Eine Attacke von außen sei daher unwahrscheinlich. Allerdings könnten theoretisch Insider, also Mitarbeiter in den Steuerungssystemen, solche Datenfluten auslösen. Wahrscheinlicher sei aber ein simpler Softwarefehler.”

soso… die haben also mitarbeiter, die nur “simple softwarefehler” produzieren und aufgrund ihrer dummheit kein boesartiges potenzial entwickeln koennen. ist die erkenntnis, dass die meisten angriffe auf unternehmen von innen kommen, veraltet?

in diesem sinne… schoenen (und hoffentlich sonnigen) sonntag noch!

das duerften wohl nur die betroffenen verstehen. ich fands lustig und muss es hier mal festhalten 😉

vorgestern hat sich mein imac sowas aehnliches wie “aufgehaengt”. ein paar sachen gingen einfch nicht mehr. nuja.. auch nen mac muss man ab und zu mal neu starten. bloss von alleine wollte er das nicht mehr machen. blieb mir nix anderes uebrig, als den netzstecker zu ziehen. danach lief scheinbar wieder alles. aber nur scheinbar… heute hab ich gemerkt, dass kein ton mehr rauskommt. ein blick in die einstellungen verriet nix gutes:

“es wurden keine ausgabegeraete gefunden”… weg isses… das ausgabegeraet. diverse tipps aus allen moeglichen foren blieben erfolglos (kopfhoerer mehrfach reinstecken, falls die buchse was hat; in der library die dateien fuers audio loeschen und neu starten; flash dingsbums reset beim starten, kein rotes licht aus der klinken-kombi-buchse vorhanden, usw. usf.) …scheinbar ist das ding kaputt. bleibt mir noch die neuinstallation zu machen und zu hoffen. ob garantie, muss ich erst noch abchecken. die gedanken kreisen gleich um alternativen: nen neuen kaufen? quark.. doch nicht weil die soundausgabe nicht geht. eine externe soundkarte mit usb dranstecken? dann brauchts auch externe lautsprecher, weil man die internen nicht nutzen kann und der halbwegs “cleane” schreibtisch wird wieder mit kabelsalat zugemuellt. heieiei… erstmal muss ich die rechnung rauskramen und dann mal schauen.

hat vielleicht noch irgender nen heissen tip fuer mich?

wordpress legt beim upload von bildern automatisch bis zu drei verschiedene groessen (thumbnail, medium, large und originalgroesse) dieses bildes ab.

da ich beim posten von bildern diese (meistens) sowieso schon passend zuschneide, gibt es so ganz viel “bildermuell”. abhilfe schafft diese einstellung unter “settings” -> “media” -> einfach die groessen, die man nicht automatisch generiert haben will, auf 0 setzen.

um den in der vergangenheit entstandenen muell zu entsorgen, kann man plugins wie z.b. “Upload Janitor” oder “WP Media Cleaner” benutzen. der Upload Janitor wollte bei mir aber partout das tar binary nicht finden und ohne backup die dateien zu loeschen, war mir zu riskant. der WP Media Cleaner haette zwar funktioniert, stellte aber die zu loeschenden dateien “paginated” auf 115 seiten dar. das war mir dann ehrlich gesagt zuviel klickerei. erschweren kam noch hinzu, dass ich eine worpress installation fuer drei blogs benutze und diese tools das natuerlich nicht schnallen, da die blogs unterschiedliche datenbanken benutzen.
ich haette zwar ca 70 mb plattenplatz sparen koennen, aber… drauf geschissen… “spare” ich halt nur in zukunft.

als ergaenzung zu einem vergangenen posting zu den brute force attacken auf wordpress installationen noch ein hinweis. es reicht nicht, das /wp-admin/ verzeichnis per .htaccess datei zu schuetzen. ueberhalb dieses verzeichnisses liegt naemlich noch die datei wp-login.php, welche zum login benutzt werden kann. auch eine einzelne datei kann man mit benutzername und passwort schuetzen. das geht wie folgt:

# wp-admin verzeichnis schuetzen

  AuthType Basic
  AuthName "Restricted Area"
  AuthUserFile /path/to/htpasswdfile....
  require valid-user


# wp-login.php schuetzen

  AuthType Basic
  AuthName "Restricted Area"
  AuthUserFile /path/to/htpasswdfile....
  require valid-user

diesen code an die eigenen begebenheiten anpassen, copy&paste in die bereits vorhandene .htaccess datei im wordpress root und gut.

es geht auch etwas kuerzer und ohne redundante eintraege:

AuthType Basic
AuthName "Restricted Area"
AuthUserFile /path/to/htpasswdfile....

# wp-admin verzeichnis schuetzen

  require valid-user


# wp-login.php schuetzen

  require valid-user

kam mir heute beim rumspielen unter… ich wollte eine java runtime deinstallieren, was aufgrund dieser meldung fehl schlug:

wie? der symantec virenscanner nutzt java? ein kleiner check hat das bestaetigt.

da falle ich ja fast vom glauben ab. die neben dem flashplayer am meisten mit “securityproblemen” behaftete software “java” wird von einer virenscanner enginge benutzt? das muss doch frueher oder spaeter in die hose gehen… nuja… den hackern wuensche ich happy hacking 😉

wenn man mit mehreren leuten urlaub macht, passiert es ja immer wieder, dass datum und uhrzeit der kameras nicht eingestellt bzw synchron sind. mit dem commandline programm exiftool kann man komfortabel z.b. die exifdaten der bilder in einem ganzen verzeichnis aendern:

exiftool "-DateTimeOriginal+=0:0:0 5:55:0" urlaub/

damit z.b. wird der timestamp der bilderstellung um 5 stunden und 55 minuten nach vorne (+) verschoben.
bei einpaar bildern kam es bei mir zu fehlermeldungen dieser art:

Warning: [minor] Possibly incorrect maker notes offsets (fix by 46?) - urlaub/DSC01342.JPG
Error: [minor] Bad MakerNotes directory - urlaub/DSC01342.JPG

woher diese genau kommen, weiss ich nicht. auf jeden fall bekommt man sie mit dem schalter -m oder -ignoreMinorErrors unterdrueckt, so dass die dateien trotzdem abgespeichert werden. (Ignore minor errors and warnings)

Warning: Deleted bad MakerNotes directory - _mariosonja/DSC01342.JPG

kuerzlich musste ich ein joomla auf einen anderen webserver umziehen. danach ging zwar noch die startseite, aber alle unterseiten hatten falsche pfade zu den bildern und stylesheets gehabt. es war immer ein “index.php/” zuviel in der url. so stand da nicht…:

…sondern:

und wenn man nach diesem phaenomen sucht, findet man in komischen foren komische kommentare und komische loesungsvorschlaege von komischen leuten zu diesem komischen cms. (ueberfluessig zu erwaehnen, dass ich foren noch nie leiden konnte, oder?) igendwo inmitten dieser komischen suchergebnisse bin ich den bugtracker auf joomlacode.org gestolpert, wo einer ganz unscheinbar diesen kommentar mittenrein geschrieben hat:

THat error is 99% of the time caused by not haveing the $live_site variable set in your configuration.

that’s it. das war “mein” problem.
(allerdings kenne ich noch immer nicht die ursache… weil auf dem einen server hats funktioniert und auf dem anderen nicht..)