Acabei de descobrir um problema de segurança, estava revisando minhas regras de tabelas IP e descobri que não havia regra para o tráfego DHCP (tenho DROP-policy para todas as cadeias), mas ainda recebo endereço IP, máscara de sub-rede etc. do servidor DHCP. Então, eu stater para olhar para ele, e depois de executar o wireshark e algumas pesquisas, descobri que DHCPCD usa soquetes AF_PACKETs, então ele ignora a pilha TCP / IP (?).
Eu olhei mais fundo nisso, escrevi um programa curto em C, usando (AF_PACKET, SOCK_RAW, ETH_P_ALL) com HW estático, IP e cabeçalho TCP (apenas para fins de teste). Tente exigir dados de um servidor que não esteja na lista de permissões do IPTables. Eu tenho um pequeno coração saltando, quando descobri que o IPTables não tinha chance de bloqueá-lo.
Estou usando o Debian 8 «Jessie». E para vocês que pensam que eu negligenciei algo em minhas regras do IPTables, eu tenho regras muito restritas, onde cada alvo é muito específico, filtrado por interfaces, endereços IP, portas de destino, protocolos, ctstates, etc.
Existe mais alguém que saiba mais sobre esse problema? Ou tem alguma solução sobre como bloquear esse tráfego ou forçar todo o tráfego a passar por TCP / IP-stack e IPTables antes de sair do host?
Você precisa de privilégios de root (ou pelo menos de CAP_NET_RAW) para usar AF_PACKET. Em geral, é difícil impedir que processos raiz façam qualquer coisa. A melhor solução é não executar processos não confiáveis.
Uma alternativa seria executar todos os processos (raiz) em um namespace de rede separado para que todo o tráfego tenha que ser roteado pelo host. Dessa forma, você poderia forçar (namespace) tráfego AF_PACKET para percorrer a pilha IP (do host).
Certamente tem implicações a serem observadas. É irritante, embora seja um caso relativamente especial.
AF_PACKET é uma operação privilegiada. Isso significa que não é algo que seus usuários sem privilégios possam ter problemas ao usar.
O software que o utiliza será semelhante a um servidor DHCP - infra-estrutura de rede de baixo nível - caso contrário, seria capaz de usar a interface normal e mais simples. Como um administrador de sistema, você certamente saberá se instalou um servidor DHCP. O mesmo se aplica em outros casos também.
É possível definir um firewall com várias "zonas" ou semelhantes usando o iptables, por exemplo, em uma ação de caixa do Linux que atua como um firewall entre sua rede e a internet. Nesse caso, como o DHCPD etc ignora esse firewall, você deve configurar sua política no DHCPD, etc. separadamente. Por exemplo,
If more than one network interface is attached to the system, but the DHCP server should only be started on one of the interfaces, configure the DHCP server to start only on that device. In /etc/sysconfig/dhcpd, add the name of the interface to the list of DHCPDARGS:
# Command line options here DHCPDARGS=eth0This is useful for a firewall machine with two network cards. One network card can be configured as a DHCP client to retrieve an IP address to the Internet. The other network card can be used as a DHCP server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users can not connect to the daemon via the Internet.
- link
AFAICT, não há nenhuma opção mais refinada para o ISC DHCPD. Se você quisesse um controle mais refinado, teria que implementar isso no nível da rede ... ao usar retransmissões DHCP de sua escolha, que fazer fornecem um controle mais refinado. Desde o receptor DHCP inicial precisa estar na mesma rede que o cliente DHCP. Como apontado por Hauke Laging, um servidor Linux é capaz de criar redes virtuais de várias maneiras, e. não deve ser necessário recorrer a uma caixa de firewall fisicamente separada, a menos que você realmente queira:).
Você deveria estar com medo de executar o sniffer de pacotes Wireshark, porque ele está executando um monte de parsers escritos em uma linguagem insegura de memória. E o tráfego que recebe não será limitado pelo firewall. link
É um pouco ambíguo, mas parece que o seu programa de teste enviou um pacote que teria sido bloqueado pelo seu firewall iptables. Ou seja você está filtrando pacotes de saída.
Esta não é a configuração mais comum. Esta pergunta não parece ser super específica sobre o modelo de ameaça sendo usado, e por que esta configuração incomum está sendo usada, então eu não tenho certeza sobre qual conselho eu posso dar.
Se você executar um programa com privilégios que incluam o CAP_NET_RAW, então sim, ele tem a capacidade de enviar pacotes que não são afetados pelo iptables. Mas, da mesma forma, se você executar um programa com privilégios que incluam o CAP_NET_ADMIN, ele poderá instalar uma regra do iptables que lhe permita enviar o pacote que quiser:).