Por que essa primeira regra de iptables não corresponde a tentativas repetidas de conexão?

Navegue suas respostas
1

Tentando atenuar os ataques de força bruta de SSH na minha caixa, eu copiei / colei as seguintes regras no meu iptables (sem realmente entendê-los, devo confessar): 

$> iptables-save
# Generated by iptables-save v1.4.14 on Wed Jun 11 15:13:01 2014
*filter
:INPUT ACCEPT [1255:139338]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1099:174390]
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m recent --rcheck --seconds 60 --hitcount 5 --rttl --name SSH --rsource -j LOG --log-prefix "[iptables] SSH brute-force "
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset
COMMIT
# Completed on Wed Jun 11 15:13:01 2014

Para minha satisfação, funciona como pretendido (repetidas tentativas de conexão são rejeitadas, enquanto tentativas legítimas passam). Desde então percebi que existem outras maneiras de obter o mesmo efeito: exemplo 1 , exemplo 2 .

Eu (acredito que) entendo como os métodos outros funcionam, mas não consigo entender como a primeira regra acima corresponde apenas a "novas conexões de entrada de fontes untracked ".

Isso contradiz o que eu entendo do manual :

--set: This will always return success

O que nesta regra faz não coincidir com tentativas de conexão repetidas? Eu assumo que a primeira regra não corresponde a repetidas tentativas de conexão, caso contrário regras subseqüentes nunca entrariam em ação.

Espero que qualquer nova ligação de entrada corresponda a esta regra.

Nos outros exemplos, eles não mencionam o destino -j ACCEPT : 

-A INPUT (...) -m state --state NEW -m recent --set --name SSH --rsource

Então, talvez minha pergunta possa ser reformulada:

A opção -j é inútil quando usada em conjunto com --set --name [some_name] ?

Conforme solicitado, aqui estão os resultados de iptables -L -n -v (ssh'ing de / para localhost, já que só tenho acesso remoto agora):

Estado inicial: 

Chain INPUT (policy ACCEPT 895 packets, 101K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   18  1080 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 state NEW recent: SET name: SSH side: source
   19   962 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 recent: CHECK seconds: 60 hit_count: 5 TTL-Match name: SSH side: source LOG flags 0 level 4 prefix "[iptables] SSH brute-force "
   19   962 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 recent: UPDATE seconds: 60 hit_count: 5 TTL-Match name: SSH side: source reject-with tcp-reset

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 776 packets, 119K bytes)
 pkts bytes target     prot opt in     out     source               destination

Após a tentativa # 4: 

Chain INPUT (policy ACCEPT 1040 packets, 121K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   22  1320 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 state NEW recent: SET name: SSH side: source
   19   962 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 recent: CHECK seconds: 60 hit_count: 5 TTL-Match name: SSH side: source LOG flags 0 level 4 prefix "[iptables] SSH brute-force "
   19   962 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 recent: UPDATE seconds: 60 hit_count: 5 TTL-Match name: SSH side: source reject-with tcp-reset

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 911 packets, 141K bytes)
 pkts bytes target     prot opt in     out     source               destination

Após a tentativa # 5 (que foi rejeitada): 

Chain INPUT (policy ACCEPT 1063 packets, 122K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   23  1380 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 state NEW recent: SET name: SSH side: source
   21  1054 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 recent: CHECK seconds: 60 hit_count: 5 TTL-Match name: SSH side: source LOG flags 0 level 4 prefix "[iptables] SSH brute-force "
   21  1054 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 recent: UPDATE seconds: 60 hit_count: 5 TTL-Match name: SSH side: source reject-with tcp-reset

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 933 packets, 144K bytes)
 pkts bytes target     prot opt in     out     source               destination

Log do "ataque": 

Jun 11 15:07:02 [hostname_hidden] kernel: [249278.516231] [iptables] SSH brute-force IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=59245 DF PROTO=TCP SPT=36129 DPT=22 WINDOW=0 RES=0x00 RST URGP=0 
Jun 11 15:07:18 [hostname_hidden] kernel: [249294.514964] [iptables] SSH brute-force IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=59246 DF PROTO=TCP SPT=36129 DPT=22 WINDOW=0 RES=0x00 RST URGP=0
    
por RandomSeed 11.06.2014 / 14:07

1 resposta

1

Parece-me que a resposta está na contagem de pacotes e nos detalhes das regras. Especificamente, com a tentativa 5, as contagens em ambos conjuntos de regras (o ACCEPT e o LOG / REJECT pair) são incrementados.

Suspeito que, com a tentativa 5, o pacote inicial SYN corresponde à regra ACCEPT , e é ACCEPT ed e aumenta as contagens. Mas como a contagem foi incrementada pelos pacotes ACCEPT ed SYN , pacotes subseqüentes nessa conexão recém-estabelecida agora correspondem ao par mais atrasado LOG / REJECT e, portanto, são rejeitados . Os logs ajudam a confirmar essa visualização, pois você verá que nem REJECT ed pacote tem o sinalizador SYN definido.

    
por 11.06.2014 / 14:27

Tags

Apache mod_proxy_balancer + Balanceamento de carga do Tomcat - Não deve redirecionar até que os aplicativos da Web estejam prontos Como criar um ponto de conexão de serviço para descoberta automática do Exchange Server (manualmente)