È possibile bloccare utenti specifici che si connettono a Internet dietro lo stesso gateway con NAT?

Nel caso generale, no.

In alcuni casi specifici, puoi. Ad esempio, se si esegue un server Web e il NAT del gateway modifica le richieste HTTP per includere un'intestazione "X-Forwarded-For", è possibile utilizzare l'intestazione XFF per distinguere e bloccare singoli computer (presupponendo, ovviamente, che il gateway è onesto).

Se si riesce a rilevare in modo affidabile la porta di origine utilizzata, è possibile bloccare tutto il traffico da quella porta di origine. Spesso, NAT differenzia tra gli utenti per porta. Il problema è che le porte di origine possono cambiare, quindi dovresti rilevare il traffico di attacco esclusivamente da un identificatore che cambia.

Sono d'accordo con Mark; nel caso generale n.

Puoi provare a farlo utilizzando le funzionalità specifiche di un utente (differenze UserAgent / XFF / qualsiasi altra cosa) ma nessuna di queste funzioni è affidabile e la maggior parte di esse viene banalmente modificata dall'utente.

A seconda di come lo fai, potresti effettivamente esporsi agli attacchi di esaurimento delle risorse se la gente falsifica un milione di stringhe XFF o UA per vedere cosa fa il tuo sistema ... e il tuo sistema prova a memorizzare & registra tutto questo.

C'è una soluzione, ma non so se è valida nel tuo caso perché non ho l'intera immagine: certificati lato client .

In poche parole, avrai bisogno di un firewall dell'applicazione e di spostare la convalida SSL sul perimetro. Se il cliente è autorizzato, ha accesso. In caso contrario (e per impostazione predefinita) sono bloccati.

Ovviamente questo apre un'altra lattina di worm visto che dovrai gestire i certificati, mantenere aggiornato il tuo elenco di revoche, ecc.

Inoltre, come altri hanno suggerito, rischi di diventare una vittima di un attacco di esaurimento delle risorse. A questo punto vale la pena considerare se il costo della creazione di un'architettura come quella descritta sopra potrebbe essere più che scalare il server o spostarlo su un provider più capace, forse uno con la "protezione" DDoS.