+ Responder ao Tópico



  1. #1

    Padrão Duvida: algum problema com esse firewall?

    Ola Galera,
    sou novato, ainda estou aprendendo
    apesar de entender um pouco sobre o iptables, nao sou nenhuma fera nele.
    andei vendo varios firewall por ai, peguei o que interessava, fiz algumas modificacoes qdo necessarias.
    ele esta funcionando normalmente aqui no meu servidor de teste em casa!
    porem, tenho a leve impressao que estou sobrepondo regras... e tendo regras que nao sao necessarias.

    por esse motivo, alguem mais intendido, poderia dar uma olhada nele pra min? se a estrutura das regras esta bom? ou se tem algo para tirar?[
    scritp firewall em anexo
    desde ja
    obrigado
    Arquivos Anexos Arquivos Anexos

  2. #2



  3. #3

    Padrão

    muito interessante
    vou analisar ele
    porem, acho q vou demorar demais...^^

    porem,
    se alguem mais experiente estiver disponivel.
    poderia dar uma olhada pra min tbm!? se a estrutura das regras esta bom? se tem algo para tirar ou modificar???

  4. #4

    Padrão

    Cara, aqui no Under-Linux.org a política geralmente é não dar o peixa, mas ensinar como pescar.

    A maioria trabalha/estuda e geralmente não tem muito tempo. Por isso fica difícil tentar ajudar da maneira que você está pedinfo. Como você mesmo falou, analisar um conjunto de regras de filtro de pacotes leva muito tempo. Por isso lhe indiquei o post. Não por ser meu, mas por apresentar uma metodologia que irá lhe poupar esforço já que você ainda não tem uma própria.

    Mas como estou de férias, resolvi dar uma olhada no seu conjunto...

    1 - Você está usando uma política restritiva na chain INPUT. Portanto, não faz sentido ter regras com alvos DROP nessa chain;

    2 - Não adianta ter uma regra impedindo a resposta de pacotes ICMP já que você não tem nenhuma regra permitindo a chegada desses pacotes;

    3 - Você pode sofrer facilmente de um ataque de negação de serviço devido as regras que geram registros. Você deveria usar a match limit para tentar controlar a quantidade de registros gerados;

    4 - Você está liberando todo o tráfego da rede interna para a rede externa. Está ciente disso?

    5 - Na minha opnião você deveria mudar a abordagem do seu filtro de pacotes para stateful. Isso reduziria bastante seu conjunto de regras, consequentemente tornando o filtro mais eficiente;

    Falouz



  5. #5

    Padrão

    Obrigado amigo pelas dicas...
    sou novato ainda, algumas coisas nao entendo... mesmo lendo lendo lendo.. acabamos por precisar de alguem para esclarecer alguns pontos (como, pra que server, o q faz exatamente, qdo usara).

    Um firewall tem que ser adequado para aquele ambiente.
    E quando abri esse topico, nao disse na realidade qual era a intencao do firewall.

    Pois bem, pretendo montar um firewall que tenha uma certa prevencao para o servidor e a rede interna contra ataques/invasao ou virus (se possivel).
    mas ao mesmo tempo, nao bloquei a navegacao interna da rede, nao pode ter bloqueios internos para externos!

    Fiz algumas modificacoes, tirei um bocado de coisa do firewall.
    @PEdroArthurJEdi vc deu umas dicas diante do firewall... com essas novas mudancas, consegui dar uma melhorada nele?

    ### na sua 3 dica, vc disse que eu teria que usar a match limit para tentar controlar a quantidade de registros gerados, seria mais ou menos isso (exemplo):
    iptables -A TROJAN -m limit --limit 15/m -j LOG --log-level 6 --log-prefix "FIREWALL: trojan: "
    iptables -A TROJAN -j DROP
    iptables -A INPUT -p TCP -i $IF_EXTERNA --dport 666 -j TROJAN
    iptables -A INPUT -p TCP -i $IF_EXTERNA --dport 666 -j TROJAN

    Outra coisa PEdroArthurJEdi
    Muito OBRIGADO pelas dicas e atencao!
    Arquivos Anexos Arquivos Anexos
    Última edição por AndrioPJ; 30-04-2009 às 14:42.

  6. #6

    Padrão

    Já melhorou muito... Mas vamos as observações.

    1 - Ping of Death não está relacionado a quantidade de pacotes ICMP que chegam a interface. E aliais, não creio que nenhum sistema atual ainda é vulnerável a esses ataques;

    2 - A regra que (supostamente) está protegendo contra port scanner, pode levar o seu sistema a DoS: depois do 20 pacote Syn casar com a regra, todos os outros passarão despercebidos;

    3 - Usar o target REJECT significa que sua máquina alocará recursos para poder sinalizar a fonte problemas. Portanto, mais uma vez você poderá sofrer de um DoS, estando esse problema relacionado a quantidade de pacotes que chegarão a sua interface e o throughput geral do seu filtro;

    4 - A chain VALID_CHECK está inútil pois não é referenciada por nenhuma regra presente nas chains padrão;

    5 - Mais uma vez: numa política restritiva é inútil ter regras com targets DROP. A menos que deseje fazer uma espécie de contabilidade. Então, todas as regras com target DROP que estão nas chains INPUT e FORWARD são inúteis, visto que a política dessas é restritiva e se tem como objetivo principal a eficiência;

    Eu re-escreveria suas regras da seguinte maneira:
    iptables -P INPUT DROP
    iptables -P FORWARD DROP
    iptables -P OUTPUT ACCEPT

    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


    # Obeservação no final...
    iptables -N SERVICOS
    iptables -A SERVICOS -p tcp --dport 80 -j RETURN
    iptables -A SERVICOS -p udp --dport 53 -j RETURN
    iptables -A SERVICOS -j DROP

    iptables -A FORWARD -j SERVICOS

    for i in `cat $MACLIST`; do
    IPSOURCE=`echo $i | cut -d ';' -f 1`
    MACSOURCE=`echo $i | cut -d ';' -f 2`

    iptables -t filter -A FORWARD -m mac --mac-source $MACSOURCE -d 0/0 -s $IPSOURCE -p tcp --syn -m state --state NEW -j ACCEPT
    done

    iptables -t nat -A PREROUTING -s 172.167.0.0/24 -p tcp -d ! 200.201.0.0/16 --dport 80 -j REDIRECT --to-port 3128

    iptables -t nat -A POSTROUTING -o $INTERNET -j MASQUERADE

    iptables -t filter -A INPUT -i lo -j ACCEPT
    iptables -A INPUT -p tcp --dport 2210 --syn -m state --state NEW -j ACCEPT
    Não inclui aqui limites para a saída de pacotes visto que acho mais eficiente o uso de um mecanismo de controle de tráfego (HTB).

    Devido as polítias de onde atuo, sempre limitamos o conjunto de sevicões que estarão disponíveis. Na chain SERVICOS você poderá colocar todos os serviços que serão liberados. No conjunto acima, essa chain será chamada para verificar se o serviço de destido no pacote é permitido na rede. E quem sabe você pode até fazer uma automatização, que nem está na sua MACLIST.



  7. #7

    Padrão

    Ola caro @PEdroArthurJEdi
    acabei de chegar do trabalho, estava alinhando uma antena, que com a chuva saiu do lugar!

    sabe, fiz 20 anos a pouco tempo
    trabalho com informatica a menos de 1 ano
    comecei com servidor a menos de 1 mes.

    essas dicas que me deu, foi mtooo bem recebida
    aprendi bastante.
    muita coisa que lendo, nao entendia direito... comecei a colocar em ordem o "no qdo sera utilizada" e "o pq utilizar".
    amanha, irei ver com mais calma as novas modificacoes, estudar e testar as regras mais um pouco...
    trabalhar mais ainda.
    mas agora, quase meia noite, vou dar uma olhada na minha cama^^

    no entanto, nessas novas dicas e nas anteriores, ja digo que as seguintes duvidas surgiram:

    1:
    iptables -N SERVICOS
    iptables -A SERVICOS -p tcp --dport 80 -j RETURN
    iptables -A SERVICOS -p udp --dport 53 -j RETURN
    iptables -A SERVICOS -j DROP
    foi criado um novo chain com o nome servicos
    adicionou uma nova regra ao chain Servicos, com o protocolo tcp na porta 80 e o udp na porta 53.
    porem nao entendi o RETURN???? nao li sobre ele ainda.
    no final vc drop o restante.

    2:
    nessas suas regras, poderia ser adicionado aquelas regras do kernel?

    echo "1" > /proc/sys/net/ipv4/conf/default/rp_filter
    echo "1" > /proc/sys/net/ipv4/tcp_syncookies
    echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
    echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
    echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
    echo "1" > /proc/sys/net/ipv4/conf/all/secure_redirects
    echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
    echo "0" > /proc/sys/net/ipv4/tcp_timestamps
    echo "1" > /proc/sys/net/ipv4/ip_dynaddr
    poderia ser adicionadas?

    3:
    o Sr. disse:
    3 - Você pode sofrer facilmente de um ataque de negação de serviço devido as regras que geram registros. Você deveria usar a match limit para tentar controlar a quantidade de registros gerados;
    poderia me dar um exemplo confiavel para se gerar os logs? o que achei sobre o match limit foi mto pouco, e quase nao entendi...
    Última edição por AndrioPJ; 01-05-2009 às 00:36.

  8. #8

    Padrão

    Se vai realmente adentrar na área de infra-estrutura de servidores de rede, recomendo você dar uma lida no Guia Foca GNU/Linux. Uma das melhores referências...

    Mas voltando...

    O target RETURN serve para voltar ao fluxo anterior de checagem de regras. Explicando melhor: eu coloquei uma regra que diz:
    iptables -A FORWARD -j SERVICOS
    Então, quando o controle de checagem de regras chega nessa regra, ele é desviado para a chain SERVICOS. O RETURN vai fazer justamente que o controle volte para a chain FORWARD. Ou seja, caso o serviço esteja autorizado, o controle voltará a chain FORWARD e irá verificar agora se a o IP e MAC também estão.

    A regra
    iptables -A SERVICOS -j DROP
    serva para que, se o serviço não estiver na lista, ele será bloqueado. A principal razão para tal abordagem é que em chains do usuário não é possível utilizar uma política.

    Quanto ao segundo questionamento: sim. Eu não coloquei apenas para simplificar pois esses ajustes não fazem parte do filtro de pacotes. Podem até ajudar no seu funcionamento, mas não fazem parte.

    Quanto a terceira,
    iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -m limit --limit 3/minute -j LOG --log-prefix "Xmas Scan "
    Na regra acima serão gerados 3 entradas por minuto.

    ps: Chamar de "Sr." lasca ... Sou 2 anos menos novo que você...



  9. #9

    Padrão

    Hum...
    Desculpa pelo Sr... ^^

    seria basicamente isso:
    antes a regra era: iptables -A INPUT -i $INTERNET -p tcp --dport 21 -j LOG --log-prefix "FIREWALL:

    se eu acresentar o limit ficaria:
    iptables -A INPUT -i $INTERNET -p tcp --dport 21 -m limit --limit 3/minute -j LOG --log-prefix "FIREWALL:

    cria uma regra normalmente
    iptables -A INPUT -i $INTERNET -p tcp --dport 21

    acresenta o limit
    da a acao de LOG
    e um "Nome para o log" (Prefixo)

    existe alguma maneira de se registrar um determinado log em outro local..?
    para ser mais claro, nao é necessário checar por trojans se adotamos a política de tudo fechado.
    Mas, podemos querer verificar mesmo assim, para poder registrar um log mais específico, e ajudar a indentificar a maquina na rede com virus?
    Última edição por AndrioPJ; 01-05-2009 às 14:18.

  10. #10

    Padrão

    Bom
    aprendi mto nesses ultimos dias com relacao ao iptables
    consegui entender bem melhor as regras que antes nao conseguia...
    Agradeco novamente ao @PEdroArthurJEdi
    sao poucos que se aprontam em ajudar de tal forma.

    creio que agora ele esteja bem melhor que antes...rs...rs...rs...
    precisava mesmo era de uma organizacao!!!

    sera que ainda existe algo a se modificar ou acresentar?
    Arquivos Anexos Arquivos Anexos



  11. #11

    Padrão

    As seguintes regras são inúteis:
    iptables -t filter -A FORWARD -d $IPSOURCE -s 0/0 -j ACCEPT
    iptables -t nat -A POSTROUTING -s $IPSOURCE -o $REDE_INTERNA -j MASQUERADE

    iptables -A INPUT -j DROP
    iptables -A FORWARD -j DROP
    A seguinte regra está dizendo que seu filtro deve aceitar qualquer pacote vindo de uma máquina da rede interna:
    iptables -t filter -A INPUT -s $IPSOURCE -d 0/0 -m mac --mac-source $MACSOURCE -j ACCEPT
    É esse comportamente mesmo que você deseja?

  12. #12

    Padrão

    A seguinte regra está dizendo que seu filtro deve aceitar qualquer pacote vindo de uma máquina da rede interna:iptables -t filter -A INPUT -s $IPSOURCE -d 0/0 -m mac --mac-source $MACSOURCE -j ACCEPT

    É esse comportamente mesmo que você deseja?
    com relacao a aceitar qualquer pacote da rede interna... sim
    aqui tenho q ter regra o maximo possivel restritiva, contra invasao, etc e tal!
    mas nao posso impedir em nada a rede interna, ela pode acessar qualquer site e usar qualquer programa!
    Por isso, alem das portas importantes no servidor, estou querendo ver quais portas da para ficar gerando logs, para poder indentificar mais facilmente a maquina interna com trojan/virus.
    meio complicado nao acha?

    As seguintes regras são inúteis:iptables -t filter -A FORWARD -d $IPSOURCE -s 0/0 -j ACCEPT
    iptables -t nat -A POSTROUTING -s $IPSOURCE -o $REDE_INTERNA -j MASQUERADE

    iptables -A INPUT -j DROP
    iptables -A FORWARD -j DROP
    a 1 regras, faz parte do meu controle de acesso, qual maquina pode ou nao acessar web.
    se eu retiro qualquer regra desse controle, as maquinas nao navegam mais!

    a 2 e 3 regras, fecham o script, dropa todo o restante...
    nao precisa dela?



  13. #13

    Padrão

    Citação Postado originalmente por mascaraapj Ver Post
    com relacao a aceitar qualquer pacote da rede interna... sim
    aqui tenho q ter regra o maximo possivel restritiva, contra invasao, etc e tal!
    mas nao posso impedir em nada a rede interna, ela pode acessar qualquer site e usar qualquer programa!
    Mas você não está dizendo isso... Você está dizendo que a máquina onde roda o filtro de pacotes deve receber qualquer pacote vindo da rede interna.

    O que você quer fazer você fez, mas com a regra presente na chain FORWARD. Recomendo você retirar essa regra.

    Citação Postado originalmente por mascaraapj Ver Post
    Por isso, alem das portas importantes no servidor, estou querendo ver quais portas da para ficar gerando logs, para poder indentificar mais facilmente a maquina interna com trojan/virus.
    meio complicado nao acha?
    Para isso você terá que ter regras tanto na chain INPUT quanto na chain FORWARD. Recomendo você criar uma chain e colocar as regras de registro e a partir das chain INPUT e FORWARD você a chama.

    Citação Postado originalmente por mascaraapj Ver Post
    a 1 regras, faz parte do meu controle de acesso, qual maquina pode ou nao acessar web.
    se eu retiro qualquer regra desse controle, as maquinas nao navegam mais!
    Tem certeza? Se você está usando o módulo state, essas regras são desnecessárias.

    Citação Postado originalmente por mascaraapj Ver Post
    a 2 e 3 regras, fecham o script, dropa todo o restante...
    nao precisa dela?
    Não... No inicio você já configurou seu filtro como restritivo (opção -P CHAIN DROP).

  14. #14

    Padrão

    verdade... nao faz diferenca mesmo...
    agora sim, creio q tenha um firewall bem melhor que antes para o ambiente que estou.

    adicionei no meu squid.conf, um script contra malware...
    para melhorar um pouquinho mais a seguranca da rede interna no acesso a web.

    Obrigado pela atencao



  15. #15

    Padrão

    Ola amigo.
    Sera que poderia dar novamente, mais uma ajudinha?
    Com o squid, eu consigo bloquear o acesso da rede interna a determinados sites.
    Porem, com base nesse firewall atual que estou usando, gostaria de saber... como poderia fazer para que a rede interna nao acesse determinados IPs externos ou dominios?

    seria algo como:
    iptables -A FORWARD -d 200.x.x.x -j DROP


    ?
    Arquivos Anexos Arquivos Anexos

  16. #16

    Padrão

    Isso mesmo... Porém as regras de bloqueio de domínio deveriam vir antes das regras de controle por IP/MAC.