Respostas:
Como regra geral, use REJECT quando quiser que a outra extremidade saiba que a porta está inacessível 'use DROP para conexões com hosts que você não quer que as pessoas vejam.
Geralmente, todas as regras para conexões dentro da sua LAN devem usar REJECT. Para a Internet, com exceção do ident em determinados servidores, as conexões da Internet geralmente são DROPPED.
O uso do DROP faz com que a conexão pareça estar com um endereço IP desocupado. Os scanners podem optar por não continuar a digitalização de endereços que parecem desocupados. Dado que o NAT pode ser usado para redirecionar uma conexão no firewall, a existência de um serviço conhecido não indica necessariamente a existência de um servidor em um endereço.
A identificação deve ser passada ou rejeitada em qualquer endereço que forneça serviço SMTP. No entanto, o uso de pesquisas de identidade por servidores SMTP caiu em desuso. Existem protocolos de bate-papo que também contam com um serviço de identificação de trabalho.
EDIT: Ao usar regras DROP: - Os pacotes UDP serão descartados e o comportamento será o mesmo que conectar a uma porta não protegida sem serviço. - Os pacotes TCP retornam um ACK / RST que é a mesma resposta que uma porta aberta sem serviço nela responderá. Alguns roteadores responderão com e ACK / RST em nome de servidores que estão inativos.
Ao usar as regras REJECT, um pacote ICMP é enviado, indicando que a porta está indisponível.
A diferença é que o destino REJECT envia uma resposta de rejeição à fonte, enquanto o destino DROP não envia nada.
Isso pode ser útil, por exemplo, para o serviço de identificação. Se você usar REJECT, os clientes não precisarão esperar pelo tempo limite.
Mais sobre isso: http://www.linuxtopia.org/Linux_Firewall_iptables/x4550.html
Geralmente, você deseja ignorar os probes dos invasores para determinadas portas, o que significa que você não deseja enviar de volta a 'conexão recusada'. 'Conexão recusada' significa: 'existe um servidor aqui' e, possivelmente, fornece mais informações, enquanto a remoção de um pacote não fornece pistas sobre versões de software, possíveis vulnerabilidades ou mesmo o fato de um servidor estar ouvindo seu IP.
O exposto acima é um dos principais motivos para usar o DROP em vez de REJECT.
Vejo muitas respostas conflitantes aqui e, dado que este é o primeiro artigo do Google com as palavras-chave corretas; aqui está a explicação correta.
É simples: o
DROP não faz nada com o pacote. Ele não é encaminhado para um host, não é respondido. A página de manual do IPtables diz que ele derruba o pacote no chão, ou seja, não faz nada com o pacote.
REJECT difere da DROP por enviar um pacote de volta, mas a resposta é como se um servidor estivesse localizado no IP, mas não tivesse a porta em um estado de escuta. As tabelas IP enviarão um RST / ACK no caso de TCP ou com UDP uma porta de destino ICMP inacessível.
Se você está tentando esconder completamente a existência da sua máquina, -j DROP
é apropriado. Por exemplo, você pode usar isso para implementar uma lista negra.
Se você estiver tentando ocultar o fato de uma porta estar aberta, imite o comportamento que ocorreria se a porta não estivesse aberta:
-p tcp -j REJECT --reject-with tcp-reset
-p udp -j REJECT --reject-with icmp-port-unreachable
Se um scanner de portas perceber que algumas portas estão descartando pacotes enquanto a maioria as está rejeitando, ele pode assumir que os pacotes descartados estão nas portas que estão abertas, mas ocultas.
Apesar de muitas respostas corretas, apenas meus dois centavos:
Aqui está um pequeno PoC FW.IDS-DROP-vs-REJECT para o assunto no que diz respeito às regras para o sistema de proibição (firewall, IDS, etc.).
Em breve:
DROP
pode ser usado para invasores recidivos, se banir todas as portas (parece que o servidor está inoperante)REJECT --reject-with tcp-reset
é a melhor opção para o banimento de várias portas, porque parece se comportar como uma porta fechada realDROP
e REJECT
(sem tcp-reset
) dará ao invasor um "sinal" de que algo está bloqueando (para que possa estimulá-lo a continuar o "ataque" na esperança de fornecer os dados necessários em algum ponto)Sim, usar o DROP não faz sentido. Use REJECT.
Mesmo quando a regra diz "DROP", o sistema ainda responde a um SYN de entrada com um TCP RST / ACK - que é o comportamento padrão para portas sem serviços em execução. (tcpdump et al não registra isso.)
Se um serviço estiver em execução, o SYN será atendido com TCP SYN / ACK.
Como o DROP não responde normalmente com um TCP SYN / ACK, mas com um RST / ACK, sua regra DROP anunciará seu firewall e os scanners de portas saberão que você está protegendo algo e pode continuar martelando você na esperança de travar seu firewall.
Agora, o nmap pode relatar "filtrado" em vez de "fechado", por exemplo:
$ nmap localhost
Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT STATE SERVICE
21/tcp open ftp
53/tcp open domain
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds
$ iptables -I INPUT -p tcp --dport 1111 -j DROP
$ nmap localhost
Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT STATE SERVICE
21/tcp open ftp
53/tcp open domain
80/tcp open http
1111/tcp filtered lmsocialserver
Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds
$ iptables -D INPUT 1
Como tal, a única configuração de firewall "invisível" é aquela em que um dispositivo dedicado fica entre seus dispositivos e apenas encaminha portas seletivamente.
Se você realmente quer mexer com os scanners básicos, pode TARPIT tcp connections, que define a janela TCP para 0, para que nenhum dado possa ser transferido depois que a conexão for aberta, ignorando as solicitações para fechar a conexão, o que significa que o scanner precisa esperar para que o tempo limite da conexão ocorra, se desejar ter certeza. Mas é trivial para um invasor detectar isso e diminuir o tempo limite dele.
Em suma, provavelmente é melhor usar REJECT - ou colocar um dispositivo de encaminhamento de porta dedicado entre o servidor e a Internet.
Ou apenas executando serviços em suas máquinas voltadas para a Internet que não exigem firewall.
Geralmente, o REJECT é melhor para servidores da Web, pois qualquer serviço que estiver tentando acessá-lo (provavelmente com mais frequência do que você) receberá rapidamente uma resposta e os usuários ou outros serviços não ficarão esperando esperando se perguntando se há uma interrupção na rede.
DROP
emitirá um SYN/ACK
? Eu nunca vi isso nas minhas máquinas.
DROP
retorna a SYN/ACK
. Eu também nunca vi esse comportamento em nenhuma versão do iptables
. Se você tem uma fonte que suporta sua reivindicação, seria mais útil vê-la; certamente, os despejos de pacotes que acabei de fazer não suportam sua reivindicação.