Una buona pratica di black list sull'indirizzo IP impedisce gli attacchi ai siti web?

Direi di non disturbare troppo la lista nera degli IP:

• Ci sono troppi falsi positivi, dal momento che ci sono molte situazioni di IP condivisi: proxy, posto di lavoro, provider di servizi Internet che utilizzano DHCP itinerante, ecc.
• È troppo facile aggirarlo. Un vero cattivo vedrà solo un IP diverso, se davvero vuole attaccarti.

Suggerirei una "lista grigia" di indirizzi IP, ad esempio se riconosci un cattivo traffico, "tieni d'occhio" quegli indirizzi.

Una lista nera IP può aiutare, ma non fare affidamento su di essa come unico mezzo di sicurezza.

Dovrai anche fare molta attenzione a vietare blocchi IP o motori di ricerca. Puoi anche mantenere una whitelist di IP che sono falsi positivi per le tue influenze sospette.

Finché le influenze sospette non sono troppo severe. Non vuoi bloccare un buon utente.

In linea di principio può essere buono.

Tuttavia dipende da quanto tempo blocchi gli indirizzi IP. Inoltre, dovresti considerare che alcuni utenti come quelli che utilizzano AOL se ricordo che arrivano tramite server proxy, quindi molti utenti condivideranno lo stesso indirizzo IP e di conseguenza potresti bloccare un sacco di persone. Un'altra considerazione è che Office, Università, ecc. Può anche avere molti computer che condividono lo stesso IP e questa è un'altra vasta gamma di persone che potrebbero finire per bloccare azioni di un utente.

Potresti forse bloccare per un breve periodo di tempo o bloccare una combinazione di user agent e indirizzo IP per limitare l'effetto dei blocchi.

Dipende. Se la tua applicazione è un server SMTP, puoi tranquillamente presumere che tutto il traffico in arrivo debba provenire da IP statici, cioè se il messaggio proviene dall'IP dinamico, probabilmente è spam o virus inviato da qualche tipo di botnet. In tal caso è davvero una buona idea impedire loro di connettersi e credo che sia una buona pratica.

In generale direi che può essere un controllo piuttosto efficace. Un problema che potresti ottenere è che gli utenti provengano da un proxy, che può sembrare che provengano tutti da un indirizzo IP, bloccandone uno che potrebbe bloccarli tutti. A volte puoi utilizzare l'intestazione X-Forwarded-For per differenziare le richieste da un indirizzo IP sorgente, ma è non presente necessariamente su tutte le richieste inoltrate.

Prestare attenzione alle configurazioni del server dove, ad esempio su Rackspace, il _SERVER [REMOTE_IP] che di solito è l'indirizzo IP dell'utente, è in realtà un server proxy che supporta il carico.

Tuttavia l'intestazione REMOTE_IP è in realtà l'unica intestazione non sostituibile in termini di ip reale degli utenti.

HTTP_X_CLUSTER_CLIENT_IP e HTTP_X_FORWARDED_FOR (per citarne alcuni), ad esempio, possono essere tutti falsificati da un sistema di attacco / attacco.

Molti dei plug-in di protezione dei componenti aggiuntivi di CMS che ho esaminato in quel tentativo di filtrare gli input utilizzando un approccio a cascata di potenziali intestazioni quindi vietano l'indirizzo IP di richieste errate, tendono ad impilare la maggior parte delle intestazioni di client o proxy comuni prima, il REMOTE_ADDR è l'ultimo della lista, questo per un utente malintenzionato è banale da bypassare, quindi l'intera applicazione diventa inutile poiché un nuovo indirizzo ip del client può essere potenzialmente inviato con ogni richiesta canaglia.

Eliminare l'indirizzo IP errato in una configurazione cluster potrebbe comportare il bando del sito Web e impedire l'IP bocciato può consentire a un utente malintenzionato di inviare un IP spoofato del server Web o un proxy di upline al server Web che risulta nel stesso effetto.

O dove vengono utilizzati gli IP autorizzati, l'utente malintenzionato potrebbe anche inviare le richieste non autorizzate con l'IP autorizzato.

Il metodo migliore che ho trovato in queste situazioni è: Laddove ci sono altre intestazioni presenti oltre al REMOTE_IP, la regola numero uno è sempre filtrata per assicurarsi che quelle intestazioni contengano effettivamente un indirizzo IP, quindi si usano quelle per determinare l'indirizzo IP dell'utente, tuttavia disabilitare il banning ip (se viene utilizzato ) in quell'istanza, e basta andare con una chiamata 403 header e page die () per bloccare una richiesta canaglia effettiva piuttosto che vietare effettivamente l'indirizzo ip.

Dopotutto è la richiesta canaglia che vuoi impedire di completare più di ogni altra cosa. Bannare gli indirizzi IP è più di un problema in cui un utente malintenzionato sta martellando il tuo sito tramite più server proxy anonimi per creare un Denial of Service.