[server] Flood attack vanaf een van mijn servers?

[B-Man]

Ik had zojuist iemand aan de telefoon van een bedrijf dat wat servers achter een corporate firewall heeft staan, en hij gaf aan dat er vanaf een van mijn servers een flood attach is uitgevoerd vanmorgen.

Eerste keer dat ik zoiets ten gehore krijg, maar goed. De betreffende server draait een aantal publieke services, en de rest is afgeschermd m.b.v. iptables.
Chkrootkit constateert niets geks, en ik zie verder ook niets geks op de machine (geen vreemde processen, logs zien er normaal uit, enz).

Wat is nu wijsheid qua stappenplan?

Het enige dat me opvalt is de volgende regel:

code:

lastlog | less

...
root     pts/1        82.94.65.49      Mon Aug 23 13:30 - 13:41  (00:11)
...

aangezien ik zelf vanaf twee vaste adressen inlog, en dit adres niet ken.

Mijn iptables chain ziet er als volgt uit:

code:

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:ftp state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:ssh state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:smtp state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:http state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:https state NEW,RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:pop3s state NEW,RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             reserved-multicast-range-NOT-delegated.example.com
ACCEPT     all  --  anywhere             anywhere           state RELATED,ESTABLISHED
drop-and-log-it  all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  unterland-online.de  anywhere
ACCEPT     all  --  anywhere             anywhere
drop-and-log-it  all  --  anywhere             anywhere

Chain drop-and-log-it (2 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere

Waarbij ik op dit moment de volgende versies draai:
- Apache/1.3.19 (2.x staat gepland voor installatie deze week, heb ik de afgelopen weken getest)
- sshd version OpenSSH_2.9p1
- ProFTPD Version 1.2.2rc2
- Exim version 3.36
- OpenSSL 0.9.6a

Voordat ik nu het systeem bijwerk, en alle software upgrade, lijkt het me verstandig om te achterhalen of er 'troep' op staat (trojans/...).

[blaataaps]

Je weet dat in ieder geval zo te zien je ssh-versie hopeloos achterloopt?
Overigens staat er in de onvolprezen nos-faq ook een kort stappenplan: FAQ Non-Windows Operating Systems - Overige vragen over wat te doen met een compromized systeem.

[ Voor 56% gewijzigd door blaataaps op 16-09-2004 11:34 ]

[Seth4Chaos]

kijk is in je auth.log file of je veel pogingen ziet van de root inloggen wat mislukt is (en blijkbaar 1 keer gelukt). Als jij zegt dat je maar vanaf 2 ip-adressen inlogt op die bakken en je ziet een adres dat je niet kent klinkt het als iemand die jouw password heeft.
Mijn advies:
- zorg dat je niet als root kan inloggen via ssh, dus dat je altijd een "su -" moet doen om root te worden.
- zorgt dmv iptables dat nieuwe connecties naar de ssh-port alleen vanaf die 2 adressen die bij jouw bekend zijn kunnen
- update sshd?
- verander je rootpassword?

[ Voor 4% gewijzigd door Seth4Chaos op 16-09-2004 11:35 ]

[B-Man]

blaataaps schreef op 16 september 2004 @ 11:30:
Je weet dat in ieder geval zo te zien je ssh-versie hopeloos achterloopt?
Overigens staat er in de onvolprezen nos-faq ook een kort stappenplan: FAQ Non-Windows Operating Systems - Overige vragen over wat te doen met een compromized systeem.

Scusi Ik zal eens in de FAQ kijken.

Ik heb inderdaad wat login pogingen (veel zonder, een met succes) gevonden:

code:

Aug 23 13:29:35 p15109251 sshd[1928]: Could not reverse map address 82.94.65.49.
Aug 23 13:29:55 p15109251 sshd[1928]: Failed password for ROOT from 82.94.65.49 port 3433 ssh2
Aug 23 13:30:07 p15109251 sshd[1928]: Failed password for ROOT from 82.94.65.49 port 3433 ssh2
Aug 23 13:30:07 p15109251 sshd[1928]: Failed none for ROOT from 82.94.65.49 port 3433 ssh2
Aug 23 13:30:14 p15109251 sshd[1928]: Accepted password for ROOT from 82.94.65.49 port 3433 ssh2
.. snip ..
Sep 14 07:42:55 p15109251 sshd[23408]: input_userauth_request: illegal user test
Sep 14 07:43:00 p15109251 sshd[23408]: Could not reverse map address 212.48.164.71.
Sep 14 07:43:00 p15109251 sshd[23408]: Failed password for illegal user test from 212.48.164.71 port 2338 ssh2
Sep 14 07:43:00 p15109251 sshd[23408]: Received disconnect from 212.48.164.71: 11: Bye Bye
Sep 14 07:43:00 p15109251 sshd[23409]: input_userauth_request: illegal user guest
Sep 14 07:43:05 p15109251 sshd[23409]: Could not reverse map address 212.48.164.71.
Sep 14 07:43:05 p15109251 sshd[23409]: Failed password for illegal user guest from 212.48.164.71 port 2469 ssh2
Sep 14 07:43:05 p15109251 sshd[23409]: Received disconnect from 212.48.164.71: 11: Bye Bye
Sep 14 07:43:05 p15109251 sshd[23413]: input_userauth_request: illegal user admin
Sep 14 07:43:10 p15109251 sshd[23413]: Could not reverse map address 212.48.164.71.
Sep 14 07:43:10 p15109251 sshd[23413]: Failed password for illegal user admin from 212.48.164.71 port 2632 ssh2
Sep 14 07:43:10 p15109251 sshd[23413]: Received disconnect from 212.48.164.71: 11: Bye Bye
Sep 14 07:43:10 p15109251 sshd[23414]: input_userauth_request: illegal user admin
Sep 14 07:43:15 p15109251 sshd[23414]: Could not reverse map address 212.48.164.71.
Sep 14 07:43:15 p15109251 sshd[23414]: Failed password for illegal user admin from 212.48.164.71 port 2772 ssh2
Sep 14 07:43:15 p15109251 sshd[23414]: Received disconnect from 212.48.164.71: 11: Bye Bye
Sep 14 07:43:15 p15109251 sshd[23415]: input_userauth_request: illegal user user
Sep 14 07:43:20 p15109251 sshd[23415]: Could not reverse map address 212.48.164.71.
Sep 14 07:43:20 p15109251 sshd[23415]: Failed password for illegal user user from 212.48.164.71 port 2917 ssh2
Sep 14 07:43:20 p15109251 sshd[23415]: Received disconnect from 212.48.164.71: 11: Bye Bye
Sep 14 07:43:26 p15109251 sshd[23416]: Could not reverse map address 212.48.164.71.
Sep 14 07:43:26 p15109251 sshd[23416]: Failed password for ROOT from 212.48.164.71 port 3051 ssh2
Sep 14 07:43:26 p15109251 sshd[23416]: Received disconnect from 212.48.164.71: 11: Bye Bye
Sep 14 07:43:31 p15109251 sshd[23417]: Could not reverse map address 212.48.164.71.
Sep 14 07:43:31 p15109251 sshd[23417]: Failed password for ROOT from 212.48.164.71 port 3168 ssh2
Sep 14 07:43:31 p15109251 sshd[23417]: Received disconnect from 212.48.164.71: 11: Bye Bye
Sep 14 07:43:36 p15109251 sshd[23418]: Could not reverse map address 212.48.164.71.
Sep 14 07:43:36 p15109251 sshd[23418]: Failed password for ROOT from 212.48.164.71 port 3298 ssh2
Sep 14 07:43:36 p15109251 sshd[23418]: Received disconnect from 212.48.164.71: 11: Bye Bye
Sep 14 07:43:36 p15109251 sshd[23419]: input_userauth_request: illegal user test
Sep 14 07:43:41 p15109251 sshd[23419]: Could not reverse map address 212.48.164.71.
Sep 14 07:43:41 p15109251 sshd[23419]: Failed password for illegal user test from 212.48.164.71 port 3433 ssh2
Sep 14 07:43:41 p15109251 sshd[23419]: Received disconnect from 212.48.164.71: 11: Bye Bye

waaruit ik afleid dat op 23 augustus een XS4all abonnee ingelogd is.
Dit verklaart echter nog niet hoe er vanmorgen een flood attack is uitgevoerd? Tenzij chkrootkit de geinstalleerde zut niet kan vinden...

Ik ga zometeen maar eens een paar nieuwe binaries bakken (openssh, apache, proftpd, exim), en op zoek naar een up-to-date pop3s server.

[Wilke]

Het lijkt mij ook interessant om te weten te komen hoe zeker diegene van het andere bedrijf (die jou belde) weet dat het van jou komt.

Het zou tenslotte kunnen zijn dat het lijkt alsof jij de afzender bent, maar dat de attacker gebruik maakt van source IP spoofing. Dan zou ik wel verwachten dat jij in je iptables log ook zooi kunt terugvinden die de servers van het bedrijf dat jou belde heeft achtergelaten, doordat in zo'n geval evt. reply-pakketten natuurlijk naar de verkeerde bestemming (jouw server dus) teruggaan i.p.v. naar de attacker. Maar ik zie in de rules hierboven niet dat je logging aan hebt staan (wel een rule die zo heet, maar het echte logging stukje zie ik niet staan) - klopt dat?


Niet dat ik uitsluit dat het systeem 'gepakt' is door een of andere cracker; er zijn zeker de nodige probleempjes geweest in Apache, OpenSSH en OpenSSL het afgelopen jaar....

[B-Man]

Seth4Chaos schreef op 16 september 2004 @ 11:35:
kijk is in je auth.log file of je veel pogingen ziet van de root inloggen wat mislukt is (en blijkbaar 1 keer gelukt). Als jij zegt dat je maar vanaf 2 ip-adressen inlogt op die bakken en je ziet een adres dat je niet kent klinkt het als iemand die jouw password heeft.
Mijn advies:
- zorg dat je niet als root kan inloggen via ssh, dus dat je altijd een "su -" moet doen om root te worden.
- zorgt dmv iptables dat nieuwe connecties naar de ssh-port alleen vanaf die 2 adressen die bij jouw bekend zijn kunnen
- update sshd?
- verander je rootpassword?

- geen root direct via SSH, check
- als ik een keer ergens anders zit, wil ik er bijkunnen, gebeurt bijna nooit, maar toch
- sshd ga ik zometeen bijwerken
- en natuurlijk een ander root password

Overigens wilde ik toch al een tijdje SSH met private key files proberen, is dit geen goede oplossing? Dan ben ik meteen van de passwords af over SSH.

-- Wilke:

source ip spoofing: daar dacht ik ook al aan.
Aangezien deze machine veel 'gescand' wordt, heb ik geruime tijd geleden de iptables logging uitgeschakeld, want om met de hand de logfiles door te spitten schoot niet echt op. In een situatie als deze had het uitsluitsel kunnen bieden, dus overweeg ik om het weer aan te zetten.

Overigens zijn mijn andere machines wel up-to-date qua software, dit is een wat ouder beestje dat overigens wel bovenaan mijn todo-lijst staat.

[ Voor 20% gewijzigd door B-Man op 16-09-2004 11:58 ]

[Wilke]

Wat betreft die 'random' SSH login attempts op niet-bestaande accounts enzo:

Toename ssh login attempts
[rml][ Linux] SSH wordt aangevallen. Virus?[/rml]

Maar: is deze login van jou?

Accepted password for ROOT from 82.94.65.49 port 3433 ssh2

Ik kan namelijk geen reverse DNS lookup doen op dat IP. Zegt op zich niet zoveel, maar als dat IP jou niet op een of andere manier bekend voorkomt, dan ben je dus screwed. Inderdaad is xs4all de netblock owner van dat IP.

Wel zeer slordig in dat geval, als de attacker z'n IP en alles gewoon in de logs heeft laten staan

Echter, het is geluk hebben als de attacker vanaf een xs4all account komt (kan natuurlijk ook een gehackte ADSL computer zijn bij xs4all btw..), want xs4all is goed met het afhandelen van die dingen

Dus als je hun die log laat zien kunnen ze wellicht opzoeken wie er achter zat. Zou het in ieder geval zeker eens opsturen naar hun abuse afdeling

[ Voor 26% gewijzigd door Wilke op 16-09-2004 12:02 ]

[r0b]

B-Man schreef op 16 september 2004 @ 11:26:
..

Het enige dat me opvalt is de volgende regel:

code:

lastlog | less

...
root     pts/1        [b]82.94.65.49[/b]      Mon Aug 23 13:30 - 13:41  (00:11)
...

aangezien ik zelf vanaf twee vaste adressen inlog, en dit adres niet ken.
..

&&

Wilke schreef op 16 september 2004 @ 11:59:
Wat betreft die 'random' SSH login attempts op niet-bestaande accounts enzo:

Toename ssh login attempts
[rml][ Linux] SSH wordt aangevallen. Virus?[/rml]

Maar: is deze login van jou?


Accepted password for ROOT from 82.94.65.49 port 3433 ssh2


Ik kan namelijk geen reverse DNS lookup doen op dat IP. Zegt op zich niet zoveel, maar als dat IP jou niet op een of andere manier bekend voorkomt, dan ben je dus screwed.

Wel op een zeer slordige manier in dat geval, als de attacker z'n IP en alles gewoon in de logs heeft laten staan

Dit IP adres lijkt dus niet aan TS toe te behoren, en kan dus in principe van desbetreffende 'hacker' zijn. Overigens krijg je deze meldingen ook niet in auth.log als iemand gebruikt zou maken van SIP spoofing.

[ Voor 7% gewijzigd door r0b op 16-09-2004 12:03 ]

[Wilke]

Okay, dan lijkt het me tijd om die bak van het internet te halen, en eens contact op te nemen met de xs4all abuse desk.

Stuur die log op, vooral MET datums en tijd erbij, en check ook of de servertijd goed loopt (vertel me /alsjeblieft/ dat er een NTPd op loopt - zo niet neem dan voordat je verder iets met die server doet op hoe ver de tijd 'verkeerd' loopt en schrijf dat er bij in de abuse mail). En vertel er bij wat er verder mee is gebeurd (flood attack op *naam-van-ander-bedrijf*). xs4all is niet blij met dat soort dingen, dus als het rechtstreeks van 1 van hun klanten gebeurt kun je er op rekenen dat ze er wel naar zullen kijken. Mits je het verhaal goed opschrijft natuurlijk, zodat ze er ook iets mee kunnen beginnen

[Wilke]

Of laat het lekker zitten (is al een maand geleden tenslotte, en verder weinig logs beschikbaar), reinstall gewoon die bak en zet er recentere versies op van sshd enzo.

[B-Man]

Wilke schreef op 16 september 2004 @ 12:07:
Okay, dan lijkt het me tijd om die bak van het internet te halen, en eens contact op te nemen met de xs4all abuse desk.

Stuur die log op, vooral MET datums en tijd erbij, en check ook of de servertijd goed loopt (vertel me /alsjeblieft/ dat er een NTPd op loopt - zo niet neem dan voordat je verder iets met die server doet op hoe ver de tijd 'verkeerd' loopt en schrijf dat er bij in de abuse mail). En vertel er bij wat er verder mee is gebeurd (flood attack op *naam-van-ander-bedrijf*). xs4all is niet blij met dat soort dingen, dus als het rechtstreeks van 1 van hun klanten gebeurt kun je er op rekenen dat ze er wel naar zullen kijken. Mits je het verhaal goed opschrijft natuurlijk, zodat ze er ook iets mee kunnen beginnen

De tijd loopt goed, draait al vanaf het begin NTPD. Het is een XS4aLL account.

Ik heb al een mailtje richting XS4all in de startblokken staan, die gaat zometeen de (spreekwoordelijke) deur uit.

Ik kan de server niet zomaar offline halen en opnieuw installeren, het betreft een dedicated machine die ik zelf beheer.
Ik ga sowieso nieuwe versies van alle services installeren en andere wachtwoorden instellen.
Ik zal zometeen eens iptables openzetten voor een andere machine, en dan eens met nmap kijken of er vreemde poorten openstaan. 'netstat -l' levert niets nieuws of vreemds op, op de machine zelf.

En zoals ik al aangaf, chkrootkit vind ook niets.

Ik begin het gevoel te krijgen dat er wel een ongeautoriseerde login was op 23 augustus, maar dat de flood attack van vanmorgen vanaf een andere machine kwam, met een gespoofed ip-adres. Anders zou ik toch ofwel:
- vreemde logins moeten vinden
- vreemde zombie services moeten hebben draaien, en
- dus vreemde poorten open hebben staan

Wat natuurlijk helemaal krom is, is dat er iemand op 23 augustus is ingelogd, die zijn IP niet gewist heeft, duidelijk (gelukkig...) geen expert.

Ok, tijd voor de nieuwe services.

[B-Man]

Update: de login, waarvan ik het IP niet herkende, blijkt een login door een collega te zijn vanaf een werkplek buiten ons kantoor. Ik heb het gecontroleerd, en het ip komt overeen.

[Seth4Chaos]

B-Man schreef op 16 september 2004 @ 11:55:
[...]

- geen root direct via SSH, check
- als ik een keer ergens anders zit, wil ik er bijkunnen, gebeurt bijna nooit, maar toch
- sshd ga ik zometeen bijwerken
- en natuurlijk een ander root password

Overigens wilde ik toch al een tijdje SSH met private key files proberen, is dit geen goede oplossing? Dan ben ik meteen van de passwords af over SSH.

Ik heb mijn servers zo ingericht dat root alleen "password-less" in kan loggen, dit betekend inderdaad dat die alleen met een prinvate-key kan inloggen (is voor scp tussen mijn verschillende servers). Alle overige gebruikers kunnen met zowel password als privatekey inloggen.
Het zou inderdaad een stuk veiliger zijn als alle gebruikers alleen met privatekey kunnen inloggen maar aangezien ik soms ook vanaf vrienden inlog heb ik niet altijd mijn privatekey bij me.

Overigens zijn mijn andere machines wel up-to-date qua software, dit is een wat ouder beestje dat overigens wel bovenaan mijn todo-lijst staat.

heb je nu een goede rede om het ook echt te gaan doen

[blaataaps]

B-Man schreef op 16 september 2004 @ 12:51:
[...]


Ik ga sowieso nieuwe versies van alle services installeren en andere wachtwoorden instellen.

Beter laat dan nooit zeggen ze wel eens, hoewel een reinstall van een hele machine vaak een beter idee is.

Ik zal zometeen eens iptables openzetten voor een andere machine, en dan eens met nmap kijken of er vreemde poorten openstaan. 'netstat -l' levert niets nieuws of vreemds op, op de machine zelf.

Je weet niet zeker of netstat veranderd is.

En zoals ik al aangaf, chkrootkit vind ook niets.

Dat die niks vindt is geen garantie dat er niks is.

Ik begin het gevoel te krijgen dat er wel een ongeautoriseerde login was op 23 augustus, maar dat de flood attack van vanmorgen vanaf een andere machine kwam, met een gespoofed ip-adres

Ik heb dat gevoel nog niet: als je betrouwbare logs krijgt (weet niet of je die gekregen hebt, geen idee hoe competent hun "corporate firewall" is) van een of andere attack, vanaf het ip van een doos met versies van services uit de steentijd, met ogenschijnlijk ongeautoriseerde root-logins denk ik niet "oh, zal wel een andere host zijn".

. Anders zou ik toch ofwel:
- vreemde logins moeten vinden

heb je gevonden, recentere kunnen eenvoudig gewist zijn, of niet gelogged

- vreemde zombie services moeten hebben draaien, en
- dus vreemde poorten open hebben staan

zijn allebei met een simpele rootkit te verbergen, zoals eerder aangegeven, en zoals de documentatie van chkrootkit zegt, dat chkrootkit niks vindt is geenszins een garantie dat er niets is.

Wat natuurlijk helemaal krom is, is dat er iemand op 23 augustus is ingelogd, die zijn IP niet gewist heeft, duidelijk (gelukkig...) geen expert.

Ok, tijd voor de nieuwe services.

dat is het al heel lang zo te zien, maar dat is inmiddels wel duidelijk genoeg gemaakt denk ik

[Kippenijzer]

B-Man schreef op 16 september 2004 @ 11:55:
[..]
- als ik een keer ergens anders zit, wil ik er bijkunnen, gebeurt bijna nooit, maar toch
[..]

Website waarop je in moet loggen, die daarna het remote ip uitlesst en dit in een file zet die door een cronjob iedere minuut gelezen wordt. Daarmee laat je dan een iptables rule toevoegen die 10 minuten actief blijft en NEW over ssh poort toestaat. ESTABLISHED over ssh sta je altijd toe -> gedurende die 10 minuten kun je ook van je random ip waar je op dat moment bent inloggen, en daarbuiten enkel van je vast ip's.

[B-Man]

blaataaps: ik volg je, maar maak me niet ongerust, omdat er
-a) geen vreemde poorten openstaan:

code:

Port       State       Service
21/tcp     open        ftp
22/tcp     open        ssh
25/tcp     open        smtp
80/tcp     open        http
110/tcp    open        pop-3
443/tcp    open        https
3306/tcp   open        mysql

(nmap -sS vanaf een andere machine, dit ip krijgt altijd ACCEPT van iptables)

-b) 'ls' en 'netstat' niet compromised lijken: alle essentiele commando's zijn gedateerd op hetzelfde moment in 2001: toen de server opgeleverd werd

-c) ik alle publieke services opnieuw compileer
-d) ik alle ssh-accounts nieuwe wachtwoorden geef

[ Voor 5% gewijzigd door B-Man op 16-09-2004 14:47 ]

[Buffy]

Kippenijzer schreef op 16 september 2004 @ 13:24:
[...]
Website waarop je in moet loggen, die daarna het remote ip uitlesst en dit in een file zet die door een cronjob iedere minuut gelezen wordt. Daarmee laat je dan een iptables rule toevoegen die 10 minuten actief blijft en NEW over ssh poort toestaat. ESTABLISHED over ssh sta je altijd toe -> gedurende die 10 minuten kun je ook van je random ip waar je op dat moment bent inloggen, en daarbuiten enkel van je vast ip's.

In de c't van deze maand staat een verhaaltje over portknocking waarbij je door een combinatie van porten aan te spreken toegang krijgt op een service port (bv ssh).

Nadeel is dat je overal de client (perl script) bij je moet hebben (en de port combinatie).

De meest simple oplossing is nog om de ssh services op een hogere port (> 40000) te zetten.

[B-Man]

Ik heb nu de nieuwe OpenSSH erop staan, en enkel root kan er in, en dan alleen maar met een private key.

Ook heb ik meteen de nieuwste versie van ProFTPd gepakt, en er de mod_tls module ingeladen, en de server zo ingesteld dat er ook alleen nog maar secure FTP verbindingen toegestaan zijn.

Dan resteert nog een install van apache2 (die staat al klaar), aangezien de MySQL en POP3 services enkel lokaal toegangkelijk zijn (afgeschermd door iptables).

[Verwijderd]

Hoe kan het bedrijf jou gebeld hebben? Zij kunnen toch niet je telefoonnummer achterhalen aan de hand van je IP-adres?

[B-Man]

Verwijderd schreef op 16 september 2004 @ 17:22:
Hoe kan het bedrijf jou gebeld hebben? Zij kunnen toch niet je telefoonnummer achterhalen aan de hand van je IP-adres?

De server draait HTTP services, en op de defaulthost is de bedrijfsnaam te vinden. Even de telefoongids erbij, en voila.

[NoBody]

ik weet niet of het wat toevoegt aan dit topic of enigszins van belang is;

$ host 212.48.164.71
71.164.48.212.in-addr.arpa domain name pointer spider7.sailory.com.

Dat is het IP welke geprobeerd heeft in te loggen onder verschillende accountnamen in je eerste logs... Lijkt dus één of andere spider te zijn

op sailory.com vind je weinig spider-achtige dingen terug (lijkt me één of andere search engine ah la google, maar dan met een specifiek doelgebied), maar zo'n spider gaat natuurlijk niet ssh flooden