A FLOSSzine magazin jóvoltából az október végi FSF.hu konferencia előadásai (közül több) kikerültek a http://videos.flosszine.org/ oldalra.

A zombi támadás ellen …. véd!

A te szűrőd tuti nem dolgozza fel a leveleket ~70 ms alatt.

Videók letöltése: ftp://ftp.fsn.hu/contrib/flosszine/szszk2k9_fsf.hu/

Idén ősszel, egészen pontosan most szombaton rendezi meg az FSF.hu Alapítvány a Szabad Szoftver Konferenciát a BME Informatikai Központban.

Több érdekes téma is lesz, pl. Google Android, Linuxos vékonykliensek, virtualizáció, Redis, Launchpad.net. És ha azt hitted, hogy az idén nem lesz szó spamszűrőkről, akkor 11:00-tól az EI215 teremben a helyed.

A clapf spamszűrő rekordot döntött nálam szeptemberben. 1506 spamet kaptam, és csak 1 csúszott át, de ami még ennél is jobb, hogy nem harapott a 2913 jó levél egyikére sem. Így hát a szeptemberi fals pozitív arány 0%, míg a spam felismerésé 99.93%. Az összesített pontosság pedig 99.97%. A te spamszűrőd képes erre?

Egy reverse proxy manapság nem probléma. Egy apró kellemetlen mellékhatása azonban van a dolognak: a reverse proxy mögött lévő web szerver nem a HTTP kérést elküldő kliens IP-címét látja, hanem a proxy IP-címét. Ez pedig gondot okozhat, ha egy site-ot pl. IP-címre kell lekorlátozni.

Szerencsére van egy mod_rpaf nevű Apache modul (1.3.x – 2.x.x), amely a következő trükköt tudja: Az “X-Forwarded-For:” HTTP fejlécben érkező címet kiexportálja a REMOTE_ADDR változóba. Így az Apache már a kliens valódi IP-címét látja, amikor pl. egy .htaccess fájl alapján kell eldönteni, hogy a kérést elfogadjuk vagy sem.

Ehhez Apache oldalon az alábbi konfigra van szükség:

LoadModule rpaf_module /usr/local/libexec/mod_rpaf-2.0.so

RPAFenable On
RPAFproxy_ips 127.0.0.1 1.2.3.4
RPAFsethostname On
RPAFheader X-Forwarded-For

Ezzel a nehezén túl is vagyunk, már csak egy olyan reverse proxyra van szükségünk, ami támogatja, ill. beleteszi a tovább passzolt kérésbe a X-Forwarded-For mezőt. Ha a dedikált reverse proxykat preferálod, akkor pl. a pound a te barátod, amely az alábbi konfiggal vígan elszalad:

User "pound"
Group "pound"

ListenHTTP
   Address 1.2.3.4
   Port 80

   Service
      BackEnd
          Address 127.0.0.1
          Port 80
      End
   End
End

Ha azonban komplex access control vagy egyéb fancy feature-ök is kellenek, akkor jobb választás lehet egy pehelysúlyú webszerver, mint pl. a lighttpd vagy az nginx, esetleg a cherokee.

Az előbbi elketyeg egy ilyesmi konfiggal:

server.modules              = (
                               "mod_status",
                               "mod_proxy",
                               "mod_simple_vhost")

server.errorlog             = "/var/log/lighttpd/error.log"

server.document-root = "/tmp"

server.port                = 80
server.bind                = "1.2.3.4"

server.username            = "lighttpd"
server.groupname           = "lighttpd"

proxy.server               = ( "" =>
                               ( "1.2.3.4" =>
                                 (
                                   "host" => "127.0.0.1",
                                   "port" => 80
                                 )
                               )
                             )

Ha pedig a backend webszerver nem Apache, hanem lighttpd, akkor az gyárilag kezelni tudja az X-Forwarded-For fejlécet.

A HUP egyik fórumán blackPanther OS SPAM címmel jelent meg egy blog, miszerint van egy hazai fejlesztésű projekt, a blackPanther OS, amely a Windows kiváltását tűzte ki célul. Ez eddig nagyon szimpatikus, csak egy baj van: ők is spammelnek.

Nem meglepő hát, hogy az említett blogban többen is kifejezték az ellenérzéseiket. Még szerencse, hogy jött egy ‘vector’ nevű illető, valószínűleg a blackPanther bennfenntese, és egy ilyesmi válasszal csapta arcon a panaszkodót:

Jónapot,

—– www.blackpanther.hu —–

Tehát egyrészt elismeri a spammelést, ami a levél fejléce alapján amúgy nyilvánvaló. Másrészt ahelyett, hogy feltenné a kezét, hogy “igen, fault-oltam”, és kezét tördelve sűrűn rebegné, hogy “bocsánat-bocsánat”, emberünk még neki áll feljebb, és elkezd pampogni, hogy ‘igen, spammeltünk, na és, közöd?’

Maga a spam így nézett ki:

Mikor jó nekem a blackPanther OS alternatív operációs rendszer?

Most egy tökéletes megoldást kínálunk a problémáikra!
[....]

Szóval jó ez a feketepárduc OS, és ha lehet, akkor én bizony inkább a hazait veszem meg, nem csak kolbászban. De csak a jó magyar munkásembereknek vagyok barátja, a spammereknek semmiképpen. Valaki leírta, hogy ez a spam “Sikeresen minuszba lokte a blackPanther OS eddig sem tul magasan levo reputaciojat nalam, koszonjuk, gratulalok.”

És ami a legjobban tetszett: a vector nevű fazon nagy fölényesen indít: külföldről jöttem, megyek is vissza, egyszóval nagyvilági legény vagyok. De addig még van 1 órám, vajon mit csináljak? Megmondom a frankót a hülyegyereknek. Most komolyan: kit érdekel, hogy egy spammer honnan jött, vagy hova megy?

Mondom, kár érte. Mert tetszett, hogy van egy Windows alternatíva, bár sosem használtam, és ez már így is marad. Kiváncsi vagyok, mi jön még ezután? A Microsoft is spammelni fog, hogy vegyem meg a Windows 7-et?

Minden projektnek kell egy logo. A clapf is egy projekt, így a graphx design jóvoltából nekem is lett egy logom, amely a jobb felső sarokban látható, ill. némi css túrás után sikerült betenni a clapf oldalára is.

Ma újra le kellett fordítanom az ucspi-tcp-t, de beleszaladtam az alábbi hibaüzenetbe:

/usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section .tbss mismatches non-TLS reference in tcpserver.o
/lib/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status

A megoldás egyszerű: szerkeszd az error.h fájlt, és ezt a diff-et hajtsd végre rajta:

-extern int errno;
+#include <errno.h>

Érdeklődve figyelem a dspam projekt sorsát, aminek több oka is van. A dspam egy enterprise-level statisztikai spamszűrő, amelyet Johnathan Zdziarski hozott létre, és számtalan helyen használják.

A dspam levelezőlistáját többek között azért is átlapozom időnként, hogy ihletet merítsek, milyen új feature-t kellene/lehetne még a clapfba építeni.

Időközben Zdziarski eladta a dspam projektet domainnel együtt a Sensory Networksnek (SN), akik pl. gyorsítókártyát is építenek. Az elején úgy tűnt, hogy minden szép, és minden jó, de idővel kiderült, hogy új dspam verziók nem nagyon jönnek ki, de akár úgy is fogalmazhattam volna, hogy a tranzakció óta egy sem.

Ez pedig elég nagy probléma, mert a felhasználói igények folyamatosan változnak, amit jó ha valamilyen szinten figyelembe vesz a/akármelyik projekt. Igen ám, de hiába is bátorította a népet az SN képviselője a népet, hogy ha jelentkezik egy elkötelezett fejlesztő, akkor ők támogatják. Senki nem állt ki a placcra, hogy én fejleszteni akarom a dspamet.

A levelezőlistán többen is megelégelték a Sensory Networks tehetetlenségét (vagy ha jobban tetszik, koncepciótlanságát), és létrehozták a DSPAM-COMMUNITY nevű projektet, ami a 3.8.0-ás verzióra épül, annak a forkja. Ez azért sem egy haszontalan lépés, mert az SN bejelentette, hogy szívesen eladnák a dspam portfolióját valakinek. Január végén ugyanis lekapcsolják a dspam dolgait hosztoló gépet, hacsak valaki nem jelentkezik, hogy átvenné a projektet.

Bár én egy konkurens spamszűrőben vagyok érdekelt, de szomorú lennék, ha a dspam eltűnne a süllyesztőben. Szerencsére a community projektnél máris van 6 fejlesztő. Kiváncsi vagyok, merre viszik tovább a dspamet…

Az utóbbi napokban nem új feature-ket adtam a spamszűrőhöz, hanem átdolgoztam néhány részletet. Arra kerestem ötletet, hogyan lehetne a MySQL lekérdezéseket gyorsítani. Eddig ugyanis azt a nem túl eredeti ötletet követtem, hogy a tokenek listáján végigmentem, majd elsütöttem egy selectet. 2k token esetén ezt 2k selectet eredményezett, ami azért – hiába gyors a MySQL – eltartott pár száz millisecundumig.

Mostmár azonban egy SELECT … WHERE token IN (…) jellegű SQL utasítást építek fel, és egy menetben kérdezem le az összes tokent. Ez 7-8x-os sebességnövekedést jelent, azaz a clapf ennyivel kevesebb ideig gondolkozik, hogy egy adott levél az ham vagy spam.

Összedobtam egy VMware virtuális masinát, és ráeresztettem 3159 levelet (2002 spam, 1157 ham levél) egy olyan felhasználóra, aki egy alias a /dev/null-ra. Az eddigi verziónak átlag ~800 ms-ba telt, amíg végzett egy levéllel, most azonban átlag ~110 ms alatt dönteni tudott egy levélről. A leveleket szekvenciálisan küldtem SMTP-vel a teszt gépre, ami nem jelenti azt, hogy a clapf egyszerre csak egy levéllel foglalkozott. A postfix ugyanis párhuzamosan, több levelet engedett a clapf spamszűrőre, amely így átlag 5 levél/sec teljesítményt ért el.

Ez nem tűnik túl soknak, de ez a teszt nem arra ment ki, hogy minél nagyobb áteresztőképességet érjek el (erre amúgy sem egy virtuális gép a legmegfelelőbb terep), hanem hogy növeljem a program teljesítményét. 800 ms helyett ~110 ms elég jó teljesítmény.

A korábbi postban említett cache démonról még nem mondtam le, majd visszatérek még rá. Eközben alapos módosításokat végeztem szinte minden .c és .h fájlban. A leggyakrabban használt függvényekben az adat struktúrákra mutatóval hivatkozom, ami még gyorsít egy kicsit, mert nem kell memóriaterület másolni.

Szóval ezek kerültek be a 0.4.0-rc2-be. Elvileg minden (eddigi) funkció rendben működik. Ha nem jön elő bug a következő hetekben, akkor jó lesz a végleges 0.4.0-nak is.

A clapf egyre inkább közelít az esedékes stabil verzióhoz, úgyhogy némi ráncfelvarrás ráfért már a dokumentációra is. Az új dizájn a http://clapf.acts.hu/new/ címen érhető el.

Nem csak a dizájn változott, de az utóbbi időben végzett fejlesztések és módosítások miatt a tartalom is frissült.