Il bot Eggdrop ha alcuni potenziali punti
deboli che possono essere utilizzati se non si difende il proprio bot
accuratamente.
Di seguito ci sono alcuni suggerimenti per rendere il proprio Eggdrop
più sicuro.
Disabilitare l'opzione learn-user
Permettere agli utenti di aggiungersi da soli al bot può essere conveniente,
ma finche è permesso a ciascuno di aggiungersi da solo non c'è molta sicurezza
(specialmente se gli utenti ottengono accesso alla party line quando si
presentano al bot). L'ultima cosa si vuole, è trovare qualcuno che abbia
floddato di messaggi il proprio bot e abbia aggiunto 1000 nuovi utenti.
Bisognerebbe considerare l'opportunità di disabilitare l'opzione learn-user
e aggiungere manualmente gli utenti al bot usando i comandi .adduser
e .+user
Se davvero si vuol permettere agli utenti di presentarsi da soli al bot
bisognerebbe cambiare il comando con qualcosa di diverso da 'hello'.
Scegliere gli owners accuratamente
Stare molto attenti a dare lo stato global owner (+n) sul bot.
Si dovrebbe considerare di non dare a nessun utente lo stato +n, altrimenti
assicurarsi di darlo a gente che conosciuta su IRC da molto tempo e di
cui ci si possa fidare.
Lo status di owner permette ad un utente di fare praticamente qualunque
cosa col bot- l'ultima cosa di cui si ha bisogno è che un utente +n traditore
usi il bot per scopi illeciti facendo cacciare il legittimo proprietario
fuori dalla shell.
Sicurezza delle password
Non usare una password facilmente individuabile - fare una combinazione
casuale di lettere maiuscole e minuscole e numeri, o due parole combinate
con un numero - qualcosa che non sia una parola reale.
Stare attenti anche quando si mandaun messaggio al bot contenente la password
(x es msg botnick op
Cambiare o disabilitare i comandi ident
e addhost
E' una buona idea cambiare i comandi 'ident' e 'addhost' per far riconoscere
al bot una nuova hostmask.Cambiare questi comandi con qualcosa di diverso
(come spiegato nella guida al Setup).
Per una miglior sicurezza disabilitare questi comandi senza cambiarli,
sebbene questo richieda master e owner per aggiungere manualmente un nuovo
hosts per gli utenti.
Usare hostmask precise
Se il proprio hostname è, per esempio cool@modem36.ppp.yourisp.net, Eggdrop
trasformerà la hostmask in *!cool@*.yourisp.net. Se si è
un owner o un master del bot, è importante limitare ulteriormente l'accesso
facendo hostmasks ancora più specifiche- x es *!cool@*.ppp.yourisp.net
o probabilmente *!cool@modem*.ppp.yourisp.net.
Abilitare protect-telnet
Per default chiunque può fare un telnet albot e tentare di individuare
la password di un utente durante il prompt di registrazione. Usando protect-telnet
sarà permesso di restringere l'accesso a utenti particolari. Per dare
accesso telnet ad un utente quando protect-telnet è abilitato, bisogna
aggiungere una speciale hostmask telnet alla registrazione dell'utente
nel formato telnet!*@their.hostname.com. Esempio- se la hostmask dell'utente
è *!cool@*.dudes.net, si deve aggiungere telnet!*@*.dudes.net
alla lista delle sue hostmask.
Questo permette al dominio *.dudes.net di fare un telnet al bot e provare
a registrarsi come utente. Nota che per default Eggdrop da all'owner la
hostmask telnet!*@* hostmask. Assicurarsi di rimuovere questa hostmask
e fanne una più precisa (x es telnet!*@*.ppp.yourisp.net).
Disabilitare i comandi tcl, set e binds
Usando i comandi DCC .tcl e . set, hiunque con lo stato di global owner
sul bot può accedere alla shell attraverso il bot. Ovviamente questa è
una brutta cosa, perciò è consigliabile che questi comandi siano
slegati nel file di configurazione. Il comando .binds in alcuni casi può
essere usato per fare danno, dovrebbe essere disabilitato se utilizzato.
Disabilitare il comando chanset
Un difetto dell'Eggdrop nelle versioni precedenti alla 1.3.25 permetteva
agli utenti di utlizzare il comando .chanset per far compiere al
bot qualunque funzione.
Bisognerebbe disabilitare il comando chanset o aggiornare la versione
1.3.25 o precedenti e assicurarsi che must-be-owner sia abilitato.
Abilitare must be owner
Questa caratteristica è presente nel 1.3.24 e successive.Permette solo
ai permanent owner (come impostato nei settaggi 'owner' del file
di configurazione) di usare i comandi .tcl e .set (se abilitati). Nella
1.3.25 e seguenti è anche aumentata la sicurezza del comando chanset,
e nella 1.3.26 si può settare must-be-owner a 2 per permettere
solamente ai permanent owner di usare il comando .dump.
Usare private-user
Se si ha una botnet con i bot che condividono i file utente, bisognerebbe
considerare la possibilità di usare l'opzione private-user. Ciò
può aumentare significativamente la sicurezza del bot, ma tutti i cambiamenti
dell'utente (aggiungere un utente, ident/host, cambiamenti di password
e flags) devono essere fatti dal bot hub. Considera che solo la versione
1.3.27 e successive hanno un private-user regolarmente funzionante- questo
non è a disposizione nelle versioni precedenti- perciò se si vuol trarre
vantaggio dal private-user il bot hub deve essere l'1.3.27 o successivo.
Tenere d'occhio le cose
Quando si èonline, bisognerebbe tener aperta una sessione di chat
in DCC con il bot e sedersi alla console.
Assicurarsi i che siano abilitati i modi console m, b, s, c, o, e x (scrivere
.console +mcobxs), così è possibile vedere qualsiasi cosa
succede sul bot. Si potrebbe voler togliere le flag di console j e k se
queste creano disordine, oppure anche che il bot invii per mail il log
del giorno precedente, che permetta di vedere tutta l'attività che si
è svolta sul bot.
Per far ciò bisogna che aggiungere una linea al crontab (se non si sa
come fare leggere quella sezione della guida alle
impostazioni per un esempio).
Se si vuole che il bot invii il log del giorno precedente alle 5:30am,
inserire la riga
30 5 * * * mail your@email.address.com < /home/username/botdir/botlog.log.yesterday
Sostituire l'indirizzo e-mail e il percorso per il log del bot con i propri.
Usare una buona protezione flood
Molta gente crede che gli Eggdrop siano a prova di proiettile, ma la realtà
è che, di default, sono abbastanza vulnerabili ai basilari tipi di flood.
Punti deboli come flood CTCP, flood a valanga, e utenti con username finti
sono stati corretti nelle versioni 1.3 più nuove- ma bisogna usare i settaggi
giusti.
La versione 1.3.21 e successive hanno la funzione kick-bogus che
dovrebbe essere impostata su 0 per prevenire kick flood da username fittizi,
mentre le versioni 1.3.24 e successive hanno la flag kick-fun che
dovrebbe essere impostata a 0 per eliminare la vulnerabilità al flood
a valanga.
Le versioni 1.3.26 e successive hanno l'opzione ctcp-mode che si
dovrebbe impostare a 2, usando un settaggio appropriato global-flood-ctcp
come quello di default 5:30.
Per maggior protezione contro i flood, dovresti considerare l'opportunità
di usare uno script antiflood come sentinel.tcl,
combinato come un limitatore di utenti nel canale tipo chanlimit.tcl.
Attacchi DoS
Gli attacchi Denial of Service sono diretti alla shell su cui è il bot.
Come ogni attacco è un flood di qualunque genere che causi alla shell
un forte rallantamento ed eventualmente il bot potrebbe essere disconnesso
da IRC.
Sfortunatamente c'è poco da fare per proteggere il bot da un serio attacco
DoS, dipende dall'abilità della shell di resistere ad ogni attacco.
Scegliere una shell con un'ampia banda di connessione e un buon firewall
può aiutare ad evitare che gli attacchi meno seri abbiano qualche effetto
significativo sul bot, ma ci sono poche shell che sono totalmente invulnerabili.
Gli attacchi DoS, come il più noto attacco 'smurf', sono il motivo principale
per cui molti canali IRC hanno un gran numero di bot su shell diverse
per aiutare a proteggere il canale dal takeover che è il risultato di
un attacco di questo tipo.
Sicurezza della shell
Dal momento che il numero di nuovi buchi nella sicurezza è apparentemente
infinito e gli exploit appaiono nei componenti di vario gusto di Linux
e FreeBSD e i servizi che sono usciti su di loro, la shell box Unix di
uno fornitore commerciale di shell è sempre sotto alto rischio di essere
'hackata'.
Dal momento che la natura 'pubblica' di un account di una shel commerciale-virtualmente
chiunque con poche migliaia di lire o col numero di carta di credito di
qualcun altro può ottenere un account, e ci può essere poca cura da parte
degli utenti che danno la propria password di accont a hacker malevoli-può
accadere che poche uova marce su un sistema tentino di compromettere la
sicurezza della shell e guadagnare il controllo di tutti gli account.
In alcuni casi la shell può anche venir messa in pericolo dall'esterno
da un utente senza account.
Se ciò accade l'utente può ottenere anche il controllo dell'Eggdrop (ed
eventualmente di tutti i bot della botnet, dipende da comesono stati settati)
e controllare tutti i canali su cui risiede l'Eggdrop. Sfortunatamente,
una volta che la shell è 'hackata' c'è poco che puoi fare per salvare
il proprio bot e i propri canali.
Le shell private sono meno vulnerabili dagli hackers, ma a meno che si
abbiano amici con lapropria shell box non si ha altra soluzione che usare
un fornitore di shell commerciale.
Perciò quando si scegle un fornitore di shell ci si assicuri di sceglierne
uno con una buona reputazione in fatto di sicurezza e metodi di controllo.
Un errore comune è quello di pensare che se il bot che viene hackato è
un bot leaf, si possa stare tranquilli finchè il bot hub sovrascrive lo
userfile del bot leaf.
In realtà l'utente può ancora controllare il bot leaf e, se si sta usando
l'opzione tipica di condivisione, l'utente può ottenere il controllo di
tutti i bot condivisi sulla botnet.
Inoltre, se i comandi .tcl, .set, or .chanset sono stati abilitati su
questi bot, l'utente può accedere a tutte le shell attraverso i bot e
fare grossi guai.
Usare private-user può essere utile ad impedire che una botnet venga danneggiata
in questo modo.
- - -