Não está claro para mim se a verificação de INVÁLIDO vs ESTABLISHED, RELATED é igualmente rápida para ambos os casos (e se os estados são completamente ortogonais). Devo descartar INVÁLIDO antes de aceitar ESTABLISHED ou posso aceitar com segurança ESTABLISHED e depois descartar INVÁLIDO?
Eu configurei o iptables para registrar o tráfego de saída de todos, exceto um conjunto limitado de usuários, e estou tentando entender as mensagens de log que isso produz. Olhando para/var/log/syslog, vejo solicitações de 127.0.0.1 a 127.0.0.53 (pesquisas de DNS?) E algumas para 224.0.0.22 que se parecem com isto:
IN= OUT=wlp2s0 SRC=10.100.102.200 DST=224.0.0.22 LEN=40 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 MARK=0x94
que é um endereço multicast... alguma idéia do que estaria causando isso?
Finalmente, tenho vários parecidos com este, que parecem ser solicitações ICMP enviadas para vários lugares ao redor do mundo:
IN= OUT=wlp2s0 SRC=10.100.102.200 DST=151.80.9.69 LEN=138 TOS=0x08 PREC=0xC0 TTL=64 ID=26846 PROTO=ICMP TYPE=3 CODE=3 [SRC=151.80.9.69 DST=10.100.102.200 LEN=110 TOS=0x08 PREC=0x40 TTL=51 ID=48812 DF PROTO=UDP SPT=27209 DPT=8083 LEN=90 ]
Mas o que realmente me intriga é a parte entre colchetes ( SRC=151.80.9.69 PROTO=UDP SPT=27209 DPT=8083
). Significa que o pacote ICMP é uma resposta a uma solicitação UDP para a porta 8083? Devo me preocupar com a possibilidade de uma possível intrusão (ou tentativa de intrusão)? E se sim, há algum motivo pelo qual eu não deva bloquear todo o tráfego UDP de entrada? (Eu só tenho servidores web escutando nas portas 80 e 443, e nenhuma outra porta está aberta - eu verifiquei e verifiquei novamente isso.)
Grato por qualquer ajuda para entender o que estou vendo aqui ...
Eu tenho uma configuração incomum no meu servidor. Temos três portas Ethernet de saída, todas conectadas a uma única interface de ponte que dividimos em duas VLANs:
ip link add veth type bridge
ip link set veth address 01:23:45:67:89:0A
ip link set dev eth1 master veth
ip link set dev eth2 master veth
ip link set dev eth3 master veth
[...]
ip link add veth name veth.10 type vlan id 10
ip link add veth name veth.20 type vlan id 20
ip link add veth.20-local link veth.20 type macvlan mode bridge
[...]
docker network create --driver=macvlan --subnet=192.168.XXX.0/24 --opt com.docker.network.driver.mpu=1500 --gateway 192.168.XXX.1 --opt parent=veth.20-local dockerbr20
Eu tenho uma imagem docker dentro do meu servidor conectada ao veth.20
endereço, que só tem permissão para se comunicar por veth.20
. Existem regras de roteamento e encaminhamento no restante da rede que permitem que a imagem do Docker se comunique com alguns destinos selecionados fora dessa VLAN.
Gostaria de adicionar uma iptables
regra cobrindo pacotes de saída que deixam meu servidor fora da veth.20
interface, independentemente do seu destino. (Alguns pacotes devem permanecer dentro da veth.20
interface; alguns podem ser roteados para outras VLANs.)
As seguintes regras foram tentadas e, por qualquer motivo, não parecem marcar os pacotes que saem veth.20
do contêiner do docker:
iptables -A POSTROUTING -t mangle -o veth.20 -j MARK --set-mark 3
iptables -A PREROUTING -t mangle -i veth.20 -j MARK --set-mark 3
iptables -A POSTROUTING -t nat -o veth.20 -j MARK --set-mark 3
iptables -A PREROUTING -t nat -i veth.20 -j MARK --set-mark 3
iptables -A OUTPUT -t mangle -o veth.20 -j MARK --set-mark 3
iptables -A INPUT -t mangle -i veth.20 -j MARK --set-mark 3
iptables -A FORWARD -i veth.20 -j MARK --set-mark 3
iptables -A FORWARD -o veth.20 -j MARK --set-mark 3
Isto é, iptables -L -n -v -t mangle
e iptables -L -n -v -t nat
não mostra nenhuma dessas regras sendo aplicadas a pacotes de saída veth.20
para um host em outra VLAN.
Confirmei, por meio de ifconfig
, que todos os pacotes da imagem do docker estão saindo do servidor veth.20
; o
iptables -A OUTPUT -t mangle -o veth.20 -j MARK --set-mark 3
a regra se aplica quando envio pacotes para máquinas externas na VLAN 20, do servidor ou da imagem do docker; mas quando envio pacotes pela veth.20
interface do docker que são roteados para um endereço VLAN 10 ou VLAN 30 externo (não ilustrado), nenhuma marca é aplicada.
Acho que esse deveria ser um problema simples, mas nada do que tentei foi capaz de marcar com base na interface que o pacote usa para sair da caixa. o que estou perdendo?
Filtrarei o tráfego de entrada com iptables.
Eu tenho 2 objetivos.
a) Allow HTTPS inbound at port 443.
b) Redirect port 443 to process listening port on 9443.
Não tenho certeza sobre o processamento dessas 2 regras.
Preciso definir minha regra INPUT para ACCEPT HTTPS de entrada para a porta 443 ou 9443?7
Depende se o redirecionamento for feito antes ou depois, eu acho.
Estou tentando executar o docker dentro do Ubuntu 22.04.3 LTS rodando em WSL-2 em minha máquina Windows 10.
Eu segui as instruções aqui . Mas ainda não está funcionando, estou recebendo o seguinte erro quando executo sudo dockerd
:
failed to register "bridge" driver: failed to create NAT chain DOCKER:
iptables failed: iptables -t nat -N DOCKER:
iptables v1.8.7 (legacy): can't initialize iptables table `nat':
Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
(exit status 3)
Quando faço isso, modprobe ip_tables
recebo:
modprobe: FATAL: Module ip_tables not found in directory /lib/modules/4.4.0-22621-Microsoft
Eu tenho um roteador Linux simples com vários NICs e encaminhamento IPv4 habilitado.
O roteador possui dois endereços IP WAN estáticos, atribuídos a uma interface ( eth0
, eth0:0
). (No texto a seguir, ofuscarei os endereços IP públicos reais (257 como um octeto).)
O roteador pode receber ping em ambos os endereços IP WAN externos da Internet externa.
Interfaces:
eth0
: Conexão com a Internet, 134.257.10. 24/10 , gateway 134.257.10.1eth0:0
: Segundo endereço IP nessa interface: 134.257.10. 20/24 _eth1
: LAN 1, 192.168.1.1/24eth2
: LAN2, 192.168.2.1/24eth3
: LAN 3, 192.168.3.1/24
Minha configuração funciona e todos os clientes LAN (LAN 1-3) podem acessar a Internet e são vistos externamente como 134.257.10. 10 . Além disso, tenho dois encaminhamentos de porta de entrada.
Minha tabela NAT do iptables é assim:
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# Port forwarding:
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80
-A PREROUTING -i eth0:0 -p tcp -m tcp --dport 25 -j DNAT --to-destination 192.168.3.33:25
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
Como posso fazer com que os clientes LAN3 ( eth3
) apareçam como 134.257.10. 20 na Internet ( eth0:0
) para conexões de saída em vez de 134.257.10. 10 ( eth0
)?
Eu executo um servidor com um servidor web rodando como um contêiner podman sem root. Isso expõe as portas 10080 e 10443 porque, como um contêiner sem raiz, não é permitido expor as portas 80 e 443.
Para que meu site possa ser acessado de fora, eu uso o ufw como firewall e configurei o encaminhamento de porta lá. Para fazer isso, adicionei as seguintes linhas ao início do /etc/ufw/before.rules
arquivo:
*nat
:PREROUTING ACCEPT [0:0]
-A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 10080
-A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 10443
COMMIT
Até agora tudo funciona.
Agora quero executar outro contêiner que execute um servidor Wireguard. Isso gera o seguinte em seu log e parece definir isso como regras no firewall:
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.13.13.1 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 10.13.13.2/32 dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth+ -j MASQUERADE
Se eu executar o contêiner Wireguard sem o firewall ufw ativado - especialmente sem o encaminhamento de porta definido - tudo funcionará. Posso me conectar a um cliente e seu tráfego é roteado pelo túnel e chega à Internet.
Se, por outro lado, eu ativar o firewall ufw incluindo o encaminhamento de porta definido e depois conectar-me à VPN Wireguard com um cliente, todas as visualizações de página parecerão chegar ao meu próprio servidor - pelo menos recebo mensagens de erro como esta:
This server could not prove that it is www.google.de. Its security certificate comes from <myServer>.de
Como posso configurar o firewall ufw para que
- Solicitações externas para a porta 80 ou 443 são encaminhadas para as portas 10080 ou 10443 e assim chegam ao meu servidor web
- As solicitações do meu cliente VPN chegam à Internet através do túnel WireGuard e não do meu próprio servidor?
(Em outro servidor eu executo o WebServer e o WireGuard no docker - tudo funciona porque o Docker WebServer expõe diretamente as portas 80 e 443 e, portanto, não preciso de nenhum encaminhamento de porta.)
Muito obrigado pela sua ajuda.
Estou tentando entender claramente o que exatamente o br_netfilter
módulo do kernel Linux faz (sei que tem algo a ver com rede).
Minha pergunta simples que estou fazendo aqui é a seguinte:
Qual é um exemplo de algo que POSSO fazer com este módulo habilitado e que NÃO POSSO fazer quando ele está desabilitado? Achei que tinha algo a ver iptables
, mas ao desabilitar/habilitar o módulo sempre consegui executar os mesmos iptables
comandos.
Nota: como eu não tinha certeza de que não mataria meu computador desabilitando um módulo do kernel, criei uma instância de teste do AWS EC2 para testar isso.
EDIT: Para esclarecer, o que eu gostaria de ver é um conjunto simples de etapas, também conhecido como executar comandos X, Y, Z, que quando habilitado, o sistema age conforme o esperado, quando desabilitado, não.
Estou lidando com uma configuração de firewall do servidor RHEL versão 6.4 e o objetivo é permitir que o dispositivo remoto conecte a porta tcp 6162, independentemente do tipo de serviço.
As regras do iptables são mostradas abaixo( iptables -L --line-numbers
), e o serviço iptables foi reiniciado.
num target prot opt source destination
1 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
2 ACCEPT icmp -- anywhere anywhere
3 ACCEPT all -- anywhere anywhere
4 ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
5 ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:6160
6 ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:patrol-coll
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Além disso, configurei a porta que desejo em sytem-config-firewall
, conforme mostrado na figura abaixo.
O estranho é:
Não importa como eu configuro o firewall/iptable, a porta 6162 simplesmente não pode ser aberta. Ele foi testado com cliente telnet de hosts remotos windows/linux que residem na mesma sub-rede IP deste servidor RHEL 6.4. A conexão com a porta 6162 foi recusada, mas outras funcionaram (como a porta 6160).
A porta TCP 6162 parecia ser sempre "patrol-coll", mas estritamente falando, quero permitir que qualquer tipo de serviço conecte a porta 6162, não apenas "patrol-coll". Não sei se o tipo de serviço impacta na conexão...
Alguém pode fornecer algumas dicas para solucionar o problema do lado do sistema operacional da conexão, por favor?
Notas1: a saída de netstat -tulpn
é mostrada abaixo.
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2538/rpcbind
tcp 0 0 192.9.110.1:1521 0.0.0.0:* LISTEN 4806/tnslsnr
tcp 0 0 0.0.0.0:37426 0.0.0.0:* LISTEN 4493/ora_d000_SOGOE
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2917/sshd
tcp 0 0 0.0.0.0:46775 0.0.0.0:* LISTEN 4686/ora_d000_SOGOL
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 2737/cupsd
tcp 0 0 127.0.0.1:10808 0.0.0.0:* LISTEN 3126/veeamservice
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 3007/master
tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN 4046/sshd
tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN 2869/snmpd
tcp 0 0 0.0.0.0:37449 0.0.0.0:* LISTEN 2657/rpc.statd
tcp 0 0 :::111 :::* LISTEN 2538/rpcbind
tcp 0 0 :::6160 :::* LISTEN 2886/veeamdeploymen
tcp 0 0 :::40976 :::* LISTEN 2657/rpc.statd
tcp 0 0 :::22 :::* LISTEN 2917/sshd
tcp 0 0 ::1:631 :::* LISTEN 2737/cupsd
tcp 0 0 ::1:25 :::* LISTEN 3007/master
tcp 0 0 ::1:6010 :::* LISTEN 4046/sshd
udp 0 0 0.0.0.0:111 0.0.0.0:* 2538/rpcbind
udp 0 0 127.0.0.1:2547 0.0.0.0:* 4495/ora_s000_SOGOE
udp 0 0 0.0.0.0:631 0.0.0.0:* 2737/cupsd
udp 0 0 0.0.0.0:1017 0.0.0.0:* 2538/rpcbind
udp 0 0 127.0.0.1:13179 0.0.0.0:* 4660/ora_pmon_SOGOL
udp 0 0 10.50.89.26:123 0.0.0.0:* 2925/ntpd
udp 0 0 192.9.110.1:123 0.0.0.0:* 2925/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 2925/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 2925/ntpd
udp 0 0 0.0.0.0:28426 0.0.0.0:* 4672/ora_lgwr_SOGOL
udp 0 0 0.0.0.0:18843 0.0.0.0:* 2657/rpc.statd
udp 0 0 0.0.0.0:161 0.0.0.0:* 2869/snmpd
udp 0 0 127.0.0.1:22464 0.0.0.0:* 4688/ora_s000_SOGOL
udp 0 0 0.0.0.0:9798 0.0.0.0:* 4479/ora_lgwr_SOGOE
udp 0 0 0.0.0.0:713 0.0.0.0:* 2657/rpc.statd
udp 0 0 127.0.0.1:48982 0.0.0.0:* 4467/ora_pmon_SOGOE
udp 0 0 127.0.0.1:26208 0.0.0.0:* 4686/ora_d000_SOGOL
udp 0 0 127.0.0.1:54112 0.0.0.0:* 4493/ora_d000_SOGOE
udp 0 0 :::111 :::* 2538/rpcbind
udp 0 0 :::1017 :::* 2538/rpcbind
udp 0 0 fe80::20c:29ff:fe74:83b5:123 :::* 2925/ntpd
udp 0 0 fe80::20c:29ff:fe74:83bf:123 :::* 2925/ntpd
udp 0 0 ::1:123 :::* 2925/ntpd
udp 0 0 :::123 :::* 2925/ntpd
udp 0 0 :::46340 :::* 2657/rpc.statd```
Deixe-me começar dizendo que vasculhei a Internet, até empresas das quais comprei o software e já se passaram 5 meses !! Então, estou me voltando para a comunidade, pois meus olhos e cérebro estão sangrando de tanto ler e tentar chegar a lugar nenhum. Em suma, isso pode ser feito, SIM. Aparentemente eu sou muito estúpido para fazer isso, porém pelo menos eu tenho um grande conhecimento de iptables agora :-)
Minha exigência: eu uso protonmail para meu e-mail. Se você não sabia, é tão seguro que você precisa executar um "software ponte" em cada máquina que precisa enviar/receber e-mail. Eu simplesmente quero enviar e-mails de mim mesmo, para mim mesmo, para minha casa inteligente, câmeras, alertas, etc etc. Como você pode imaginar, não consigo instalar este software em 20 dispositivos, muito menos em câmeras !!! Portanto, preciso de um único servidor linux executando este software para atuar como o "hub" de e-mail
Minha rede é 192.168.10.0/24 sem vlans, sem complicações (pfsense como meu roteador/firewall)
Estou usando mxlinux/debian como meu "host de e-mail" 192.168.10.106 IMAP está escutando na porta 1143 SMTP está escutando na porta 1025
Tudo o que eu queria fazer era fazer com que QUALQUER dispositivo na minha rede pudesse usar 192.168.10.106 para enviar e-mails usando SMTP na porta 1025. Achei que seria fácil... !!! Não posso alterá-lo para algo como 0.0.0.0 etc.
Primeiro, você deve saber que entrei em contato diretamente com o protonmail, pois é um serviço de e-mail pago, eles realmente têm técnicos que sabem o que estão fazendo e falam com você. No entanto, eles acham que é um "risco de segurança" permitir que seu serviço ouça em 0.0.0.0, portanto, o código não permitirá que isso seja alterado. Fiz o seguinte no "servidor de email / 192.168.10.106"
Editado
/etc/sysctl.conf
e descomentado na#
frente de net.ipv4.ip_forward=1Atualizada
iptables
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp -s 192.168.10.0/24 --dport 1025 -j DNAT --to-destination 127.0.0.1:1025 sudo iptables -t nat -A POSTROUTING -o lo -p tcp --dport 1025 -j SNAT --to-source 192.168.10.106 sudo iptables -A FORWARD -i eth0 -o lo -p tcp --dport 1025 -j ACCEPT
Salve minhas entradas na reinicialização e vai me perguntar se eu quero salvar minhas tabelas acima, preciso dizer que sim, então vou:
sudo apt install iptables-persistent
Vá para "configuração do firewall" do MX e desative "público, privado e escritório", basicamente desative o firewall
Reinicie o computador
OK, agora listando após uma reinicialização, fica assim. Eu tentei de um computador Windows na minha rede 192.168.10.50 para telnet e como você pode ver, estou vendo pacotes, mas não está funcionando :-( :-( :-( :-( :-( :-( :-( :- ( :-( :-( :-(
sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 15748 packets, 1719K bytes)
pkts bytes target prot opt in out source destination
5 260 DNAT tcp -- eth0 * 192.168.10.0/24 0.0.0.0/0 tcp dpt:1025 to:127.0.0.1:1025
Chain INPUT (policy ACCEPT 15748 packets, 1719K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 730 packets, 73256 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 730 packets, 73256 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT tcp -- * lo 0.0.0.0/0 0.0.0.0/0 tcp dpt:1025 to:192.168.10.106
Este sou eu testando o serviço no computador de e-mail host local
$ telnet 127.0.0.1 1025
Trying 127.0.0.1... Connected to 127.0.0.1.
Escape character is '^]'.
220 127.0.0.1 ESMTP Service Ready
Observe os pacotes descartados no lado recebido da eth0
$ uname -a
Linux email 5.10.0-23-amd64 #1 SMP Debian 5.10.179-2 (2023-07-14) x86_64 GNU/Linux
bob@email:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.10.106 netmask 255.255.255.0 broadcast 192.168.10.255
ether 00:0c:29:63:d5:4f txqueuelen 1000 (Ethernet)
RX packets 126620 bytes 24077186 (22.9 MiB)
RX errors 0 dropped 6447 overruns 0 frame 0
TX packets 30080 bytes 3728557 (3.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 57 bytes 4931 (4.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 57 bytes 4931 (4.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Nenhuma das opções acima funcionou, então tentei variações diferentes. Também encontrei um comando que me sugeriram usar que não pareceu ajudar, mas tentei mesmo assim.
sysctl -w net.ipv4.conf.eth0.route_localnet=1