Juletip 23: bad bots, no cookie

Grmpf, når man lige tror man skal julehygge og prøve at tænke på andre i denne søde juletid - så bliver man belemret med slemme botter der drøner rundt i webserveren, selvom man har frabedt sig det.

Idag vil jeg udnytte at der er en del af jer der læser julekalenderen, tak for de mange gode input og kommentarer - såvel her som ude i den virkelige verden (IRC hvis du er i tvivl ;-) ).

Nå, dagens tip indeholder to dele - en del med to gode værktøjer som man bør kende og så en del med hvordan man kan forsøge at blokerer samme, eller andre der udfører det samme.

Wget og cURL

Disse værktøjer kan nogenlunde det samme, og jeg bruger begge. Wget er den jeg lærte at kende først, så typisk defaulter jeg til den, men cURL er ligeså yderst nyttig. Hvad kan de så?

Disse værktøjer kan fra kommandolinien hente data fra en webserver. Du angiver en URL og så henter programmerne data. Det kunne eksempelvis være sådan:

hlk@bigfoot:hlk$ wget www.kramse.org/robots.txt
--2008-12-23 09:03:29--  http://www.kramse.org/robots.txt
Løser www.kramse.org...91.102.91.17, 2001:16d8:ff00:12f::2
Connecting to www.kramse.org|91.102.91.17|:80... forbundet.
HTTP forespørgsel sendt, afventer svar... 200 OK
Længde: 53 [text/plain]
Saving to: `robots.txt'<br />100%[=============================================>] 53     --.-K/s   in 0s<br />2008-12-23 09:03:29 (2,66 MB/s) - `robots.txt' saved [53/53]
hlk@bigfoot:hlk$ cat robots.txt
User-agent: *
Disallow: /files/
Disallow: /pictures/

Nemt og smart. Specielt hvis man skal hente flere filer fra et website. Det gør man ved at specificere wget -r for rekursiv, og ofte begrænser jeg den til nogle få niveauer med level. Dvs wget -r -l 1 http://www.server.dk/ensidejegvilhente.html - så får man billeder og andre elementer fra den side med ned. Wget overholder som standard robots.txt som fortæller robotter hvad der må/ikke må indekseres.

Det fine ved wget er at den tillader meget fleksibel download programmatisk og de fleste downloads man skal bruge i dagligdagen. Den understøtter IPv4 og IPv6, tillader at man nedsætter hastigheden og så HTTP/HTTPS og FTP. Rart og nemt.

En anden god måde at bruge wget på er når man skal hente data, men kun dem som er ændrede - dvs mirroring. Det kan klares med option -m, eksempelvis: wget -m -r -l 1 http://www.server.dk/ensidejegvilhente.html, så slipper du for at overbelaste serveren ved at hente data du allerede har - be nice.

Det andet program er cURL der på hjemmesiden beskrives sådan:

curl is a command line tool for transferring files with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS and FILE. curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, kerberos…), file transfer resume, proxy tunneling and a busload of other useful tricks.

Hov, den kan vist en del mere end wget :-)

Så udover at cURL kan hente med de sædvanlige protokoller understøtter den vildt meget mere! Den kan endda bruge POST til at sende data til en webserver - supernice. Lad os lige prøve:

hlk@bigfoot:hlk$ curl www.kramse.org/robots.txt
User-agent: *
Disallow: /files/
Disallow: /pictures/

ohh, den smider bare data ud i hovedet på mig. Det var da lidt voldsomt, lad os lige sætte en option -o på for output:

hlk@bigfoot:hlk$ curl -o robots.txt www.kramse.org
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100  7547  100  7547    0     0   2784      0  0:00:02  0:00:02 --:--:--  4431

cURL kan også hente flere filer ligesom Wget, men se så dette eksempel fra man-siden: http://any.org/archive[1996-1999]/vol[1-4]/part{a,b,c}.html
Det eksempel henter alle URL’er med årstal 1996,1997,1998,1999 med volumenavne vol1, vol2, vol3, vol4, hvor der til hvert volume er en parta.html, partb.html og partc.html - dvs 4*4*3=48 GET fra en kommando!

Det er altså det basale, men derudover understøtter cURL diverse muligheder for at angive credentials, som cookies, NTLM auth, basic auth, digest auth, certifikater osv. Man kan endda pille ved Referer i det request der sendes, så man kan omgå naive beskyttelsesmekanismer.

Mon den så også kan andre sjove ting, ja da:

hlk@bigfoot:hlk$ curl -D header.txt http://www.kramse.org/robots.txt
User-agent: *
Disallow: /files/
Disallow: /pictures/
hlk@bigfoot:hlk$ cat header.txt
HTTP/1.1 200 OK
Date: Tue, 23 Dec 2008 08:23:35 GMT
Server: Apache
Last-Modified: Tue, 19 Aug 2008 09:11:42 GMT
ETag: "1119499-35-454cc79e5af80"
Accept-Ranges: bytes
Content-Length: 53
Content-Type: text/plain; charset=ISO-8859-1

Cool, vi får lige en header fra HTTP serveren - det lader til at min server bruger Apache - big surprise :-) Hvad med det website jeg legede med den anden dag, med relayd?

hlk@bigfoot:hlk$ curl -D header.txt -o temp.html http://portal.kramse.org/
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
198   198  198   198    0     0   4254      0 --:--:-- --:--:-- --:--:--     0
hlk@bigfoot:hlk$ cat header.txt
HTTP/1.1 301 Moved Permanently
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=CEFCEC93DCB79165214A75A92A5E3B6B; Path=/
Location: /c;jsessionid=CEFCEC93DCB79165214A75A92A5E3B6B
Connection: close
Content-Type: text/html
Content-Length: 198
Date: Tue, 23 Dec 2008 08:25:25 GMT

Ahh ja - det er en Tomcat, bagved relayd - Apache-Coyote = Apache Tomcat HTTP connector. Hmm, der var noget sjov med relayd.conf

Et lille tip her er fra Web Security Testing bogen som går ud på automatisk at følge redirects:

hlk@bigfoot:hlk$ curl -D header.txt -o temp.html -L -e ";auto" http://portal.kramse.org/
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100  8730  100  8730    0     0   6295      0  0:00:01  0:00:01 --:--:-- 1481k
hlk@bigfoot:hlk$ cat header.txt
HTTP/1.1 301 Moved Permanently
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=EBDEC233F220839FBDB28C0C5558F7C3; Path=/
Location: /c;jsessionid=EBDEC233F220839FBDB28C0C5558F7C3
Connection: close
Content-Type: text/html
Content-Length: 198
Date: Tue, 23 Dec 2008 08:31:21 GMT<br />HTTP/1.1 302 Moved Temporarily<br />Server: Apache-Coyote/1.1<br />Set-Cookie: GUEST_LANGUAGE_ID=en_US; Expires=Wed, 23-Dec-2009 08:31:21 GMT; Path=/<br />Set-Cookie: COOKIE_SUPPORT=true; Expires=Wed, 23-Dec-2009 08:31:21 GMT; Path=/<br />Location: http://portal.kramse.org/c/portal/layout;jsessionid=EBDEC233F220839FBDB28C0C5558F7C3<br />Content-Length: 0<br />Date: Tue, 23 Dec 2008 08:31:21 GMT<br />HTTP/1.1 302 Moved Temporarily<br />Server: Apache-Coyote/1.1<br />Set-Cookie: COOKIE_SUPPORT=true; Expires=Wed, 23-Dec-2009 08:31:21 GMT; Path=/<br />Location: http://portal.kramse.org/web/guest/home;jsessionid=EBDEC233F220839FBDB28C0C5558F7C3<br />Content-Type: text/html;charset=UTF-8<br />Content-Length: 0<br />Date: Tue, 23 Dec 2008 08:31:21 GMTHTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: COOKIE_SUPPORT=true; Expires=Wed, 23-Dec-2009 08:31:21 GMT; Path=/
Liferay-Portal: Liferay Portal 5.1.2 (Calvin / Build 5102 / October 3, 2008)
Content-Type: text/html;charset=UTF-8
Content-Length: 8730
Date: Tue, 23 Dec 2008 08:31:21 GMT

Hmm, jeg ved ikke om det er så fandens smart at der hver gang skal redirectes sådan, men ok - det er jo værre når man skal betale med kreditkort på internet idag med Verified by VISA (Very Fucked up by VISA?) - hvor man redirects og flyver rundt mellem en del sider og servere uden chance for at gennemskue om det er phishingsites eller PBS.

Hov glem ikke lige resultatet, nu fik jeg en version frem på det CMS jeg er begyndt at kigge på “Liferay Portal 5.1.2 (Calvin / Build 5102 / October 3, 2008)” det findes på http://www.liferay.com hvis nogen vil lege med det - ser ret nice ud og en enkelt af mine firmahjemmesider er lagt ind under det. Jeg anbefaler typisk at man fjerner den slags overflødig information - det vises ikke i browseren, browseren er ligeglad - så dt kan kun hjælpe en angriber => fjern det!

Nu kan cURL så også en anden smart ting, den kan ændre Agent - så lad os som den sidste ting i denne del prøve det, med -A User-Agent.

Først laver vi et request til HTTP med:

hlk@fluffy:hlk$ rm header.txt
hlk@fluffy:hlk$ curl -D header.txt -o temp.html -L -e ";auto" -k -A 'Bandia (blah blah blah Bandia blah 1.0)' http://portal.kramse.org/web/guest/home
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100  8730  100  8730    0     0    97k      0 --:--:-- --:--:-- --:--:-- 1510k
hlk@fluffy:hlk$ cat header.txt
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=FAC693EA2BBD4875CE1692FB4C337B5C; Path=/
Set-Cookie: GUEST_LANGUAGE_ID=en_US; Expires=Wed, 23-Dec-2009 08:46:45 GMT; Path=/
Set-Cookie: COOKIE_SUPPORT=true; Expires=Wed, 23-Dec-2009 08:46:45 GMT; Path=/
Liferay-Portal: Liferay Portal 5.1.2 (Calvin / Build 5102 / October 3, 2008)
Content-Type: text/html;charset=UTF-8
Content-Length: 8730
Date: Tue, 23 Dec 2008 08:46:45 GMT

Bemærk at jeg går direkte til http://portal.kramse.org/web/guest/home for at undgå redirects og det går fint. Lad os dernæst ændre til HTTPS og prøve igen:

hlk@fluffy:hlk$ rm header.txt
hlk@fluffy:hlk$ curl -D header.txt -o temp.html -L -e ";auto" -k -A 'Bandia (blah blah blah Bandia blah 1.0)' https://portal.kramse.org/web/guest/home
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
126   379    0   379    0     0   7295      0 --:--:-- --:--:-- --:--:--     0
hlk@fluffy:hlk$ cat header.txt
HTTP/1.x 403 Forbidden
Date: Tue Dec 23 09:48:56 2008
Server: OpenBSD relayd
Connection: close
Content-Type: text/html

Hov? Nu gik det ikke godt - og det er relayd der gør som den har fået besked på :-) I min relayd.conf står der nemlig at den skal blokere for bestemte User-Agents:

### Block bad or abusive User-Agents (case insensitive)
label "BAD user agent"
request header filter "Bandia*" from "User-Agent"
request header filter "TwoSands*" from "User-Agent"

Så fik vi lige vist at cURL kan ændre User-Agent og relayd kan blokere samme. Så User-Agent - eller alt andet der kommer fra brugeren, browseren, internet kan man altså ikke stole på! Så sørg for god sikkerrhed!

Anden del

Der er en bot der irriterer mig - ikke så meget fordi softwaren er dum, men dem der bestyrer botten har nægtet at opføre sig ordentligt.

Ja, jeg ved godt at ikke alle der er på internet opfører sig ordentligt, ej heller i den virkelige verden - men når man specifikt gør det til sin politik at overtræde god tone på internet - så er man en klaphat!

Lad os starte med at se et eksempel på nogen der gør det rigtige nemlig http://www.archive.org - de har indsamlet internet over lang tid og stiller det til rådighed for alle. Det betyder at man kan gå tlbage og se gamle hjemmesider:

• Min hjemmeside fra 2002 med denne adresse: http://web.archive.org/web/20021213115253/http://www.kramse.org/
• DSB fra 1997 http://web.archive.org/web/19971010040348/http://www.dsb.dk/
• DIKU http://web.archive.org/web/19971108221852/http://www.diku.dk/index.html

Åhh disse minder :-)

Nå, men archive.org har en politik for indsamling og fjernelse af data som er beskrevet på FAQ siden:

“How can I remove my site’s pages from the Wayback Machine?

The Internet Archive is not interested in preserving or offering access to Web sites or other Internet documents of persons who do not want their materials in the collection. By placing a simple robots.txt file on your Web server, you can exclude your site from being crawled as well as exclude any historical pages from the Wayback Machine.

Internet Archive uses the exclusion policy intended for use by both academic and non-academic digital repositories and archivists. See our exclusion policy.

Here are directions on how to automatically exclude your site. If you cannot place the robots.txt file, opt not to, or have further questions, email us at info at archive dot org. “

Helt rimeligt - hvem er det som ejer copyright, hvem er det som har lagt siden ud?

Ja, at fjerne information fra internet er som at pisse i en pool og prøve at fjerne det bagefter, men det kunne være man gerne ville fjerne det fra de åbenlyse steder.

Archive.org er gud!

Hvem er så satan? Det er det fscking danske netarkivet. Præcis snakker vi om http://netarkivet.dk/ som har fået til opgave at indsamle danske hjemmesider. Fair nok, det kan være interessant at se og forske i gamle data. Archive.org gør det, google gør det, mange andre gør det - be my guest, men overhold god takt og tone!

Nææææh nej, det gider vi ikke som netarkivet.dk - vi har ikke ressourcer til at se på robots.txt - nå så lad være, men lad så også være med at besøge mine sites, tak.

Det er simpelthen en principsag for mig at jeg ikke frivilligt vil lade netarkivet indsamle fra mine sider, før de overholder robots.txt. Specifikt drejer det sig om at følgende passus skal ændres fra http://netarkivet.dk/faq/index-da.php:

“3. Hvorfor ignorerer Netarkivets crawlere robots.txt?

På rigtig mange websites styrer robots.txt søgemaskinernes webcrawlere uden om materiale, som er helt nødvendigt for at kunne genskabe den oplevelse, man har som bruger af Internettet i 2006.

Erfaringerne viser at hvis vi indsamler med respekt for robots.txt går vi glip af store mængder vitale data - fx. avisernes websites - men også 10.000-vis af private websites som anses for væsentlige bidrag til den danske kulturarv.

Statistik fra juli 2005 viser at der under .dk-domænet findes mindst 35.000 robots.txt filer - netarkivet har ikke manuelle ressourcer til at tage stilling til disse en for en.

Efter helt samme principper har netarkivet muligheden for at tilsidesætte HTML-meta-tags”

Nåååå, skal I have en tudekiks! Fordi I ikke har ressourcer pisser I bevidst på andre? Det er sgu ikke iorden! (Ja, jeg er en sur gammel nisse hvis du var i tvivl)

Så vi ønsker altså at blokere en webspider som ikke overholder reglerne, men lad os derfor se på reglerne robots.txt, min siger fra kramse.org:

hlk@laura:sites$ cat kramse.org/robots.txt
User-agent: *
Disallow: /files/
Disallow: /pictures/

Dvs jeg beder botterne holde nallerne fra katalogerne /files/ og /pictures/ - jeg dropper diverse filer under /files/ og uanset det ikke direkte er hemmeligt så gider jeg ikke at det bliver indekseret og genfundet, med efterfølgende døde links hvis jeg rydder op. For min pictures mappe er det mere irriterende at folk linker til billeder uden kontekts og derfor (mis)bruger båndbredde hos mig. Jeg frabeder mig derfor at botterne går ind i disse to kataloger - er det for meget forlangt?

Når man støder på en bot der ikke overholder reglerne kan vi se på logfilerne og finde noget der kendetegner botten eller IP-adresserne den kommer fra. Undskyld de lange linier:

130.225.26.133 - - [23/Apr/2008:20:33:35 +0200] "GET /recommended/hardware.html HTTP/1.0" 200\
 9029 "http://www.kramse.org/" "Mozilla/5.0 (compatible; heritrix/1.12.1 +http://netarkivet.dk/website/info.html)"
130.225.26.133 - - [23/Apr/2008:20:33:51 +0200] "GET /life/bryllup/invitation.html HTTP/1.0" 200\
 8509 "http://www.kramse.org/" "Mozilla/5.0 (compatible; heritrix/1.12.1 +http://netarkivet.dk/website/info.html)"
130.225.26.133 - - [23/Apr/2008:20:34:09 +0200] "GET /projects/soekris/casemod_en.html HTTP/1.0" 200\
 7680 "http://www.kramse.org/" "Mozilla/5.0 (compatible; heritrix/1.12.1 +http://netarkivet.dk/website/info.html)"
130.225.26.133 - - [23/Apr/2008:20:34:20 +0200] "GET /projects/soekris/casemod/soekris-bluelight-1.jpg HTTP/1.0" 200\
 691465 "http://www.kramse.org/projects/soekris/casemod_en.html" "Mozilla/5.0 (compatible; heritrix/1.12.1 +http://netarkivet.dk/website/info.html)"
130.225.26.133 - - [23/Apr/2008:20:34:28 +0200] "GET /projects/soekris/casemod/soekris-blue-above.jpg HTTP/1.0" 200\
 344391 "http://www.kramse.org/projects/soekris/casemod_en.html" "Mozilla/5.0 (compatible; heritrix/1.12.1 +http://netarkivet.dk/website/info.html)"

Ahh, der er altså en User-Agent - starter med Mozilla og indeholder heritrix og noget med http://netarkivet.dk - godt, de skjuler sig i det mindste ikke! Det næste er så at finde alle IP-adresserne, og vi kan jo bruge netarkivet.dk som søgemønster:

#! /bin/sh
# find netarkivet i logs
PATH=/usr/bin:/bin

# iflg. http://netarchive.dk/faq/index-da.php
# kan netarkivets bot identificeres på:
# 
# 16. Hvordan kan jeg se, om min server er blevet besøgt af Netarkivets crawler?
#Vores crawler identificerer sig med en streng der indeholder en URL til en infoside:
#http://netarkivet.dk/website/info.html

LOGDIR=/.../apache2/logs

# print current block
echo "Det nuværende filter er:"
sudo grep netarkivet /etc/pf.conf

echo "Leder i logs efter netarkivets robot, vent venligst"
grep netarkivet.dk/website $LOGDIR/* > /tmp/netarkivet.txt

echo "De IP-adresser som er fundet er:"
cat /tmp/netarkivet.txt | cut -f 2 -d : | cut -f 1 -d '-' | sort -u 

Det giver en pæn lille række IP-adresser:

hlk@laura:hlk$ netarkiv         
Det nuværende filter er:
netarkivet="130.226.228.0/24 130.225.25.0/24 130.225.26.0/24 130.225.27.0/24"
table  { $netarkivet } 
Leder i logs efter netarkivets robot, vent venligst
De IP-adresser som er fundet er:
130.225.26.132 
130.225.26.133 
130.225.26.135 
130.225.26.136 
130.225.26.138 
130.226.228.72 
130.226.228.73 

Det næste skridt er så at blokere for den pågældende bot bedst muligt, eventuelt lægge en fælde i robots.txt så andre botter der ikke overholder spillereglerne opdages.

Da ovenstående oplysninger også er dokumenteret i FAQ for netarkivet har jeg valgt blot at blokere deres IP-adresser. Så kan de sgu købe julekalenderen, ligesom jeg må betale hvis jeg vil have Mikkel og Guldkortet på DVD ;-)

Hvis I vil gøre mig en tjeneste så tilføj dem til jeres firewall - jeg blokerer al trafik fra ovenstående netværksadresser på min webserver.

Generelt har du følgende muligheder:

• Bloker IP-adresser, hvis du kan finde dem - der findes svarende til e-mail blacklists også proxy lister og lister over hackede sites
• Bloker bestemte User-Agents, specielt hvis de fortæller hvor de kommer fra som netarkivet. Dette kan du gøre med relayd som ovenstående, mod_rewrite, mod_security eller tilsvarende på andre platforme

Hvis du skal være ekstra ond kunne du lave en sticky webserver/tarpit så deres robot går helt i stå når den rammer dit site. Alternativt kunne man smide tubgirl i hovedet på dem til deres diske løber fulde :-) Tubgirl er jo en vigtig ting, eller var det - måske de gerne vil have lidt two girls one cup at gemme i et par tusind kopier?

ohhh og btw - så lad da lige din cURL indeksere statsbiblioteket, bare fordi de har en robots.txt behøver du ikke overholde den :P

hlk@laura:hlk$ curl http://statsbiblioteket.dk/robots.txt
# /robots.txt for www.statsbiblioteket.dk
# Revised 2008-01-03 tgc
User-agent: *
Disallow: /search
Disallow: /e-tidsskrifter/e-tidsskrifter-pa-statsbiblioteket-og-aarhus-universitet
Disallow: /e-tidsskrifter/tidsskrifter-pa-statsbiblioteket-og-aarhus-universitet
Disallow: /databaser/databaseliste
# Webpacs here (autogenerated)
Disallow: /webpac2a
Disallow: /webpac3a
Disallow: /webpac4a
Disallow: /webpac5a
Disallow: /webpac-nba
Disallow: /webpac-aestet
Disallow: /webpac-djf
Disallow: /webpac-econ
Disallow: /webpac-geol
Disallow: /webpac-idraet
Disallow: /webpac-jur
Disallow: /webpac-kemi
Disallow: /webpac-moes
Disallow: /webpac-nobel
Disallow: /webpac-psy
Disallow: /webpac-ringg
Disallow: /webpac-teo

Hvis ovenstående vakte din interesse så se evt. mere på OWASP eller en af følgende ressourcer:

• Apache Security af Ivan Ristic
• Apache Cookbook af Rich Bowen, Ken Coar
  
• Relayd og relayd.conf fra OpenBSD
• Preventing Web Attacks with Apache
• Web Security Testing Cookbook, et helt lille kapitel med cURL

Vi ses imorgen til sidste indlæg, og det bliver ikke en stor finale - blot endnu et indlæg :-)