Iptables non chiude le porte come dovrebbe
- omegaub
- Scoppiettante Seguace
- Messaggi: 342
- Iscrizione: martedì 2 dicembre 2008, 12:50
- Desktop: gnome
- Distribuzione: Ubuntu 18.04.4 LTS
- Sesso: Femminile
- Località: Boschi romani
Iptables non chiude le porte come dovrebbe
Buongiorno a tutti!
Ho un server in cui ho installato dei docker, per farli funzionare devo aprire le porte con le quali comunico con loro. Il server è continuamente bombardato da porte superiori alla 10000. Ho configurato iptables in questo modo:
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- IP1
2 ACCEPT all -- IP2
3 ACCEPT all -- IP3
4 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
5 ACCEPT tcp -- anywhere anywhere tcp multiport dports ftp,ssh,http,https,mysql,postgres,cslistener,hbci
6 DROP all -- anywhere anywhere
In teoria, a parte le porte lasciate aperte, tutte le altre dovrebbero essere blindate; la condizione 4 è appunto per i docker che richiamano librerie esterne.
Inoltre, cosa più GRAVE, avevo configurato in ssh l'opzione AlloUser, per un po' di tempo ha funzionato, ora sembra non funzionare più, nel senso, quando dò il comando:
journalctl -xe
prima risultava utente bloccato perchè non nell'elenco degli utenti permessi, ora non più.
Qualcuno mi sa aiutare?
Grazie di cuore!
Mic speranzosa
Ho un server in cui ho installato dei docker, per farli funzionare devo aprire le porte con le quali comunico con loro. Il server è continuamente bombardato da porte superiori alla 10000. Ho configurato iptables in questo modo:
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- IP1
2 ACCEPT all -- IP2
3 ACCEPT all -- IP3
4 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
5 ACCEPT tcp -- anywhere anywhere tcp multiport dports ftp,ssh,http,https,mysql,postgres,cslistener,hbci
6 DROP all -- anywhere anywhere
In teoria, a parte le porte lasciate aperte, tutte le altre dovrebbero essere blindate; la condizione 4 è appunto per i docker che richiamano librerie esterne.
Inoltre, cosa più GRAVE, avevo configurato in ssh l'opzione AlloUser, per un po' di tempo ha funzionato, ora sembra non funzionare più, nel senso, quando dò il comando:
journalctl -xe
prima risultava utente bloccato perchè non nell'elenco degli utenti permessi, ora non più.
Qualcuno mi sa aiutare?
Grazie di cuore!
Mic speranzosa
Re: Iptables non chiude le porte come dovrebbe
Policy accept = tutte le porte sono aperte e tutte le altre regole che hai aggiunto sono ridondanti ...
-
- Rampante Reduce
- Messaggi: 5460
- Iscrizione: domenica 20 gennaio 2008, 1:13
- Desktop: Kubuntu
- Distribuzione: 20.04 x64
- Contatti:
Re: Iptables non chiude le porte come dovrebbe
iptables fa quanto nella configurazione è scritto.
Non quanto c'è nelle speranze di chi fa la configurazione...
Non quanto c'è nelle speranze di chi fa la configurazione...
Sono colui che fa cose che non servono...
Secondo Principio di Dilbert, di Scott Adams. "Si parte dalla certezza che siamo tutti idioti". Ed alcuni su questo mi ab-battono alla grande.
Come certificato dalla moderazione, incivile e maleducato. You have been warned.
Secondo Principio di Dilbert, di Scott Adams. "Si parte dalla certezza che siamo tutti idioti". Ed alcuni su questo mi ab-battono alla grande.
Come certificato dalla moderazione, incivile e maleducato. You have been warned.
- omegaub
- Scoppiettante Seguace
- Messaggi: 342
- Iscrizione: martedì 2 dicembre 2008, 12:50
- Desktop: gnome
- Distribuzione: Ubuntu 18.04.4 LTS
- Sesso: Femminile
- Località: Boschi romani
Re: Iptables non chiude le porte come dovrebbe
Ho impostato
iptables -P INPUT DROP
e lasciato il resto della configurazione, eliminata la riga 4 ma continuano a bombardare sulle porte alte.
iptables -P INPUT DROP
e lasciato il resto della configurazione, eliminata la riga 4 ma continuano a bombardare sulle porte alte.
Re: Iptables non chiude le porte come dovrebbe
posta
Codice: Seleziona tutto
sudo iptables -S
- omegaub
- Scoppiettante Seguace
- Messaggi: 342
- Iscrizione: martedì 2 dicembre 2008, 12:50
- Desktop: gnome
- Distribuzione: Ubuntu 18.04.4 LTS
- Sesso: Femminile
- Località: Boschi romani
Re: Iptables non chiude le porte come dovrebbe
Ho anche creato uno script che, all'interno di /var/log/secure, individua gli ip con "Failed password for invalid user" e li "looppa" con il comando:
route add IP gw 127.0.0.1 lo;
ho bloccato l'accesso in ssh all'utente root ed indicato nell'opzione AllowUsers soltanto quello che utilizzo io per collegarmi.
Questi gli output di:
# iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-USER
-N DOCKER-ISOLATION-STAGE-2
-A INPUT -s IP1/32 -j ACCEPT
-A INPUT -s IP2/32 -j ACCEPT
-A INPUT -s IP3/32 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp -m multiport --dports 21,22,80,443,3306,5432,9000,3000 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d IP1local/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 9000 -j ACCEPT
-A DOCKER -d IP2local/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 3000 -j ACCEPT
-A DOCKER -d IP3local/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 5432 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-USER -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
#journalctl -xe
Jan 12 14:48:34 my.hostname sshd[50598]: Invalid user sysop from 58.87.90.156 port 57218
Jan 12 14:48:34 my.hostname sshd[50598]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 14:48:34 my.hostname sshd[50598]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.87.90.156
Jan 12 14:48:36 my.hostname sshd[50598]: Failed password for invalid user sysop from 58.87.90.156 port 57218 ssh2
Jan 12 14:48:37 my.hostname sshd[50598]: Received disconnect from 58.87.90.156 port 57218:11: Bye Bye [preauth]
Jan 12 14:48:37 my.hostname sshd[50598]: Disconnected from invalid user sysop 58.87.90.156 port 57218 [preauth]
Jan 12 14:48:42 my.hostname sshd[50628]: Invalid user redmine from 177.12.227.131 port 27806
Jan 12 14:48:42 my.hostname sshd[50628]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 14:48:42 my.hostname sshd[50628]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=177.12.227.131
Jan 12 14:48:43 my.hostname sshd[50628]: Failed password for invalid user redmine from 177.12.227.131 port 27806 ssh2
Jan 12 14:48:43 my.hostname sshd[50642]: Invalid user prince from 46.101.4.230 port 45166
Jan 12 14:48:43 my.hostname sshd[50642]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 14:48:43 my.hostname sshd[50642]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=46.101.4.230
Jan 12 14:48:44 my.hostname sshd[50628]: Received disconnect from 177.12.227.131 port 27806:11: Bye Bye [preauth]
Jan 12 14:48:44 my.hostname sshd[50628]: Disconnected from invalid user redmine 177.12.227.131 port 27806 [preauth]
Jan 12 14:48:44 my.hostname sshd[50638]: Invalid user tomas from 121.4.31.236 port 44882
Jan 12 14:48:44 my.hostname sshd[50638]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 14:48:44 my.hostname sshd[50638]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.4.31.236
Jan 12 14:48:46 my.hostname sshd[50642]: Failed password for invalid user prince from 46.101.4.230 port 45166 ssh2
Jan 12 14:48:47 my.hostname sshd[50642]: Received disconnect from 46.101.4.230 port 45166:11: Bye Bye [preauth]
Jan 12 14:48:47 my.hostname sshd[50642]: Disconnected from invalid user prince 46.101.4.230 port 45166 [preauth]
Jan 12 14:48:47 my.hostname sshd[50650]: Invalid user michel from 202.155.228.207 port 34896
Jan 12 14:48:47 my.hostname sshd[50650]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 14:48:47 my.hostname sshd[50650]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.155.228.207
Jan 12 14:48:47 my.hostname sshd[50638]: Failed password for invalid user tomas from 121.4.31.236 port 44882 ssh2
route add IP gw 127.0.0.1 lo;
ho bloccato l'accesso in ssh all'utente root ed indicato nell'opzione AllowUsers soltanto quello che utilizzo io per collegarmi.
Questi gli output di:
# iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-USER
-N DOCKER-ISOLATION-STAGE-2
-A INPUT -s IP1/32 -j ACCEPT
-A INPUT -s IP2/32 -j ACCEPT
-A INPUT -s IP3/32 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp -m multiport --dports 21,22,80,443,3306,5432,9000,3000 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d IP1local/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 9000 -j ACCEPT
-A DOCKER -d IP2local/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 3000 -j ACCEPT
-A DOCKER -d IP3local/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 5432 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-USER -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
#journalctl -xe
Jan 12 14:48:34 my.hostname sshd[50598]: Invalid user sysop from 58.87.90.156 port 57218
Jan 12 14:48:34 my.hostname sshd[50598]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 14:48:34 my.hostname sshd[50598]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.87.90.156
Jan 12 14:48:36 my.hostname sshd[50598]: Failed password for invalid user sysop from 58.87.90.156 port 57218 ssh2
Jan 12 14:48:37 my.hostname sshd[50598]: Received disconnect from 58.87.90.156 port 57218:11: Bye Bye [preauth]
Jan 12 14:48:37 my.hostname sshd[50598]: Disconnected from invalid user sysop 58.87.90.156 port 57218 [preauth]
Jan 12 14:48:42 my.hostname sshd[50628]: Invalid user redmine from 177.12.227.131 port 27806
Jan 12 14:48:42 my.hostname sshd[50628]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 14:48:42 my.hostname sshd[50628]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=177.12.227.131
Jan 12 14:48:43 my.hostname sshd[50628]: Failed password for invalid user redmine from 177.12.227.131 port 27806 ssh2
Jan 12 14:48:43 my.hostname sshd[50642]: Invalid user prince from 46.101.4.230 port 45166
Jan 12 14:48:43 my.hostname sshd[50642]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 14:48:43 my.hostname sshd[50642]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=46.101.4.230
Jan 12 14:48:44 my.hostname sshd[50628]: Received disconnect from 177.12.227.131 port 27806:11: Bye Bye [preauth]
Jan 12 14:48:44 my.hostname sshd[50628]: Disconnected from invalid user redmine 177.12.227.131 port 27806 [preauth]
Jan 12 14:48:44 my.hostname sshd[50638]: Invalid user tomas from 121.4.31.236 port 44882
Jan 12 14:48:44 my.hostname sshd[50638]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 14:48:44 my.hostname sshd[50638]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.4.31.236
Jan 12 14:48:46 my.hostname sshd[50642]: Failed password for invalid user prince from 46.101.4.230 port 45166 ssh2
Jan 12 14:48:47 my.hostname sshd[50642]: Received disconnect from 46.101.4.230 port 45166:11: Bye Bye [preauth]
Jan 12 14:48:47 my.hostname sshd[50642]: Disconnected from invalid user prince 46.101.4.230 port 45166 [preauth]
Jan 12 14:48:47 my.hostname sshd[50650]: Invalid user michel from 202.155.228.207 port 34896
Jan 12 14:48:47 my.hostname sshd[50650]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 14:48:47 my.hostname sshd[50650]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.155.228.207
Jan 12 14:48:47 my.hostname sshd[50638]: Failed password for invalid user tomas from 121.4.31.236 port 44882 ssh2
- omegaub
- Scoppiettante Seguace
- Messaggi: 342
- Iscrizione: martedì 2 dicembre 2008, 12:50
- Desktop: gnome
- Distribuzione: Ubuntu 18.04.4 LTS
- Sesso: Femminile
- Località: Boschi romani
Re: Iptables non chiude le porte come dovrebbe
questo silenzio mi fa supporre che chi attacca i miei server è piuttosto bravino...
-
- Rampante Reduce
- Messaggi: 5460
- Iscrizione: domenica 20 gennaio 2008, 1:13
- Desktop: Kubuntu
- Distribuzione: 20.04 x64
- Contatti:
Re: Iptables non chiude le porte come dovrebbe
O che qui mediamente passano utenti di pc desktop, e non di server.
Cercati Fail2Ban. Magari è un software adatto a... gestire il tuo problema
Cercati Fail2Ban. Magari è un software adatto a... gestire il tuo problema
Sono colui che fa cose che non servono...
Secondo Principio di Dilbert, di Scott Adams. "Si parte dalla certezza che siamo tutti idioti". Ed alcuni su questo mi ab-battono alla grande.
Come certificato dalla moderazione, incivile e maleducato. You have been warned.
Secondo Principio di Dilbert, di Scott Adams. "Si parte dalla certezza che siamo tutti idioti". Ed alcuni su questo mi ab-battono alla grande.
Come certificato dalla moderazione, incivile e maleducato. You have been warned.
Re: Iptables non chiude le porte come dovrebbe
@omegaub : premesso che ritengo inaccettabile che una/o iscritto/a al forum da 12 anni posti in quel modo gli output ...
il silenzio è dovuto anche al fatto che da parte tua mancano informazioni sufficienti ... ad esempio : su che servizi usano quelle porte dove registri i tentativi di login , e (penso) che chi chiede aiuto dovrebbe fornirle ... quindi perchè dovremmo spremerci le meningi noi ad immaginarle ???
- DoctorStrange
- Imperturbabile Insigne
- Messaggi: 2872
- Iscrizione: mercoledì 14 ottobre 2015, 9:33
- Desktop: Gnome3
- Distribuzione: Ubuntu 22.04 LTS Jammy Jellyfish
- Sesso: Maschile
- Località: Roma, Italia
Re: Iptables non chiude le porte come dovrebbe
Giusto per dare un mio modesto contributo: Io sospetto qualcosa per questa stringa: .
Come immagino saprai, tutte le regole iptables vengono applicate in sequenza in funzione di come queste vengono scritte.
Questo significa che, proprio la regola: che viene applicata alla fine della toolchain di INPUT, fa il drop di tutti i pacchetti che hanno superato la validazione precedente e, visto che la policy sulla toolchain di input è, anche lei drop, io sospetto che tutti i pacchetti di input vengono dismessi.
Codice: Seleziona tutto
-A INPUT -j DROP
Come immagino saprai, tutte le regole iptables vengono applicate in sequenza in funzione di come queste vengono scritte.
Questo significa che, proprio la regola:
Codice: Seleziona tutto
-A INPUT -j DROP
- thece
- Tenace Tecnocrate
- Messaggi: 12949
- Iscrizione: lunedì 23 aprile 2007, 14:16
- Distribuzione: Debian 12 (Bookworm) - KDE
Re: Iptables non chiude le porte come dovrebbe
Oppure che chi ha scritto quelle regole non ci capisce una H di IPTables (e io di certo non sono un grande esperto)
Riguardati le regole che sono impostate.
Se un pacchetto IP passa e non dovrebbe (o viceversa) chiediti:
- come è fatto quel pacchetto IP?
- come attraversa le regole impostate?
- quali lo lasciano passare?
- quali lo scartano?
Aiutati con uno schema per visualizzare il "percorso" effettuato dal pacchetto dentro IPTables (come attraversa tutte le catene e le regole definite).
Aiutati con le regole di logging per arrivare al comportamento desiderato.
Quoto @Pike , che magari nei modi pecca ma spesso ci azzecca.
Ultima modifica di thece il venerdì 15 gennaio 2021, 20:02, modificato 2 volte in totale.
- Stealth
- Tenace Tecnocrate
- Messaggi: 17349
- Iscrizione: martedì 31 gennaio 2006, 22:55
- Desktop: Gnome
- Distribuzione: Ubuntu 22.04 LTS
Re: Iptables non chiude le porte come dovrebbe
Non è così, la policy droppa tutto ciò che tu non consenti esplicitamente. Per capirci meglio, se tu imposti la policy in drop e non gli dici più nulla, allora non passerà nulla. E il drop a tutto, come regola finale, non è concettualmente sbagliato. È solo ridondante, in caso qualcosa vada storto con la policy.DoctorStrange ha scritto: ↑venerdì 15 gennaio 2021, 16:45... visto che la policy sulla toolchain di input è, anche lei drop, io sospetto che tutti i pacchetti di input vengono dismessi.
Prima di quello, però, lui ha messo parecchi "ACCEPT" e solo lui sa come, quindi io che (come thece) non sono un esperto di iptables, posso solo consigliare di rivolgersi ad un esperto o acquistare soluzioni già pronte e che si adattino alle sue esigenze
- thece
- Tenace Tecnocrate
- Messaggi: 12949
- Iscrizione: lunedì 23 aprile 2007, 14:16
- Distribuzione: Debian 12 (Bookworm) - KDE
Re: Iptables non chiude le porte come dovrebbe
Tempo fa leggendo delle best practices sulla scrittura delle regole di IPTables queste dicevano di lasciare come policy di default sempre ACCEPT e di inserire esplicitamente una regola di DROP come ultima di catena.
Un qualcosa del genere (*)
Spieghino: queste poche regole droppano tutte le connessioni in ingresso (tranne quelle sull'interfaccia di loopback) iniziate dall'esterno, droppano tutte le connessioni inoltrate, permettono tutte le connessioni in uscita.
(*) è un estratto di un mio script di inizializzazione.
QUI avevo postato la versione completa.
funziona benissimo. Non capisco la tua correlazione con journalctl.
Un qualcosa del genere (*)
Codice: Seleziona tutto
$IP4TABLES -t filter -P INPUT ACCEPT
$IP4TABLES -t filter -P FORWARD ACCEPT
$IP4TABLES -t filter -P OUTPUT ACCEPT
# INPUT
(Inserire qui eventuali altre regole sulla chain INPUT)
$IP4TABLES -A INPUT -i lo -j ACCEPT
$IP4TABLES -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IP4TABLES -A INPUT -j DROP
# FORWARD
(Inserire qui eventuali altre regole sulla chain FORWARD)
$IP4TABLES -A FORWARD -j DROP
(*) è un estratto di un mio script di inizializzazione.
QUI avevo postato la versione completa.
Stessa cosa. Nel file /etc/ssh/sshd_config la direttiva
Codice: Seleziona tutto
AllowUsers USER01 USER02 ...
-
- Rampante Reduce
- Messaggi: 5460
- Iscrizione: domenica 20 gennaio 2008, 1:13
- Desktop: Kubuntu
- Distribuzione: 20.04 x64
- Contatti:
Re: Iptables non chiude le porte come dovrebbe
Carina la rima, gentile il complimento.
iptables, come il firewalling in genere, è stupido. Fa quello che gli dici esattamente come tu glielo dici, ogni volta che arriva un pacchetto.
La "presunta intelligenza" la crea la configurazione, in grado di essere corretta, adatta e ottimizzata al contesto.
Come i software di firewalling, bisogna essere stupidi imparando la sintassi, comprendendo ogni passo e applicando la stessa identica logica per capire cosa sta facendo il firewall in quel momento. Aggiungendo il log per ogni regola, in fase di risoluzione problemi, si fa "esplodere" la dimensione, ma si trovano i passi che vengono eseguiti dal software.
Finito di essere stupidi leggendo ed interpretando i log, bisogna essere "intelligenti" nella minimalità, nell'ordinamento delle regole (più in alto sono, più corta è la coda di elaborazione, quindi le righe/condizioni più usate è saggio che siano il più in alto possibile, compatibilimente con la logica, per risparmiare potenza di calcolo), nell'accortezza delle istruzioni (e più è familiare la sintassi di iptables, più velocemente si arriva a fare cose equilibrate).
Mi ripeto: iptables è stupido. Ed essendo un software, non una persona, non lo si convince con le chiacchiere, gli insulti, la circuizione. Bisogna dare le corrette istruzioni.
Prima però bisogna sapere cosa fanno queste istruzioni...
Questo è un dispositivo che amministro, non linux.
Almeno il 30-35% delle regole "nasce" con la macchina, che ha zone preconfigurate e regole di default che, per evitare errori, preferisco lasciare, disattivandole se non mi occorrono.
Prima o poi voglio completamente ristudiare le regole da zero, a vedere se riesco a tagliarne 3 o 4.
Tale dispositivo ha nat su una quaterna di porte, cinque endpoint IPSec statici, un endpoint IPSec roadwarrior, un endpoint L2TP Roadwarrior.
E' una piccola installazione, quelle grosse sono scritte in modo molto più pignolo (regole firewall non solo in transito, ma anche in entrata ed in uscita!)
Ultima modifica di Pike il venerdì 15 gennaio 2021, 20:57, modificato 1 volta in totale.
Sono colui che fa cose che non servono...
Secondo Principio di Dilbert, di Scott Adams. "Si parte dalla certezza che siamo tutti idioti". Ed alcuni su questo mi ab-battono alla grande.
Come certificato dalla moderazione, incivile e maleducato. You have been warned.
Secondo Principio di Dilbert, di Scott Adams. "Si parte dalla certezza che siamo tutti idioti". Ed alcuni su questo mi ab-battono alla grande.
Come certificato dalla moderazione, incivile e maleducato. You have been warned.
Re: Iptables non chiude le porte come dovrebbe
io insisto che l'utente in questione dovrebbe fornire maggiori informazioni , ad esempio se il server anzichè girare su ubuntu girasse su debian 10 userebbe come default nftables al posto di iptables
@thece gli script non si usano da parecchio ... esiste iptables-persistent
@thece gli script non si usano da parecchio ... esiste iptables-persistent
- thece
- Tenace Tecnocrate
- Messaggi: 12949
- Iscrizione: lunedì 23 aprile 2007, 14:16
- Distribuzione: Debian 12 (Bookworm) - KDE
Re: Iptables non chiude le porte come dovrebbe
Sono vecchio
In questo caso nftables o iptables o qualsiasi altra cosa è uguale: è evidente che quelle regole non fanno quello che @omegaub si aspetta.
IMHO perchè @omegaub non sa come funziona IPTables
IMHO perchè @omegaub non sa (o non ricorda) come è fatto un pacchetto IP.
In quale tua regola hai impostato un filtro sulla porta sorgente?
Sei sicura di trarre un qualche vantaggio nel filtrare sulla porta sorgente?
Con un esempio
questo stralcio di output di netstat raffigura una connessione legittima tra un mio client SSH (.11) e un mio server SSH (.21). La porta sorgente della connessione SSH è 40960 > 10000. Se filtrassi sulla porta sorgente ( > 10000 ) introdurrei dei malfunzionamenti sulle funzionalità di rete.
In questo caso nftables o iptables o qualsiasi altra cosa è uguale: è evidente che quelle regole non fanno quello che @omegaub si aspetta.
IMHO perchè @omegaub non sa come funziona IPTables
IMHO perchè @omegaub non sa (o non ricorda) come è fatto un pacchetto IP.
Di quale porta stai parlando? Porta sorgente o porta di destinazione? Della porta sorgente ...
In quale tua regola hai impostato un filtro sulla porta sorgente?
Sei sicura di trarre un qualche vantaggio nel filtrare sulla porta sorgente?
Con un esempio
Codice: Seleziona tutto
tcp 0 196 192.168.0.21:22 192.168.0.11:40960 ESTABLISHED 1639/sshd
Riquoto @Pike , meglio usare fail2ban (o equivalenti) per bloccare temporanemente gli IP che provano ad indovinare le coppie utente / password dei vari servizi
Bene. Se poi disabiliti anche l'accesso con password e abiliti solo quello con chiavi è meglio.
Ultima modifica di thece il venerdì 15 gennaio 2021, 22:01, modificato 1 volta in totale.
- Clover
- Scoppiettante Seguace
- Messaggi: 298
- Iscrizione: giovedì 30 agosto 2012, 14:04
- Desktop: KDE
- Distribuzione: Kubuntu x86_64
Re: Iptables non chiude le porte come dovrebbe
Non ho letto tutti i commenti perché ad un certo punto mi pare che la discussione sia mezza degenerata e per quanto riguarda il problema segnalato c'è di mezzo docker che conosco poco e non so se possa manipolare e come le catene di iptables... cmq segnalo la procedura per loggare le singole regole in modo da poter poi capire una connessione da dove è passata.
Per esempio se per loggare le connessioni ssh:
Per esempio se per loggare le connessioni ssh:
Codice: Seleziona tutto
-A INPUT -i enp2s0 -p tcp -m tcp --dport 22 -j LOG --log-prefix "SSH-CONNECTION " --log-level 4
-A INPUT -i enp2s0 -p tcp -m tcp --dport 22 -m comment --comment ssh -j ACCEPT
Chi c’è in linea
Visualizzano questa sezione: 0 utenti iscritti e 18 ospiti