Comentários do Blog

  1. Avatar de Magnun
    pois é, o sourceforge é muito bom! Mas também tem outros, o googlecode, lauchpad...

    Mas com SSH... essa é novadade pra mim!
  2. Avatar de osmano807
    Então, o povo do VOL estava querendo fazer uma distro, Linux: Distro VOL [Comunidade] , mas pararam, até sugeri para já registrar o projeto no sourceforge devido a suas facilidades, mas o projeto parou.
  3. Avatar de PEdroArthurJEdi
    Citação Postado originalmente por Dedao
    Ola Pedro.
    Obrigado pelas respostas
    De nada cara, pra isso que serve o Under-Linux.org! E é bem mais divertido quando dicutimos nossas opniões!

    Citação Postado originalmente por Dedao
    8 - Você acha importante deixar a chain output da tabela filter como DROP ? Eu normalmente deixo apenas o INPUT e o FORWARD como DROP, e o OUTPUT deixo ACCEPT e não tenho muitos problemas.
    Isso é um ponto bem pessoal, ligado ao seu nível de paranoia. Mas vamos a um cenário pra ficar mais claro minha opnião.

    Seja um servidor de rede rodando FTP e HTTP. Assuma as seguintes regras:
    iptables -P INPUT DROP
    iptables -P FORWARD DROP
    iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
    iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
    Veja que a política da chain OUTPUT está como DROP.

    Agora imagine que num dia X aparece uma falha no serviço de FTP. Agora imagine que antes da falha ser relatada e corrigida surge um exploit para a falha (0-day). Um atacante utiliza o exploit contra o serviço de FTP e consegue acesso ao terminal com os previlégios do usuário ao qual o serviço estava associado.

    Agora, imagine que o kernel também está com uma falha e existe um exploir disponível. O usuário poderá fazer:
    e executar o exploit contra sua máquina.

    Porém, se seu conjunto de regras fosse:
    iptables -P INPUT DROP
    iptables -P OUTPUT DROP
    iptables -P FORWARD DROP

    iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
    iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT

    iptables -A OUTPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
    Veja que não há regras que aceitem novas conexões saindo do servidor, portanto a conexão maliciosa nunca seria realizada. E também não adianta somente se valer dessa técnica. Atualize seus servidores.

    Como eu disse, vai depender do seu nível de paranóia.

    Citação Postado originalmente por Dedao
    Em relação a questão 9, ficou claro sim. Mas me surgiu uma outra dúvida.
    Eu seria obrigado a ter a regra

    iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW -j ACCEPT no final do firewall, ou apenas tendo a regra

    iptables -A INPUT -p tcp --dport $PORTA -m state --state RELATED,ESTABLISHED -j ACCEPT bastaria ?
    Você tem que ter regras para aceitar novas conexões. Quanto falei regras no estilo "X", quis dizer que $PORTA deve ser substituido pela porta do serviço que se deseja liberar. Como no exemplo que dei acima, temos duas portas, a 21 e a 80, logo, temos duas regras com o template citado:
    iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW -j ACCEPT

    iptables -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
    iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
    Citação Postado originalmente por Dedao
    Em relação a esse mesmo assunto, teria problema se eu utilizar apenas a regra iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT, ou isso poderia comprometer a segurança ?
    Sim teria, porém necessitaria de uma regra por serviço. Digamos que se faça:
    iptables -A INPUT -p tcp --dport 21 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
    iptables -A INPUT -p tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
    VEja que não haveria proveito do sistema de conntrack pois teriamos uma regra para cada serviço, e no caso de N regras, todos os pacote de uma conexão teria que passar por P regras até ser aceito, onde P é a posição da regra que o aceita, estando alguma conexão sempre necessitando a passar por um número de regras que se aproxime de N. Ao passao que, da forma como citado na outra resposta, após o primeiro pacote ser aceito, somente uma regra seria avaliada. Entendeu meu ponto de vista?
  4. Avatar de Dedao
    Ola Pedro.
    Obrigado pelas respostas
    Bom, me desculpe, acho que eu mesmo me confundi na questão 7...eheh...desconsidere.

    Na pergunta 8, também me passei. Segue a minha duvida de forma mais clara:

    8 - Você acha importante deixar a chain output da tabela filter como DROP ? Eu normalmente deixo apenas o INPUT e o FORWARD como DROP, e o OUTPUT deixo ACCEPT e não tenho muitos problemas.

    Em relação a questão 9, ficou claro sim. Mas me surgiu uma outra dúvida.
    Eu seria obrigado a ter a regra

    iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW -j ACCEPT no final do firewall,
    ou apenas tendo a regra

    iptables -A INPUT -p tcp --dport $PORTA -m state --state RELATED,ESTABLISHED -j ACCEPT bastaria ?
    Em relação a esse mesmo assunto, teria problema se eu utilizar apenas a regra iptables -A INPUT -p tcp --dport $PORTA -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT, ou isso poderia comprometer a segurança ?
    Atualizado 10-03-2009 em 07:48 por Dedao
  5. Avatar de Laedrus
    Um tempo atrás li que já está em uso em UM prédio na praia de botafogo, Rio de Janeiro =)

    Nunca tive a chance de ir lá perguntar como é, mas dá pra imaginar hahaha
  6. Avatar de Magnun
    Eu mereço... Sérgio tu não presta
  7. Avatar de magnusrk8
    Citação Postado originalmente por info24hs
    Opa, assisti e enviei a seguinte pergunta: Monitorar conversar do msn é crime?

    Não consegui ver se foi respondida, a conexão caiu na hora e ao voltar tenho a impressão que estava sendo respondida...
    Foi respondida sim assisti o prog todo, show de bola parabens..
  8. Avatar de Magnun
    Massa, vou dar uma olhada! vlw
  9. Avatar de Laedrus
    Ah maneiro, mas de repente pode ser feito até por SSH, já vi muita gente fazendo por exemplo checagem remota de Nagios do tipo

    ssh [email protected] -C "sysusers" >> report.txt

    Mas um cliente que pudesse ser adaptado como plugin do Nagios =) mas primeiro quero melhorar o principal, que tem muito a evoluir ainda.

    Linux System Users Information Report

    Já dá pra ver o relatório, o código até a noite vai pra lá!
  10. Avatar de Magnun
    A idéia é você ter um cliente pra acessar o "servidor" e emitir relatórios, visualizar a utilização, fazer configurações e etc...

    Quando tiver pronto põe o link do sourceforge ai!