FUT: dk.edb.programmering
Dette er meget langt - men jeg tror faktisk det er ret interessant
ud fra mange forskellige indfaldsvinkler og jeg håber jeg forklare
mig selv tydeligt nok herunder!
Jeg har udviklet en frontend til SpamCop's webinterface, så jeg
ikke hele tiden skal sætte og/eller fjerne checkmærker, indsætte
tekst i textareas og aktivere submit- eller cancel-knappen i
deres webform - og det fungere faktisk skide godt, når man vil
rapportere over 500 spammails om dagen!!!
Men jeg har et "lille" problem med at overskue spammernes
"signature" samt gemme dem på en fornuftig måde. Lige nu er de
en del af koden, som bliver opdateret hver gang en ny spammer
dukker op eller en eksisterende spammer sender en spam med en
"signatur" jeg ikke har taget højde for. Det ville være smartere
at putte det i en database, men hvordan?
Det lyder vel som noget højtravende noget, så her er et eksempel:
Jeg har bedt SpamCop (
http://www.spamcop.net/) om at analysere
en spam og den kommer frem med dette resultat for dette site:
http://www.macromed.biz/ at følgende udbydere skulle have en
spamrapport: abuse at webrider.ru og abuse at rtcomm.ru.
http://www.spamcop.net/sc?
id=z572417122z26af4d6562cf764df243a0eaa79b8907z
Disse oplysninger aflæser mit program og hvis jeg allerede har
sendt en spamrapport på det site til de adresser "klikker" den
de checkboxe til og fra som jeg gjorde sidst og "trykker" på
submit spamrapports - medmindre jeg har bedt den om at lade
være - så "klikker" den på cancel og fortsætter med den næste
spam der venter i køen.
Som sagt er det hardkodet i programmet hvilket sites osv. den
skal genkende og det er de informationer jeg ønsker strukturet
på en måde så de kan gemmes i en database - uden at miste
overblikket.
Ovenstående er kodet således i mit (VB) program herunder -
næsten - denne del kan hoppes over medmindre min forklaring
efter "*** Slut på kodeforklaring ***" ikke er uddybende nok:
*** Start på kodeforklaring ***
Denne del af koden løbes igennem for hver enkelt abuseadresse:
'CheckIt atReportingType, long, Boolean, Boolean, Boolean, eCheck,
' sAbuseAddress, sAddress [, eCheckExt [, bRegExp [, bDublicates]]]
' For abuse departments
CheckIt atReportingType, lSpamCop, bMatch, True, True, eCheckCheck,
"abuse at webrider.ru", ' i koden er " at " skrevet som "@"
"http%3A%2F%2F
www.macromed.biz" ' HTML entities %3A = :, %2F = /
CheckIt atReportingType, lSpamCop, bMatch, True, True, eCheckCheck,
"abuse at webrider.ru",
"http%3A%2F%2F
www.macromed.biz%2Funs.htm"
' ...
' For third party interested in ...
CheckIt atReportingType, lSpamCop, bMatch, True, True, eCheckCheck,
"abuse at rtcomm.ru",
"http%3A%2F%2F
www.macromed.biz"
CheckIt atReportingType, lSpamCop, bMatch, True, True, eCheckCheck,
"abuse at rtcomm.ru",
"http%3A%2F%2F
www.macromed.biz%2Funs.htm"
Som oversat til menneskesprog lyder (bare så alle er med):
Kald funktionen CheckIt med:
- et array der indeholder alle de abuse adresser der henvises til i
den spam der nu bliver analyseret
- samt nummeret på den aktuelle abuse adresse der skal efterforskes.
- en boolean som sættes til sand, hvis der findes et match (denne
del skal udbygges til mere nyancerede værdier end sandt og falsk -
men det er en helt anden historie).
- Næste boolean afgører om det aktuelle kald af CheckIt skal
markeres som et match i arrayet.
- Næste boolean fortæller om det match der er fundet er unikt.
- Den næste parameter [er en enumerator som] fortæller om der skal
være et hak i checkboxen eller ej (og om der forventes at være et
hak i boxen eller ej i forvejen - bare for at dobbeltchecke).
- En af abuse adresserne på ...
- Adressen på det site/IP-adressen der bliver misbrugt
- Optional parameter der fortæller om andre skal have en spamrapport
a la: Forbrugerstyrelsen, spam@uce.gov og andre relevante parter
- Er adresserne skrevet som et regulært udtryk - forklaring følger
- og den sidste optionelle parameter - må flere CheckIt's godt matche?
*** Slut på kodeforklaring ***
Alle (både dem der er hoppet over ovenstående kodelinier og dem der
har forsøgt at finde hoved og hale i dem vil sige - "Hvorfor ***
laver han ikke bare en tabel med abuse-adresser og de relaterede
abused-adresser???" - ja det ville også være simpelt nok hvis ikke
spammerne lavede lidt om på deres URL'er og IP-adresser hele tiden!
Derfor er der (som de der har læst koden har set) mulighed for at
lave regulære udtryk. Jeg vil ikke begynde at forklare regulære
udtryk, men bare sige at de er meget stærkt værktøj - også i dette
system, for jeg kan samle alle abused-adresser i en linie i stedet
for at skrive hver enkelt i koden. Ovenstående kan samles til:
CheckIt atReportingType, lSpamCop, bMatch, True, True, eCheckCheck,
"abuse at webrider.ru",
"http%3A%2F%2F
www.macromed.biz(%2F(uns.htm)?)?", , True
Den vil match disse tre abused adresser:
http://www.macromed.biz/uns.htm
http://www.macromed.biz/
http://www.macromed.biz
(Ja jeg ved godt nogle af jer med det samme vil sige. "Hov, men
.. (dot) matcher alle bogstaver!", men det har været nemt for mig
at få programmet til at skrive ovenstående abused adresse om til:
"http%3A%2F%2Fwww\.macromed\.biz(%2F(uns\.htm)?)?" - OK!?!
)
Her er bare et par eksempler på hvilke udtryk der ligger i "basen"
"http%3A%2F%2F[a-z]+.mostlyyes.info%2F[a-z]+%2F[a-z]+%2Findex.htm"
som matcher alle spammails der henviser til "mostlyyes.info/nogle
bogstaver/nogle bogstaver/index.htm".
Når det går hedt til matcher jeg ikke på domænet længere!!!
"http%3A%2F%2F([a-z0-9(%7C)]+.)?[a-z0-9]+.com%2F(nomoremail%2F|
gen_ads%2Fgen_mail.php(%3Fgrid%3D[0-9]+%26ape%3D[a-z0-9]+)?)"
Her bruger jeg den sidste parameter, da jeg ikke kan overskue
om flere CheckIt statements finder et match - jeg er også ligeglad
det kommer fra en spammer uanset hvilket domænenavn der bruges!
Men her begynder filmen at knække! Jeg kan ikke altid huske
hvilket mønster en spammer bruger og ofte skifter de imellem
forskellige udbydere, så de gamle mønstre matcher ikke, osv.
osv!
Er der nogen der har forslag til hvordan jeg gemmer oplysningerne
i en database, så de er nemme og hurtige at søge i? I starten var
det min plan at bruge domænenavnene "bagfra (fra toplevel og ned)
men det blev ret uoverskueligt specielt da nogle spammere er ret
ligeglade med deres domænenavne - gud fri os fra den dag hvor
domænenavne bliver en gratis service!!!
Det skal også være nemt at se hvilke gamle mønstre evt. nye
mønstre matcher! osv. osv. osv!
Andrew
--
*** The opinions expressed are not necessarily those of my employer. ***
* Software Engineer Andrew Engels Rump * BLIK og ROERarbejderforbundet *
* Immerkaer 42, 2650 Hvidovre * Tlf: +45 3638 3638, Fax: +45 3638 3639 *
Home: N55°41'38.9" E12°29'08.6" (WGS 84) Work: N55°39'50.9" E12°27'47.4"
E-mail: mailto:newandrew@rump.dk WWW
http://www.rump.dk/homepage/andrew/