Joomla.it Forum
Non solo Joomla... => Sicurezza => : mau_develop 10 Feb 2010, 16:19:12
-
Cerco volontari! :)
Ho scritto un plugin che limita il login all'area amministrativa secondo specifiche direttive da impostare come parametro.
Avrei bisogno di un sacchetto di critiche, diciamo che ci sono cose che forse sono obsolete e altre che forse mancano.
Devo decidere se fare qualcosa di più semplice e bona lì oppure se può essere un valido aiuto all'admin joomla.
Ovviamente è destinato a persone consapevoli :) , non installatelo se non riuscite a capirne il senso, vi si pianta tutto e non vi loggate più.
grazie
M.
ps: il file di log va copiato manualmente nella cartella /log
[allegato vecchio più di un anno eliminato automaticamente]
-
sembra interessante!! :D
ora ci smanetto un pò, poi ti farò qualche critica.. ;D
-
siate impietosi :)
no, scherzi a parte, difficilmente pubblico ciò che scrivo perchè lo faccio soprattutto per me, quindi sono sempre io il mio giudice...
a proposito, due cosine... nel file php ci sono ancora due righe di debug, proprio all'inizio, due print che mi servono per avere un controllo visuale di ciò che succede.
la funzione che vi allerta via mail ha dentro la mia mail come sender... mettete la vostra ovviamente.
ip e dns autorizzati, se più d'uno vanno a capo, ne a fianco, ne separati da virgole etc.
per i dns basta il nome, quindi es. tiscali, scrivetelo come viene ricevuto perchè è grezzo e quindi non c'è un controllo maiuscole minuscole, è case sensitive .... poi do' di finitura
M.
EDIT[23.13 10-2]
... stavo pensando... se vedete gli script mancherebbe una cosina.. è controllato il flood nella sessione ma non è legato all'ip,... errore! E' più facile che avvenga la seconda della prima. Bisognerà implementare entrambi.
Però l'ip a qs punto non lo posso tenere nella sessione, dovrò ricorrere per forza al db... e quì mi son venuti i primi dubbi...
impressionato dalla quantità di query di joomla ero felice quando pensavo di aver risolto tutto con la sessione, ma anche la sessione, gliel'ho printata... madonna quanta roba!
a questo punto occorrono pareri... meglio sessione o db? ... entrambi con moderazione?
M.
-
sto provando il plugin,
mi chiedevo se si può utilizzare per nascondere un sito e lasciarlo aprire solo da altri siti nei loro wrapper
a prima vista parrebbe di si, ma sinceramente non ho capito cosa devo inserire li dove vedo dns?
per gli ip credo di si, però io anche avendo un ip fisso non sono mai riuscito ad utilizzare ad esempio in htaccess allow all denied ecc.. perchè non mi riconosce poi il mio ip...
-
mi chiedevo se si può utilizzare per nascondere un sito e lasciarlo aprire solo da altri siti nei loro wrapper
-----------------------------------------------------
mmhh ho dei dubbi
a prima vista parrebbe di si, ma sinceramente non ho capito cosa devo inserire li dove vedo dns?
----------------------------------
avendo un ip fisso non sono mai riuscito ad utilizzare ad esempio in htaccess allow all denied ecc.. perchè non mi riconosce poi il mio ip...
-----------------------------------------------------------------
allora, siccome parliamo di area admin, si presume che solo tu o un paio di altri collaboratori vi abbiano accesso.
abilitare il controllo ip implica autorizzare la visita agli ip che inserirai, ognuno su una riga.
Ovvio che bisogna avere un ip fisso.
Nel caso in cui non lo si abbia allora il controllo è un po' più largo, si abilita il solo controllo dei dns, si inserisce nel campo: tiscali pittosto che fastweb e potranno accedere solo i provenienti da quel dns.
IN LOCALE BISOGNA CONTROLLARE CON UN PRINT che ip avete e che dns avete (credo nessuno), ip ... localhost, ::1, 127.0.0.1
Comunque generalmente ogni controllo è da abilitare prima di essere parametrizzato.
Il flood determina quanto tempo tu ritieni debba trascorrere tra la consultazione di una pag e un'altra.
Inserire 1 vuol dire che se tra una request e l'altra trascorre meno di un secondo è flood.
Dopo 3 tentativi errati c'è il sistema di autoban del quale puoi configurarne il tempo di "allontanamento"
se qualcosa non dovesse funzionare, disabilitalo.
Sono proprio queste cose che mi servono di capire oltre all'efficienza, e cioè se risulta di facile impiego, crea problemi, risponde alle aspettative, si installa tutto a dovere, le descrizioni sono efficaci o ingannevoli...
cmq, credo che razionalizzato sia un'ottima sentinella per il ns sito.
-
però io anche avendo un ip fisso non sono mai riuscito ad utilizzare ad esempio in htaccess allow all denied ecc.. perchè non mi riconosce poi il mio ip...
ciao francesco,
prova con
<Directory /var/www/etcetera>
Order deny,allow
Deny from all
Allow from ip1[/maschera] [ip2[/maschera]]
</Directory>
la directory è ovviamente la parte del sito che devi proteggere (anche la root), questo ti garantisco che funziona ;)
ciao,
marco
-
:-[ :-[
mi vergogno a dire che io il plugin non ho ancora trovato il tempo di installarlo (anche perché tipicamente ciò che fa il plugin io lo faccio con il firewall); ma ho guardato il codice e debbo dire che è scritto molto bene.
è sicuramente utile a tutti coloro che hanno il loro sito in hosting presso terzi, senza la possibilità di accedere al server: insomma può servire al 99% degli utenti joomla.
ciao,
marco
-
non trovo l'emoticons che da i baci.....
:):):)
magari mi puoi dare un suggerimento su una cosina...
questo plugin interviene sull onAuthentication, però alcune funzionalità farebbero comodo anche al lato pubblico al momento dell'accesso al sito, come ad esempio il controllo sui bannati il flood etc.
...devo per forza fare 2 plugin e dividere o duplicare, in alcuni casi, i metodi?
L'altro dovrebbe intervenire su onAfterInitialise();
..posso usare un trigger?
M.
-
ciao francesco,
prova con
<Directory /var/www/etcetera>
Order deny,allow
Deny from all
Allow from ip1[/maschera] [ip2[/maschera]]
</Directory>
la directory è ovviamente la parte del sito che devi proteggere (anche la root), questo ti garantisco che funziona ;)
ciao,
marco
si provato, anche se più semplice
ma non mi riconosce così l'ho modificato in
Order deny,allow
Deny from all
e ne ho fatto un file htaccess.txt nella cartella administrator
io lo chiamo lucchetto
così in certi periodi lo rinomino in .htaccess (metto il lucchetto) e chi si è visto si è visto..
;)
-
ciao francesco, scusa la domanda scema...
ma sei sicuro di uscire sempre con il medesimo ip, non è che il router seleziona un ip dal pool disponibile?
prova ad creare un file ip.php e ad inserire questo contenuto:
<?php
echo $_SERVER['REMOTE_ADDR'];
?>
poi aggiorna la pagina più volte chiudendo il browser...
fammi sapere.
ciao,
marco
-
ma sei sicuro di uscire sempre con il medesimo ip, non è che il router seleziona un ip dal pool disponibile?
paghiamo per un ip e nel forum ad esempio vedo sempre lo stesso ip..
però non mi riconosce, misteri dei servizi adsl?
su certe estensioni ad esempio risulta che entro da latina pur essendo molto lontano da li, distretto di pescara almeno una volta..
ci ho rinunciato, del resto il lucchetto funziona e non è che tutti i giorni si entra in amministrazione..
-
Azz! Mi pero perso questa discussione! ;D ;D
Ho scaricato il plugin e domani lo provo (adesso ho letto troppi post sul forum e mi girano abbastanza ;D)
Sul mio sito sto usando il plugin di jsecure. Credo che, in linea di principio, l'uso del tuo plugin possa affincarsi all'uso di jsecure.
Intanto lo provo in locale ;)
Personalmente il controllo sugli ip per l'accesso al backend lo trovo difficoltoso per chi, come me, usa un ip dinamico.
Magari si potrebbero abilitare range di ip visto che ogni isp ha i suoi.
difficilmente pubblico ciò che scrivo perchè lo faccio soprattutto per me, quindi sono sempre io il mio giudice...
Male! molto male! ;D Bisogna sottoporsi alla pubblica gogna se si vuole migliorare ;D ;D
Soprattutto se non rendi pubblico quello che crei.
Io eviterei di usare un trigger. Se ti poni il problema dell'elevato numero di query sul db mettere un trigger potrebbe avere lo stesso effetto? E' una domanda perchè non so come vuoi creare il trigger.
Usare il plugin anche lato frontend? Da valutare perchè il rischio è sempre quello di bannare troppo o troppo poco. Ci si deve studiare su.
Ciao
-
ciao maurizio,
questo plugin interviene sull onAuthentication, però alcune funzionalità farebbero comodo anche al lato pubblico
i plugin di tipo authentication agiscono su ogni operazione di autenticazione del framework di joomla, quindi tanto a lato be quanto a fe.
il problema è, in realtà, quello di salvare i dati già analizzati... in php standard esiste una memorizzazione a livello session, ma non a livello application.
ovvero vi è un accesso ai dati risultanti da ciò che viene fatto a livello di singolo collegamento browser, tracciato con i cookies, ma non a livello di application server.
penso che l'unica sia loggare i dati in un db e fare sì che il plugin faccia un lookup sulla tabella per verificare i dati raccolti.
a te stabilire un tracciato record efficace e soprattutto efficiente.
ciao,
marco
-
Magari si potrebbero abilitare range di ip visto che ogni isp ha i suoi.
il problema è i provider grandi hanno così tanti ip che non sarebbe più utile come sistema di protezione...
Io eviterei di usare un trigger. Se ti poni il problema dell'elevato numero di query sul db mettere un trigger potrebbe avere lo stesso effetto? E' una domanda perchè non so come vuoi creare il trigger.
non ho capito: stai parlando di trigger sul db? noi parlavamo della pattern observer/observable del modello di plugin di joomla...
ciao,
marco
-
Intanto lo provo in locale
-----------------------------
...assolutamente! qualche casting in più poi lo aggiungo...
il trigger l'ho nominato perchè molti dei metodi usati in quel plugin mi servirebbero in un altro plugin che sta in system, atto invece ad altri controlli poichè prevede un uso diverso del sito.
... ho erroneamente parlato di lato pubblico perchè intendevo che serviva per gli accessi da frontend.
chessò il metodo per rilevare il flood mi servirebbe... però mi sa che essendo già parte di un estensione di classe io non possa usare i metodi in altre classi o classi che estendono la stessa classe "mamma" ... o no?
bene.. allora, range di ip.. direi di no per i motivi detti da marco. Ho previsto in alternativa quello coi dns perchè ci vuole proprio na bella sfiga che l'attacker sia sul tuo stesso provider :)
... no scherzo, è che comunque ho cercato di fare una "cascata" per cui se passi da uno facilmente se hai intenzioni malevole incappi nel secondo... il flood è il minimo... e verresti avvisato per mail.
M.
ps:
penso che l'unica sia loggare i dati in un db e fare sì che il plugin faccia un lookup sulla tabella per verificare i dati raccolti.
--------------------------------------------------------------
..adottato! :) ... continuate così... che vi serve ... birra? ...mando na cassaaaa? :)
-
il problema è i provider grandi hanno così tanti ip che non sarebbe più utile come sistema di protezione...
Hai perfettamente ragione. Ci ho pensato dopo che ho postato, ma ormai... :)
Solo che per chi ha un ip dinamico è un bel casino. Lo dico in funzione di una possibile distribuzione del plugin, non perchè non funzioni.
Si, pensavo che si trattasse di un trigger sul db. Lavorando con Oracle è un termine che ricorre quindi pensavo si riferisse a quello.
Ho detto due stronzate in pochi minuti! ;D ;D
Vedi che fa fare leggere troppi topic sul forum di Joomla? Prima o poi torno a fare l'utonto ;D ;D
-
bene.. allora, range di ip.. direi di no per i motivi detti da marco. Ho previsto in alternativa quello coi dns perchè ci vuole proprio na bella sfiga che l'attacker sia sul tuo stesso provider
ehem! :-[
Mi viene un dubbio atroce. Il mio provider?
A costo di dire la terza... Ma intendi il dns che usa il mio isp? (credo usino OpenDNS e io mi sono impostato i dns di google che vanno meglio)
Vabbè. ho detto la terza.
-
oddio! ecco il primo bug :)
..scusa ma con gethostbyaddr($tuoip) cosa ti viene fuori?
in fondo io uso quella funzione in modo un po' barbaro... ci sarà nei tuoi dns una stringa fissa...
M.
ah ... però magari intendevi che ce l'hanno in tanti?
-
...intendevo che serviva per gli accessi da frontend.
mi sono perso: con accessi non intendi i login, ma le normali page view, vero? stiamo parlando di possibili denial of service?
in tal caso devi agire sul primo trigger raggiungibile in system, quindi ok per onAfterInitialise.
va da sé che stiamo parlando di due plugin differenti (e magari di un componente di analisi lato be)
che vi serve ... birra? ...mando na cassaaaa? :)
rossa e corposa, ti mando l'indirizzo ;D ;D ;D
ciao,
marco
-
mi sono perso: con accessi non intendi i login, ma le normali page view, vero? stiamo parlando di possibili denial of service?
in tal caso devi agire sul primo trigger raggiungibile in system, quindi ok per onAfterInitialise.
--------------------------------------------
esatto, il mio problema è se c'era un modo di usare all'interno di questo listener, onAfterInitialise, dei metodi che ho già sotto l'altro listener onAuthentication. E' brutto scrivere due volte le stesse cose!
Oppure pensavo addirittura ad una classe comune, ho visto anche scrivere due classi nello stesso plugin...
insomma non riesco a capire che strada prendere.
M.
-
nel caso specifico:
a) se costruisci anche il componente per l'analisi dei dati, usa una classe comune nella dir del componente
b) se usi solo i due plugins, duplica il codice.
ciao,
marco
-
ho visto che ad esempio nei plugins/search usa qs sintassi
$mainframe->registerEvent( 'onSearch', 'plgSearchCategories' );
$mainframe->registerEvent( 'onSearchAreas', 'plgSearchCategoryAreas' );
mi domandavo se funzionava anche
$mainframe->registerEvent( 'onAuthentication', 'plgDelLogin' );
$mainframe->registerEvent( 'onbeforeInitialize', 'plgDegliaccessi' );
poi mi verrebbe la domanda... e mo dove lo metto? sotto che gruppo?
M.
-
il motivo per cui ti avevo dato la risposta di cui sopra è che appartengono a due gruppi diversi...
ciao,
marco
-
già già ... che palle! :) era tanto semplice!
M.