Sec, blogmal!
04 2006

Categories:

Everything

Juli '17

SoSoSoSoSoSoSo
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456

Archive:

Tue, 25 Apr 2006

Blog-Spam-B-Gone

Ich habe die Comments hier im Blog ja schon vor einiger Zeit auf moderated umgestellt, um der Spam-Problematik Herr zu werden.

Bei herkömmlichen CAPTCHAs (üblicherweise ja Buchstaben-Abtipp-Bildchen) hat mich immer gestört, daß die mit ein bisschen Aufwand eben doch von Programmen gelöst werden können, aber z.B. von Blinden nicht.

Es gibt noch ein paar andere nette Ideen (wie z.B. KittenAuth) die aber alle irgendwie Arbeit der Kommentierenden verlangt, und nochdazu eben nicht von allen Leuten erledigt werden kann.

Ich bin zu dem Schluss gekommen, daß ein einzelnes Blog zu 'klein' ist, um dafür eine extra Erkennung in einen Spambot einzubauen, und deshalb eigentlich eine noch so einfache (Text-)Aufgabe genügt. Gesagt, getan, seitdem gab es eine Box in die eine 42 einzutragen war.

Der Test verlief zwar nicht soo gut 100% Spam-Filter-rate, 0% false negatives - dafür leider 100% false positives. Nunja, es gab einen echten comment, und der (nein, ich nenne jetzt keine Namen :-) hat eben auch nix in die Box eingetragen. Nunja, ich zähle auf eure Lernfähigkeit…

Heute hab ich das Ding insofern scharfgeschaltet, als das mir spams jetzt auch nicht mehr per Mail vorgelegt werden, sondern einfach komplett rejected werden. Man bekommt jetzt dafür einen "Comment rejected"-Text.

Jetzt werden sich vielleicht die meisten von euch wundern, wo denn besagte Box ist? - Nunja, weil die Aufgabe so einfach zu lösen war, habe ich ein Stück Javascript eingebaut, das die 42 selbständig einträgt, und dann die Box versteckt. Bequemer gehts nun wirklich nicht.

Und wenn mir jetzt jemand sagt, Das geht aber nur solange gut, bis Spammer das javascript ausführen, dann sage ich, Ich wollte schon immer einen kostenlosen distributed-computing-cluster :->

– Sec


posted at: 16:22 | Category: /misc | permanent link to this entry | 3 comments (trackback)

Thu, 20 Apr 2006

Easterhegg 2006

Letztes Wochenende war ja bekanntlich Ostern und somit war es mal wieder Zeit für eine Easterhegg. Dieses Jahr sollte sie in Wien stattfinden, aus München diesmal also in durchaus akzeptabler Entfernung.

Diese Easterhegg war allerdings eher chaotisch. Angefangen damit, daß das Programm eher dürftig aussah, gab es auch noch eine last-Minute Änderung des Veranstaltungsorts (vom FLUC ins Metalab). Dies führte dazu, daß spontan 4 von 6 Leuten aus unserer Fahrgemeinschaft absprangen. Selbst ray und ich sind dann erst einen Tag später als geplant hingefahren. Vor Ort bekam man zu erst noch ein bisschen mehr von dem Chaos zu spüren (es gab keine Tassen mit Logo wie sonst üblich, und auch die Anmeldungsliste an der Kasse war nach Anmeldezeitpunkt und nicht nach Namen sortiert %-), aber das wars dann auch.

Abgesehen von diesen Problemchen war die diesjährige Hegg seht entspannt. Gut, lag vielleicht auch daran, daß ich nicht das Gefühl hatte irgendwas zu verpassen, aber irgendwie wars angenehm. Die restliche Orga (z.B. die Küche, das Frühstück und die Bereitstellung des Beamers für meinen Workshop) haben perfekt geklappt - und auch das (Ether-)Netz war stabil. (Das Wavelan konnte ich wegen Treiberproblemen unter BSD leider nicht testen :-/).

Weil es keinen Datenaustauschpunkt gab, habe ich mit meiner USB-Platte mal schnell einen lokalen ftp-Server aufgemacht und habe deshalb jetzt ca. 300 MB Easterhegg-Fotos hier rumliegen. (Wer Platz/Bandbreite hat, die zu publizieren, bitte melden!)

Mein eigener Vortrag zum Thema Perlgolf lief glaub ich ganz ok, die Zeit war dann doch ein bisschen arg knapp für den Ausprobier-Teil bei dem die Teilnehmer selbst programmieren sollten. Wenn gewünscht, kann ich dazu auch mal eine Zusammenfassung tippen und die Beispiel-Lösungen veröffentlichen. Ich hätte gerne noch ein paar mehr konkrete Beispiele und Optimierungen gebracht, andererseits hatte ich den Eindruck, daß einige Teilnehmer nicht so fit in Perl waren, das hätte vielleicht bloß noch mehr verwirrt.

Ansonsten hab ich mich bloß noch in den Regiotreff verirrt, wo es allerdings nicht viel neues gab, und in Data independent bonding, den Vortrag der locker den Preis des verwirrendsten Titels gewinnt.

2 Nächte im Hotel, 1 in der Location zu übernachten hat sich als recht brauchbar herausgestellt, ich bin doch deutlich besser drauf, wenn ich ausgeschlafen bin :)

Nach der Abschlußveranstaltung haben wir uns dann noch bei Sacher und Demel eingedeckt und sind dann relativ rasch wieder Richtung München abgedüst.

– Sec


posted at: 14:03 | Category: /misc | permanent link to this entry | 0 comments (trackback)

Fri, 14 Apr 2006

Linux ist borken

Wow. Also das Linux manchmal bizarr broken ist, ist ja eigentlich bekannt, aber heute habe ich eine ganz neue Dimension kennengelernt.

Es geht um eine Box mit einem physikalischen Interface und einem virtuellen (für OpenVPN). Das Ethernet hat IP 10.1.1.1/24, das OpenVPN-Interface 192.168.1.1/28. Nun hat Linux die bescheuerte Eigenschaft, auf jedem Interface ARP-Requests für alle IPs auf allen Interfaces zu beantworten. Was für ein Quark.

Im aktuellen Fall ist in dem Ethernet halt parallel noch ein zweites Netz mit einer Kiste auf 192.168.1.1 - Über den Sinn von zwei verschiedenen Netzen auf einem Ethernet kann man sich streiten, nur entzieht sich dieser Aspekt leider derzeit der Kontrolle (blöder ISP). Und da ist es natürlich eher kontraproduktiv, daß die Linux-Kiste unpassende ARPs verschickt.

Andere OSe (FreeBSD, *BSD, SunOS ...) machen es natürlich richtig, und schicken ARPs nur auf dem jeweils dazu passenden Interface raus.

Aber wartet, es kommt noch besser. :-)

Linux-Benutzer leben ja nicht hinter dem Mond, und drum ist das auch schon ein paar mal aufgefallen. In Google finden sich auch lauter Mails, besonders um 2003 rum, die das diskutieren. Fazit ist, daß TPTB das nicht ändern wollen und zwar weil, haltet euch fest:

  • Blocking ARP responses in this way is putting filtering decisions at the wrong layer of the networking code. This sort of action belongs at the netfilter level, rather than down at the device level.
  • Linux's approach to ARP responses is fully compliant with all applicable RFCs.
  • In some situations, responding out of all interfaces is the only way to successfully get communication established.
  • For situations where the default ARP behavior causes problems, the arp_filter sysctl knob can be used to change things.

Zusammengefasst also etwa: Unser Code ist scheiße, da kriegen wir das nicht sauber hin, es gibt auch Fälle da will man so ein kaputtes Verhalten, und außerdem erlaubt uns die RFC das. Achja, und arp_filter: Na gut, na gut, ihr habt so geschrieen, also haben wir es doch noch reingehackt.

Nur das arp_filter was ganz anderes tut, und komplett unbrauchbar ist. Es filtert eingehende ARP Anfragen. Kommt die Anfrage nach 192.168.1.1 auf dem Ethernet an und hat eine Source-IP von 192.168.1.2, wird sie nicht beantwortet, weil das Netz dazu ja auf das OpenVPN Interface geroutet wird. Kommt das Paket allerdings von 10.1.1.2, wird es beantwortet. Denn dann kommt es ja laut routing-Tabelle von der richtigen IP.

Häh? Was haben die denn da geraucht? Das hilft genau garnix. Nehmen wir an, die fremde Kiste mit der IP 192.168.1.1 hat als Netz ein /24 – Wir hatten (siehe oben) ja nur ein /28. Kommt die Anfrage nun von 192.168.1.250, beantworten wir sie plötzlich. Warum? Wir haben ja eine defaultroute auf dem Ethernet!

GnaGnaGnaGnaGna!

Und was freut man sich beim Googlen über all die Leute, die mit dem Verhalten auch ein Problem haben. Man findet FAQs zu dem Thema die dann auf lauter Patches verweisen, die es da dann brav für alle erdenklichen Kernelversionen gibt.

Hallo, ist euch das nicht peinlich?

– Sec


posted at: 18:38 | Category: /misc | permanent link to this entry | 2 comments (trackback)
<< older

powered by blosxom
in 0.00 s