existe algum procedimneto ou comandos
Para verificar falhas no servidor use o nessus. http://www.nessus.org/download/
Tem o pacote para Fedora 5, 6 e 7.
Em 28/08/07, Adere - Levi / Analista de Suporte Linux levi.alves@adere.com escreveu:
existe algum procedimneto ou comandos
--
Levi Leopoldino Alves T.I. - (19)2104-0700 Adere Produtos Auto-Adesivos Ltda visite nosso site http://www.adere.com
Esta mensagem tem caráter confidencial, se você recebeu-a por engano, por favor delete-a imediatamente.
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
Olá,
O nessus é razoavelmente bom para serviços de rede e só funciona bem se você tiver um firewall sem regras no caminho entre a máquina com o nessus e a máquina a ser analisada (nem sempre pode instalar o nessus no servidor a ser analisado).
Além disso, há outras coisas que podem ser feitas e o nessus não faz, por exemplo, ele não vê se todos as atualizações de segurança foram aplicadas e nem se você tem uma boa política de senhas na máquina. Mas em todo o caso, o nessus é algo bom para se ter um começo :)
Dependendo da criticidade do servidor, tem muita coisa que pode ser feita ... mas nem sempre vale a pena ($$$) o investimento.
[]´s Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Para verificar falhas no servidor use o nessus. http://www.nessus.org/download/
Tem o pacote para Fedora 5, 6 e 7.
Em 28/08/07, Adere - Levi / Analista de Suporte Linux levi.alves@adere.com escreveu:
existe algum procedimneto ou comandos
--
Levi Leopoldino Alves T.I. - (19)2104-0700 Adere Produtos Auto-Adesivos Ltda visite nosso site http://www.adere.com
Esta mensagem tem caráter confidencial, se você recebeu-a por engano, por favor delete-a imediatamente.
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
Mais neste caso o mais obvio é que o firewall esteja desativado para esse proposito. Eu ainda desconheço uma ferramenta tão util quanto o nessus. Picoloto, você tem idéia de uma outra ferramenta?
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Olá,
O nessus é razoavelmente bom para serviços de rede e só funciona bem se você tiver um firewall sem regras no caminho entre a máquina com o nessus e a máquina a ser analisada (nem sempre pode instalar o nessus no servidor a ser analisado).
Além disso, há outras coisas que podem ser feitas e o nessus não faz, por exemplo, ele não vê se todos as atualizações de segurança foram aplicadas e nem se você tem uma boa política de senhas na máquina. Mas em todo o caso, o nessus é algo bom para se ter um começo :)
Dependendo da criticidade do servidor, tem muita coisa que pode ser feita ... mas nem sempre vale a pena ($$$) o investimento.
[]´s Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Para verificar falhas no servidor use o nessus. http://www.nessus.org/download/
Tem o pacote para Fedora 5, 6 e 7.
Em 28/08/07, Adere - Levi / Analista de Suporte Linux <
levi.alves@adere.com>
escreveu:
existe algum procedimneto ou comandos
--
Levi Leopoldino Alves T.I. - (19)2104-0700 Adere Produtos Auto-Adesivos Ltda visite nosso site http://www.adere.com
Esta mensagem tem caráter confidencial, se você recebeu-a por engano, por favor delete-a imediatamente.
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
Olá,
Para vulnerabilidades remotas, o nessus é digamos "a melhor relação custo X benefício". Ele procura as vulnerabilidades mais comuns, mas não procura todas. O nessus não faz certas coisas como ver se o ssh está permitindo acesso remoto de root e a senha do mesmo é "root". Ele também não consegue ver se determinado usuário está no grupo wheel e pode executar "sudo su -". Entendeu o que tentei mostrar? Este tipo de coisa é muito mais comum do que se possa imaginar e o nessus não faz.
Ah sim, não é óbvio desativar o firewall pois para uma análise real de vulnerabilidades o firewall deve estar ativo pois um possível invasor não vai te pedir para desativar o firewall para invadir, ele vai tentar invadir do jeito que a rede está. Uma análise dessas poderia descobrir regras de firewall incorretas e depois disso descobrir configurações incorretas no servidor.
O ideal é ter um checklist a ser seguido e aplicar tudo ou o máximo de regras possíveis e para isso, até onde eu saiba, não tem uma ferramenta que "faz tudo".
Se quiserem/precisarem, eu posso passar algumas dicas genéricas e tirar dúvidas mas infelizmente não posso passar o checklist que conheço devido a um contrato que tenho assinado com a empresa onde trabalho e outro com a empresa onde trabalhei até recentemente :(
Uma sugestão é procurar na internet por "linux security enforcing", "linux security hardening" e coisas do tipo. Depois, procurar fazer o mesmo com os serviços que a máquina tem disponível (ssh e apache por exemplo). Tudo o que tem no checklist de onde trabalho tem na internet, mas não está tudo concentrado no mesmo lugar.
[]'s
Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Mais neste caso o mais obvio é que o firewall esteja desativado para esse proposito. Eu ainda desconheço uma ferramenta tão util quanto o nessus. Picoloto, você tem idéia de uma outra ferramenta?
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Olá,
O nessus é razoavelmente bom para serviços de rede e só funciona bem se você tiver um firewall sem regras no caminho entre a máquina com o nessus e a máquina a ser analisada (nem sempre pode instalar o nessus no servidor a ser analisado).
Além disso, há outras coisas que podem ser feitas e o nessus não faz, por exemplo, ele não vê se todos as atualizações de segurança foram aplicadas e nem se você tem uma boa política de senhas na máquina. Mas em todo o caso, o nessus é algo bom para se ter um começo :)
Dependendo da criticidade do servidor, tem muita coisa que pode ser feita ... mas nem sempre vale a pena ($$$) o investimento.
[]´s Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Para verificar falhas no servidor use o nessus. http://www.nessus.org/download/
Tem o pacote para Fedora 5, 6 e 7.
Em 28/08/07, Adere - Levi / Analista de Suporte Linux
<levi.alves@adere.com >
escreveu:
existe algum procedimneto ou comandos
--
Levi Leopoldino Alves T.I. - (19)2104-0700 Adere Produtos Auto-Adesivos Ltda visite nosso site http://www.adere.com
Esta mensagem tem caráter confidencial, se você recebeu-a por engano, por favor delete-a imediatamente.
-- Fedora-users-br mailing list Fedora-users-br@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
Geralmente eu faço com que no final do dia seja mandado para mim um log via email para que eu possa ver se houve algum tipo de ataque ou algo parecido. Até hoje so passei por um aperto, mais resolvi muito rapido, pois tinha visto que em um horario (de madruga) um cara tinha tentado atacar meu servidor com força bruta, mais vi de que forma ele estava tentando e mudei logo. Isso foi a mais de meses e até hoje não sofri mais nenhum tipo de ataque :). Eu sempre usei o nessus por não encontrar uma outra ferramenta que pudesse me trazer pelo menos um resultado sabe? Ja tenho pesquisado sobre isso a tempos, e realmente não encontrei nenhuma. Então prefiro ficar ligado todos os dias no que aconteceu pela madrugada ou de dia mesmo.
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Olá,
Para vulnerabilidades remotas, o nessus é digamos "a melhor relação custo X benefício". Ele procura as vulnerabilidades mais comuns, mas não procura todas. O nessus não faz certas coisas como ver se o ssh está permitindo acesso remoto de root e a senha do mesmo é "root". Ele também não consegue ver se determinado usuário está no grupo wheel e pode executar "sudo su -". Entendeu o que tentei mostrar? Este tipo de coisa é muito mais comum do que se possa imaginar e o nessus não faz.
Ah sim, não é óbvio desativar o firewall pois para uma análise real de vulnerabilidades o firewall deve estar ativo pois um possível invasor não vai te pedir para desativar o firewall para invadir, ele vai tentar invadir do jeito que a rede está. Uma análise dessas poderia descobrir regras de firewall incorretas e depois disso descobrir configurações incorretas no servidor.
O ideal é ter um checklist a ser seguido e aplicar tudo ou o máximo de regras possíveis e para isso, até onde eu saiba, não tem uma ferramenta que "faz tudo".
Se quiserem/precisarem, eu posso passar algumas dicas genéricas e tirar dúvidas mas infelizmente não posso passar o checklist que conheço devido a um contrato que tenho assinado com a empresa onde trabalho e outro com a empresa onde trabalhei até recentemente :(
Uma sugestão é procurar na internet por "linux security enforcing", "linux security hardening" e coisas do tipo. Depois, procurar fazer o mesmo com os serviços que a máquina tem disponível (ssh e apache por exemplo). Tudo o que tem no checklist de onde trabalho tem na internet, mas não está tudo concentrado no mesmo lugar.
[]'s
Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Mais neste caso o mais obvio é que o firewall esteja desativado para
esse
proposito. Eu ainda desconheço uma ferramenta tão util quanto o nessus. Picoloto, você tem idéia de uma outra ferramenta?
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Olá,
O nessus é razoavelmente bom para serviços de rede e só funciona bem se você tiver um firewall sem regras no caminho entre a máquina com o nessus e a máquina a ser analisada (nem sempre pode instalar o nessus no servidor a ser analisado).
Além disso, há outras coisas que podem ser feitas e o nessus não faz, por exemplo, ele não vê se todos as atualizações de segurança foram aplicadas e nem se você tem uma boa política de senhas na máquina. Mas em todo o caso, o nessus é algo bom para se ter um começo :)
Dependendo da criticidade do servidor, tem muita coisa que pode ser feita ... mas nem sempre vale a pena ($$$) o investimento.
[]´s Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Para verificar falhas no servidor use o nessus. http://www.nessus.org/download/
Tem o pacote para Fedora 5, 6 e 7.
Em 28/08/07, Adere - Levi / Analista de Suporte Linux
<levi.alves@adere.com >
escreveu:
existe algum procedimneto ou comandos
--
Levi Leopoldino Alves T.I. - (19)2104-0700 Adere Produtos Auto-Adesivos Ltda visite nosso site http://www.adere.com
Esta mensagem tem caráter confidencial, se você recebeu-a por
engano,
por favor delete-a imediatamente.
-- Fedora-users-br mailing list Fedora-users-br@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
Olhem esse link, OSSEC HIDS, muito bom...
http://www.dicas-l.com.br/dicas-l/20070628.php
Em 28/08/07, Cristiano Furtado jasonnfedora@gmail.com escreveu:
Geralmente eu faço com que no final do dia seja mandado para mim um log via email para que eu possa ver se houve algum tipo de ataque ou algo parecido. Até hoje so passei por um aperto, mais resolvi muito rapido, pois tinha visto que em um horario (de madruga) um cara tinha tentado atacar meu servidor com força bruta, mais vi de que forma ele estava tentando e mudei logo. Isso foi a mais de meses e até hoje não sofri mais nenhum tipo de ataque :). Eu sempre usei o nessus por não encontrar uma outra ferramenta que pudesse me trazer pelo menos um resultado sabe? Ja tenho pesquisado sobre isso a tempos, e realmente não encontrei nenhuma. Então prefiro ficar ligado todos os dias no que aconteceu pela madrugada ou de dia mesmo.
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Olá,
Para vulnerabilidades remotas, o nessus é digamos "a melhor relação custo X benefício". Ele procura as vulnerabilidades mais comuns, mas não procura todas. O nessus não faz certas coisas como ver se o ssh está permitindo acesso remoto de root e a senha do mesmo é "root". Ele também não consegue ver se determinado usuário está no grupo wheel e pode executar "sudo su -". Entendeu o que tentei mostrar? Este tipo de coisa é muito mais comum do que se possa imaginar e o nessus não faz.
Ah sim, não é óbvio desativar o firewall pois para uma análise real de vulnerabilidades o firewall deve estar ativo pois um possível invasor não vai te pedir para desativar o firewall para invadir, ele vai tentar invadir do jeito que a rede está. Uma análise dessas poderia descobrir regras de firewall incorretas e depois disso descobrir configurações incorretas no servidor.
O ideal é ter um checklist a ser seguido e aplicar tudo ou o máximo de regras possíveis e para isso, até onde eu saiba, não tem uma ferramenta que "faz tudo".
Se quiserem/precisarem, eu posso passar algumas dicas genéricas e tirar dúvidas mas infelizmente não posso passar o checklist que conheço devido a um contrato que tenho assinado com a empresa onde trabalho e outro com a empresa onde trabalhei até recentemente :(
Uma sugestão é procurar na internet por "linux security enforcing", "linux security hardening" e coisas do tipo. Depois, procurar fazer o mesmo com os serviços que a máquina tem disponível (ssh e apache por exemplo). Tudo o que tem no checklist de onde trabalho tem na internet, mas não está tudo concentrado no mesmo lugar.
[]'s
Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Mais neste caso o mais obvio é que o firewall esteja desativado para
esse
proposito. Eu ainda desconheço uma ferramenta tão util quanto o
nessus.
Picoloto, você tem idéia de uma outra ferramenta?
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Olá,
O nessus é razoavelmente bom para serviços de rede e só funciona bem
se você tiver um firewall sem regras no caminho entre a máquina com
o
nessus e a máquina a ser analisada (nem sempre pode instalar o
nessus
no servidor a ser analisado).
Além disso, há outras coisas que podem ser feitas e o nessus não
faz,
por exemplo, ele não vê se todos as atualizações de segurança foram aplicadas e nem se você tem uma boa política de senhas na máquina.
Mas
em todo o caso, o nessus é algo bom para se ter um começo :)
Dependendo da criticidade do servidor, tem muita coisa que pode ser feita ... mas nem sempre vale a pena ($$$) o investimento.
[]´s Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Para verificar falhas no servidor use o nessus. http://www.nessus.org/download/
Tem o pacote para Fedora 5, 6 e 7.
Em 28/08/07, Adere - Levi / Analista de Suporte Linux
<levi.alves@adere.com >
escreveu:
existe algum procedimneto ou comandos
--
Levi Leopoldino Alves T.I. - (19)2104-0700 Adere Produtos Auto-Adesivos Ltda visite nosso site http://www.adere.com
Esta mensagem tem caráter confidencial, se você recebeu-a por
engano,
por favor delete-a imediatamente.
-- Fedora-users-br mailing list Fedora-users-br@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
legal pessoal vou usar o nessus, mas existe uma ferramenta mais completa que pegue tudo o que o nessus não pega. ---- Levi Leopoldino Alves T.I. - (19)2104-0700 Adere Produtos Auto-Adesivos Ltda visite nosso site http://www.adere.com
Esta mensagem tem caráter confidencial, se você recebeu-a por engano, por favor delete-a imediatamente.
Cristiano Furtado escreveu:
Geralmente eu faço com que no final do dia seja mandado para mim um log via email para que eu possa ver se houve algum tipo de ataque ou algo parecido. Até hoje so passei por um aperto, mais resolvi muito rapido, pois tinha visto que em um horario (de madruga) um cara tinha tentado atacar meu servidor com força bruta, mais vi de que forma ele estava tentando e mudei logo. Isso foi a mais de meses e até hoje não sofri mais nenhum tipo de ataque :). Eu sempre usei o nessus por não encontrar uma outra ferramenta que pudesse me trazer pelo menos um resultado sabe? Ja tenho pesquisado sobre isso a tempos, e realmente não encontrei nenhuma. Então prefiro ficar ligado todos os dias no que aconteceu pela madrugada ou de dia mesmo.
Em 28/08/07, *Gustavo Picoloto* <picoloto@gmail.com mailto:picoloto@gmail.com> escreveu:
Olá, Para vulnerabilidades remotas, o nessus é digamos "a melhor relação custo X benefício". Ele procura as vulnerabilidades mais comuns, mas não procura todas. O nessus não faz certas coisas como ver se o ssh está permitindo acesso remoto de root e a senha do mesmo é "root". Ele também não consegue ver se determinado usuário está no grupo wheel e pode executar "sudo su -". Entendeu o que tentei mostrar? Este tipo de coisa é muito mais comum do que se possa imaginar e o nessus não faz. Ah sim, não é óbvio desativar o firewall pois para uma análise real de vulnerabilidades o firewall deve estar ativo pois um possível invasor não vai te pedir para desativar o firewall para invadir, ele vai tentar invadir do jeito que a rede está. Uma análise dessas poderia descobrir regras de firewall incorretas e depois disso descobrir configurações incorretas no servidor. O ideal é ter um checklist a ser seguido e aplicar tudo ou o máximo de regras possíveis e para isso, até onde eu saiba, não tem uma ferramenta que "faz tudo". Se quiserem/precisarem, eu posso passar algumas dicas genéricas e tirar dúvidas mas infelizmente não posso passar o checklist que conheço devido a um contrato que tenho assinado com a empresa onde trabalho e outro com a empresa onde trabalhei até recentemente :( Uma sugestão é procurar na internet por "linux security enforcing", "linux security hardening" e coisas do tipo. Depois, procurar fazer o mesmo com os serviços que a máquina tem disponível (ssh e apache por exemplo). Tudo o que tem no checklist de onde trabalho tem na internet, mas não está tudo concentrado no mesmo lugar. []'s Gustavo Picoloto Em 28/08/07, Cristiano Furtado<jasonnfedora@gmail.com <mailto:jasonnfedora@gmail.com>> escreveu: > Mais neste caso o mais obvio é que o firewall esteja desativado para esse > proposito. Eu ainda desconheço uma ferramenta tão util quanto o nessus. > Picoloto, você tem idéia de uma outra ferramenta? > > Em 28/08/07, Gustavo Picoloto <picoloto@gmail.com <mailto:picoloto@gmail.com>> escreveu: > > Olá, > > > > O nessus é razoavelmente bom para serviços de rede e só funciona bem > > se você tiver um firewall sem regras no caminho entre a máquina com o > > nessus e a máquina a ser analisada (nem sempre pode instalar o nessus > > no servidor a ser analisado). > > > > Além disso, há outras coisas que podem ser feitas e o nessus não faz, > > por exemplo, ele não vê se todos as atualizações de segurança foram > > aplicadas e nem se você tem uma boa política de senhas na máquina. Mas > > em todo o caso, o nessus é algo bom para se ter um começo :) > > > > Dependendo da criticidade do servidor, tem muita coisa que pode ser > > feita ... mas nem sempre vale a pena ($$$) o investimento. > > > > []´s > > Gustavo Picoloto > > > > > > Em 28/08/07, Cristiano Furtado<jasonnfedora@gmail.com <mailto:jasonnfedora@gmail.com>> escreveu: > > > Para verificar falhas no servidor use o nessus. > > > http://www.nessus.org/download/ > > > > > > Tem o pacote para Fedora 5, 6 e 7. > > > > > > Em 28/08/07, Adere - Levi / Analista de Suporte Linux > <levi.alves@adere.com <mailto:levi.alves@adere.com> > > > > escreveu: > > > > existe algum procedimneto ou comandos > > > > > > > > -- > > > > ---- > > > > Levi Leopoldino Alves > > > > T.I. - (19)2104-0700 > > > > Adere Produtos Auto-Adesivos Ltda > > > > visite nosso site http://www.adere.com > > > > > > > > Esta mensagem tem caráter confidencial, se você recebeu-a por engano, > > > > por favor delete-a imediatamente. > > > > > > > > -- > > > > Fedora-users-br mailing list > > > > Fedora-users-br@redhat.com <mailto:Fedora-users-br@redhat.com> > > > > > https://www.redhat.com/mailman/listinfo/fedora-users-br > > > > > > > > > > > > > > > > -- > > > Cristiano Furtado > > > Gerente de TI - Projetos de Software Livre > > > Embaixador do Fedora no Brasil > > > > > > Sites: > > > http://www.projetofedora.org > > > http://www.jasonnfedora.eti.br > > > http://www.fedora.org.br > > > http://www.ekaaty.com.br > > > -- > > > Fedora-users-br mailing list > > > Fedora-users-br@redhat.com <mailto:Fedora-users-br@redhat.com> > > > https://www.redhat.com/mailman/listinfo/fedora-users-br > > > > > > > > > > > > -- > > ------ > > Gustavo Picoloto, LPIC-1, SCSECA > > http://cenoura.homelinux.com > > ------ > > > > -- > > Fedora-users-br mailing list > > Fedora-users-br@redhat.com <mailto:Fedora-users-br@redhat.com> > > https://www.redhat.com/mailman/listinfo/fedora-users-br > > > > > > -- > Cristiano Furtado > Gerente de TI - Projetos de Software Livre > Embaixador do Fedora no Brasil > > Sites: > http://www.projetofedora.org > http://www.jasonnfedora.eti.br <http://www.jasonnfedora.eti.br> > http://www.fedora.org.br > http://www.ekaaty.com.br > -- > Fedora-users-br mailing list > Fedora-users-br@redhat.com <mailto:Fedora-users-br@redhat.com> > https://www.redhat.com/mailman/listinfo/fedora-users-br > > -- ------ Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com ------ -- Fedora-users-br mailing list Fedora-users-br@redhat.com <mailto:Fedora-users-br@redhat.com> https://www.redhat.com/mailman/listinfo/fedora-users-br-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
Em 28/08/07, Adere - Levi / Analista de Suporte Linux levi.alves@adere.com escreveu:
legal pessoal vou usar o nessus, mas existe uma ferramenta mais completa que pegue tudo o que o nessus não pega.
Na realidade, pelo que deu para ver, ele somente analiza os arquivos em /var/log/
Olá,
O problema é que como você está fazendo (lendo logs) você vai saber que aconteceu (resumindo, seu servidor já era) sendo que, a meu ver, o ideal é evitar que aconteça.
Algumas sugestões:
* Mantenha os pacotes atualizados, se não pode aplicar todos os patches, tente aplicar pelo menos os de segurança nos serviços que abrem conexões tcp/udp. * Tenha uma boa política de senhas (tamanho, complexidade e expiração). * Deixe apenas o mínimo necessário em execução no servidor. * Procure restringir o acesso administrativo ao mínimo possível de usuários e obrigue-os a usar "su" para tarefas administrativas (jamais logar direto como root). * Verifique se as permissões de arquivos críticos estão restritas (no /etc e /var/log).
[]'s
Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Geralmente eu faço com que no final do dia seja mandado para mim um log via email para que eu possa ver se houve algum tipo de ataque ou algo parecido. Até hoje so passei por um aperto, mais resolvi muito rapido, pois tinha visto que em um horario (de madruga) um cara tinha tentado atacar meu servidor com força bruta, mais vi de que forma ele estava tentando e mudei logo. Isso foi a mais de meses e até hoje não sofri mais nenhum tipo de ataque :). Eu sempre usei o nessus por não encontrar uma outra ferramenta que pudesse me trazer pelo menos um resultado sabe? Ja tenho pesquisado sobre isso a tempos, e realmente não encontrei nenhuma. Então prefiro ficar ligado todos os dias no que aconteceu pela madrugada ou de dia mesmo.
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Olá,
Para vulnerabilidades remotas, o nessus é digamos "a melhor relação custo X benefício". Ele procura as vulnerabilidades mais comuns, mas não procura todas. O nessus não faz certas coisas como ver se o ssh está permitindo acesso remoto de root e a senha do mesmo é "root". Ele também não consegue ver se determinado usuário está no grupo wheel e pode executar "sudo su -". Entendeu o que tentei mostrar? Este tipo de coisa é muito mais comum do que se possa imaginar e o nessus não faz.
Ah sim, não é óbvio desativar o firewall pois para uma análise real de vulnerabilidades o firewall deve estar ativo pois um possível invasor não vai te pedir para desativar o firewall para invadir, ele vai tentar invadir do jeito que a rede está. Uma análise dessas poderia descobrir regras de firewall incorretas e depois disso descobrir configurações incorretas no servidor.
O ideal é ter um checklist a ser seguido e aplicar tudo ou o máximo de regras possíveis e para isso, até onde eu saiba, não tem uma ferramenta que "faz tudo".
Se quiserem/precisarem, eu posso passar algumas dicas genéricas e tirar dúvidas mas infelizmente não posso passar o checklist que conheço devido a um contrato que tenho assinado com a empresa onde trabalho e outro com a empresa onde trabalhei até recentemente :(
Uma sugestão é procurar na internet por "linux security enforcing", "linux security hardening" e coisas do tipo. Depois, procurar fazer o mesmo com os serviços que a máquina tem disponível (ssh e apache por exemplo). Tudo o que tem no checklist de onde trabalho tem na internet, mas não está tudo concentrado no mesmo lugar.
[]'s
Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Mais neste caso o mais obvio é que o firewall esteja desativado para
esse
proposito. Eu ainda desconheço uma ferramenta tão util quanto o nessus. Picoloto, você tem idéia de uma outra ferramenta?
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Olá,
O nessus é razoavelmente bom para serviços de rede e só funciona bem se você tiver um firewall sem regras no caminho entre a máquina com o nessus e a máquina a ser analisada (nem sempre pode instalar o nessus no servidor a ser analisado).
Além disso, há outras coisas que podem ser feitas e o nessus não faz, por exemplo, ele não vê se todos as atualizações de segurança foram aplicadas e nem se você tem uma boa política de senhas na máquina. Mas em todo o caso, o nessus é algo bom para se ter um começo :)
Dependendo da criticidade do servidor, tem muita coisa que pode ser feita ... mas nem sempre vale a pena ($$$) o investimento.
[]´s Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Para verificar falhas no servidor use o nessus. http://www.nessus.org/download/
Tem o pacote para Fedora 5, 6 e 7.
Em 28/08/07, Adere - Levi / Analista de Suporte Linux
<levi.alves@adere.com >
escreveu:
existe algum procedimneto ou comandos
--
Levi Leopoldino Alves T.I. - (19)2104-0700 Adere Produtos Auto-Adesivos Ltda visite nosso site http://www.adere.com
Esta mensagem tem caráter confidencial, se você recebeu-a por
engano,
por favor delete-a imediatamente.
-- Fedora-users-br mailing list Fedora-users-br@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-users-br
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Olá,
O problema é que como você está fazendo (lendo logs) você vai saber que aconteceu (resumindo, seu servidor já era) sendo que, a meu ver, o ideal é evitar que aconteça.
Algumas sugestões:
- Mantenha os pacotes atualizados, se não pode aplicar todos os
patches, tente aplicar pelo menos os de segurança nos serviços que abrem conexões tcp/udp.
Nem sempre os pacotes mais atualizados são os mais seguros. Ainda acho a melhor idéia ficar de olho nas falhas de segurança no proprio site do bugzilla.
* Tenha uma boa política de senhas (tamanho, complexidade e expiração).
sempre usar acima de 13 digitos
* Deixe apenas o mínimo necessário em execução no servidor.
Evitando usar pacotes para modo gráfico e principalmente se for firewall perl e outros.
* Procure restringir o acesso administrativo ao mínimo possível de
usuários e obrigue-os a usar "su" para tarefas administrativas (jamais logar direto como root).
hehehe isso é o que os administradores mais fazem, e isso é uma lista gigante :)
* Verifique se as permissões de arquivos críticos estão restritas (no
/etc e /var/log).
Sem resposta .. ... ..
[]'s
Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Geralmente eu faço com que no final do dia seja mandado para mim um log
via
email para que eu possa ver se houve algum tipo de ataque ou algo
parecido.
Até hoje so passei por um aperto, mais resolvi muito rapido, pois tinha visto que em um horario (de madruga) um cara tinha tentado atacar meu servidor com força bruta, mais vi de que forma ele estava tentando e
mudei
logo. Isso foi a mais de meses e até hoje não sofri mais nenhum tipo de ataque :). Eu sempre usei o nessus por não encontrar uma outra
ferramenta
que pudesse me trazer pelo menos um resultado sabe? Ja tenho pesquisado sobre isso a tempos, e realmente não encontrei nenhuma. Então prefiro
ficar
ligado todos os dias no que aconteceu pela madrugada ou de dia mesmo.
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Olá,
Para vulnerabilidades remotas, o nessus é digamos "a melhor relação custo X benefício". Ele procura as vulnerabilidades mais comuns, mas não procura todas. O nessus não faz certas coisas como ver se o ssh está permitindo acesso remoto de root e a senha do mesmo é "root". Ele também não consegue ver se determinado usuário está no grupo wheel e pode executar "sudo su -". Entendeu o que tentei mostrar? Este tipo de coisa é muito mais comum do que se possa imaginar e o nessus não faz.
Ah sim, não é óbvio desativar o firewall pois para uma análise real de vulnerabilidades o firewall deve estar ativo pois um possível invasor não vai te pedir para desativar o firewall para invadir, ele vai tentar invadir do jeito que a rede está. Uma análise dessas poderia descobrir regras de firewall incorretas e depois disso descobrir configurações incorretas no servidor.
O ideal é ter um checklist a ser seguido e aplicar tudo ou o máximo de regras possíveis e para isso, até onde eu saiba, não tem uma ferramenta que "faz tudo".
Se quiserem/precisarem, eu posso passar algumas dicas genéricas e tirar dúvidas mas infelizmente não posso passar o checklist que conheço devido a um contrato que tenho assinado com a empresa onde trabalho e outro com a empresa onde trabalhei até recentemente :(
Uma sugestão é procurar na internet por "linux security enforcing", "linux security hardening" e coisas do tipo. Depois, procurar fazer o mesmo com os serviços que a máquina tem disponível (ssh e apache por exemplo). Tudo o que tem no checklist de onde trabalho tem na internet, mas não está tudo concentrado no mesmo lugar.
[]'s
Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Mais neste caso o mais obvio é que o firewall esteja desativado para
esse
proposito. Eu ainda desconheço uma ferramenta tão util quanto o
nessus.
Picoloto, você tem idéia de uma outra ferramenta?
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Olá,
O nessus é razoavelmente bom para serviços de rede e só funciona
bem
se você tiver um firewall sem regras no caminho entre a máquina
com o
nessus e a máquina a ser analisada (nem sempre pode instalar o
nessus
no servidor a ser analisado).
Além disso, há outras coisas que podem ser feitas e o nessus não
faz,
por exemplo, ele não vê se todos as atualizações de segurança
foram
aplicadas e nem se você tem uma boa política de senhas na máquina.
Mas
em todo o caso, o nessus é algo bom para se ter um começo :)
Dependendo da criticidade do servidor, tem muita coisa que pode
ser
feita ... mas nem sempre vale a pena ($$$) o investimento.
[]´s Gustavo Picoloto
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Para verificar falhas no servidor use o nessus. http://www.nessus.org/download/
Tem o pacote para Fedora 5, 6 e 7.
Em 28/08/07, Adere - Levi / Analista de Suporte Linux
<levi.alves@adere.com >
escreveu: > existe algum procedimneto ou comandos > > -- > ---- > Levi Leopoldino Alves > T.I. - (19)2104-0700 > Adere Produtos Auto-Adesivos Ltda > visite nosso site http://www.adere.com > > Esta mensagem tem caráter confidencial, se você recebeu-a por
engano,
> por favor delete-a imediatamente. > > -- > Fedora-users-br mailing list > Fedora-users-br@redhat.com >
https://www.redhat.com/mailman/listinfo/fedora-users-br
>
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-users-br
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Cristiano Furtado Gerente de TI - Projetos de Software Livre Embaixador do Fedora no Brasil
Sites: http://www.projetofedora.org http://www.jasonnfedora.eti.br http://www.fedora.org.br http://www.ekaaty.com.br -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
- Tenha uma boa política de senhas (tamanho, complexidade e expiração).
sempre usar acima de 13 digitos
Nem só tamanho ... 8 caracteres pode ser mais seguro que 13, depende da senha, se tem letras, números e caracteres especiais por exemplo. Mas é por aí mesmo :)
[]'s
Gustavo Picoloto
Uma senha do tipo Fedora@#23 seria uma boa senha... (Por exemplo...)
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
Em 28/08/07, Cristiano Furtadojasonnfedora@gmail.com escreveu:
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
- Tenha uma boa política de senhas (tamanho, complexidade e
expiração).
sempre usar acima de 13 digitos
Nem só tamanho ... 8 caracteres pode ser mais seguro que 13, depende da senha, se tem letras, números e caracteres especiais por exemplo. Mas é por aí mesmo :)
[]'s
Gustavo Picoloto
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
Não... não seria... é aconselhavel que você não utiliza palavras conhecidas e sim faça uma mistura de letras e caracteres especiais, não uma divisão meio que "modular", uma senha bo seria: f3Edo![#2Aa3 , seria dificil de você gravar, mas você podia usar o PGP, para criptografar seus arquivos...
Em 28/08/07, Rafael Gomes linux.rafa@gmail.com escreveu:
Uma senha do tipo Fedora@#23 seria uma boa senha... (Por exemplo...)
Em 28/08/07, Gustavo Picoloto <picoloto@gmail.com > escreveu:
Em 28/08/07, Cristiano Furtado< jasonnfedora@gmail.com> escreveu:
Em 28/08/07, Gustavo Picoloto picoloto@gmail.com escreveu:
- Tenha uma boa política de senhas (tamanho, complexidade e
expiração).
sempre usar acima de 13 digitos
Nem só tamanho ... 8 caracteres pode ser mais seguro que 13, depende da senha, se tem letras, números e caracteres especiais por exemplo. Mas é por aí mesmo :)
[]'s
Gustavo Picoloto
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Rafael Gomes Consultor em TI ITServ - Tecnologia com Segurança (71) 8146-5772
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
Um site que você poderia utilizar para gerar suas senhas é: http://www.goodpassword.com, eu atualmente estou trabalhando em Python que faça um checklist do hardening do servidor, e me diga os pontos fracos da configuração desse servidor, como acesso via ssh, portas abertas, serviços que estão rodandos e são desnecessarios e etc.
Em 28/08/07, Marley Bacelar marleybacelar@gmail.com escreveu:
Não... não seria... é aconselhavel que você não utiliza palavras conhecidas e sim faça uma mistura de letras e caracteres especiais, não uma divisão meio que "modular", uma senha bo seria: f3Edo![#2Aa3 , seria dificil de você gravar, mas você podia usar o PGP, para criptografar seus arquivos...
Em 28/08/07, Rafael Gomes linux.rafa@gmail.com escreveu:
Uma senha do tipo Fedora@#23 seria uma boa senha... (Por exemplo...)
Em 28/08/07, Gustavo Picoloto < picoloto@gmail.com > escreveu:
Em 28/08/07, Cristiano Furtado< jasonnfedora@gmail.com> escreveu:
Em 28/08/07, Gustavo Picoloto <picoloto@gmail.com > escreveu:
- Tenha uma boa política de senhas (tamanho, complexidade e
expiração).
sempre usar acima de 13 digitos
Nem só tamanho ... 8 caracteres pode ser mais seguro que 13, depende da senha, se tem letras, números e caracteres especiais por exemplo. Mas é por aí mesmo :)
[]'s
Gustavo Picoloto
--
Gustavo Picoloto, LPIC-1, SCSECA http://cenoura.homelinux.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Rafael Gomes Consultor em TI ITServ - Tecnologia com Segurança (71) 8146-5772
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
-- Marley Oliveira Bacelar
O uso de palavras simples ou não só se aplica para pessoas tentando adivinhar as senhas, pois para ataques de bruta força eles usam combinações que são descobertas estando em ordem logica ou não. Claro que em alguns sistemas palavras comuns são utilizadas, tais como nome de distribuição e outras coisas, mas outras palavras em ordem logica pode ser usada normalmente, claro que com os outros graus de complexbilidade.
Em 28/08/07, Marley Bacelar marleybacelar@gmail.com escreveu:
Não... não seria... é aconselhavel que você não utiliza palavras conhecidas e sim faça uma mistura de letras e caracteres especiais, não uma divisão meio que "modular", uma senha bo seria: f3Edo![#2Aa3 , seria dificil de você gravar, mas você podia usar o PGP, para criptografar seus arquivos...
Em 28/08/07, Rafael Gomes linux.rafa@gmail.com escreveu:
Uma senha do tipo Fedora@#23 seria uma boa senha... (Por exemplo...)
Rafael Gomes Consultor em TI ITServ - Tecnologia com Segurança (71) 8146-5772
Olá,
Uma ótima ferramenta para testar a complexidade das senhas é o John the Ripper (http://www.openwall.com/john/) que também está disponível nos repositórios do Fedora.
[]'s Gustavo Picoloto
Em 28/08/07, Rafael Gomeslinux.rafa@gmail.com escreveu:
O uso de palavras simples ou não só se aplica para pessoas tentando adivinhar as senhas, pois para ataques de bruta força eles usam combinações que são descobertas estando em ordem logica ou não. Claro que em alguns sistemas palavras comuns são utilizadas, tais como nome de distribuição e outras coisas, mas outras palavras em ordem logica pode ser usada normalmente, claro que com os outros graus de complexbilidade.
Em 28/08/07, Marley Bacelar marleybacelar@gmail.com escreveu:
Não... não seria... é aconselhavel que você não utiliza palavras
conhecidas e sim faça uma mistura de letras e caracteres especiais, não uma divisão meio que "modular", uma senha bo seria:
f3Edo
Em 28/08/07, Cristiano Furtado jasonnfedora@gmail.com escreveu:
Nunca deve-se usar senha do tipo conhecidas. As minhas senhas são macabras, mais imagine o que é MACABRA? Todas as minhas senhas são acima de 13 digitos. Em relação ao John the Ripper realmente é uma otima opção. Usei ele mais a muito tempo mesmo atras. Hoje as minhas senhas são geralmente trocadas de 15 em 15 dias. (Ja estou Falando demais...)
Bem, falar de segurança é sempre muito complicado. Eu definiria segurança como um modo de adiar o momento do ataque, pois um dia você será atacado. Bem, deixando a paranóia de lado. Segurança é algo fundamental, mas que ninguém se preocupa muito hoje em dia.
Claro que para um ambiente seguro, tem que se levar em conta o que se roda, qual a necessidade de se rodar tal programa entre diversos otros fatores. Um firewall, por exemplo, tem que ser o mais seguro de uma empresa. Já um servidor de arquivos, não terá a mesma segurança que o firewall, pois seria quase que impossível utilizá-lo, dar permissões e ser tão flexível como tem que ser.
Boas praticas de segurança? Bem, é complicado, mas não impossível.
Algomas dicas do que se pode fazer em um sistema para deixá-lo mais seguro:
- Hardering Ou seja, tirar as permissões de quase tudo. Exemplos? SUID de arquivos - Não permitir que nenhum arquivo rode com permissões de dono de outro usuário /etc/passwd com quase nenhum serviço rodando com um shell válido (somente os extremamente necessários) Politica bem definida com o PAM. Limitando acesso por horário, por usuário etc. Ainda no PAM, usar cracklib para definição de senhas etc. Configurar as partições, principalmente /home, /tmp, /var/log com os parâmetros NOSUID, NOEXEC Configurar a variável TMOUT para os usuário logados. Bloquer login de root, só permitindo su, e ainda assim para usuários específicos. SSH com chave. Senha no gerenciador de boot
Criar um sistema que rode em chroot, como serviços enjaulados. Um bom exemplo seria apache, ftp, e serviços que seriam abertos à acessos externos.
Utilizar um registro de eventos com o Syslog-NG
Um IDS bem configurado.
Programas para checar vulnerabilidades.
Bem, por ai já deve-se ter uma idéia do tanto de trabalho que é pensar em segurança. Isso por que não mencionei metado do necessário e possível.
Segurança é algo bem complexo, que exige muito de um Administrador. Analise de logs, acompanhamentos, check-list de verificações.
Tenho um conhecido que fala: "Para se proteger, pense como um cracker. Imagine as formas que você usaria para entrar em sua rede. Para saber se está vulnerável, tente se invadir, mas com determinação, com vontade de quem quer obter lucro tendo acessos à seus arquivos."
Bem, acho que deu pra passar uma idéia do que quis dizer, mas também acho que me delonguei muito.
Abraços.
Leitura recomendada: http://www.cert.br/docs/seg-adm-redes/ http://cartilha.cert.br (este para usuários)
E ainda, explorando o site há muito material sobre o tema. http://www.cert.br/
Recomendo ainda os cursos ministrados pelos CERT.br, são muito bons, com destaque especial para os instrutores cujos conhecimento técnico e didática são excelentes. http://www.cert.br/cursos/
O CERT.br é o grupo de resposta a incidentes de segurança para a Internet brasileira, mantido pelo NIC.br, do Comitê Gestor da Internet no Brasil. O CERT.br é responsável por receber, analisar e responder a incidentes de segurança envolvendo redes conectadas à Internet no Brasil.
Saudações, Otto Fuchshuber Filho o2to2f@gmail.com
Anderson Kaiser escreveu, Em 28-08-2007 20:01:
Em 28/08/07, *Cristiano Furtado* <jasonnfedora@gmail.com mailto:jasonnfedora@gmail.com> escreveu:
Nunca deve-se usar senha do tipo conhecidas. As minhas senhas são macabras, mais imagine o que é MACABRA? Todas as minhas senhas são acima de 13 digitos. Em relação ao John the Ripper realmente é uma otima opção. Usei ele mais a muito tempo mesmo atras. Hoje as minhas senhas são geralmente trocadas de 15 em 15 dias. (Ja estou Falando demais...)Bem, falar de segurança é sempre muito complicado. Eu definiria segurança como um modo de adiar o momento do ataque, pois um dia você será atacado. Bem, deixando a paranóia de lado. Segurança é algo fundamental, mas que ninguém se preocupa muito hoje em dia.
Claro que para um ambiente seguro, tem que se levar em conta o que se roda, qual a necessidade de se rodar tal programa entre diversos otros fatores. Um firewall, por exemplo, tem que ser o mais seguro de uma empresa. Já um servidor de arquivos, não terá a mesma segurança que o firewall, pois seria quase que impossível utilizá-lo, dar permissões e ser tão flexível como tem que ser.
Boas praticas de segurança? Bem, é complicado, mas não impossível.
Algomas dicas do que se pode fazer em um sistema para deixá-lo mais seguro:
- Hardering
Ou seja, tirar as permissões de quase tudo. Exemplos? SUID de arquivos - Não permitir que nenhum arquivo rode com permissões de dono de outro usuário /etc/passwd com quase nenhum serviço rodando com um shell válido (somente os extremamente necessários) Politica bem definida com o PAM. Limitando acesso por horário, por usuário etc. Ainda no PAM, usar cracklib para definição de senhas etc. Configurar as partições, principalmente /home, /tmp, /var/log com os parâmetros NOSUID, NOEXEC Configurar a variável TMOUT para os usuário logados. Bloquer login de root, só permitindo su, e ainda assim para usuários específicos. SSH com chave. Senha no gerenciador de boot
Criar um sistema que rode em chroot, como serviços enjaulados. Um bom exemplo seria apache, ftp, e serviços que seriam abertos à acessos externos.
Utilizar um registro de eventos com o Syslog-NG
Um IDS bem configurado.
Programas para checar vulnerabilidades.
Bem, por ai já deve-se ter uma idéia do tanto de trabalho que é pensar em segurança. Isso por que não mencionei metado do necessário e possível.
Segurança é algo bem complexo, que exige muito de um Administrador. Analise de logs, acompanhamentos, check-list de verificações.
Tenho um conhecido que fala: "Para se proteger, pense como um cracker. Imagine as formas que você usaria para entrar em sua rede. Para saber se está vulnerável, tente se invadir, mas com determinação, com vontade de quem quer obter lucro tendo acessos à seus arquivos."
Bem, acho que deu pra passar uma idéia do que quis dizer, mas também acho que me delonguei muito.
Abraços.
-- Anderson Kaiser alpkaiser@gmail.com mailto:alpkaiser@gmail.com Linux User #: 426240 (1011) 10000011000100100110010000011000
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
cara eu estou tão chatão para segurança que ate para acessar agora aos meus emails, acesso a meu servidor via VPN e abro o firefox la em casa hehehe acredita? Mais tudo isso por que não da para confiar nos computadores da minha faculdade.
Em 28/08/07, Anderson Kaiser alpkaiser@gmail.com escreveu:
Em 28/08/07, Cristiano Furtado jasonnfedora@gmail.com escreveu:
Nunca deve-se usar senha do tipo conhecidas. As minhas senhas são macabras, mais imagine o que é MACABRA? Todas as minhas senhas são acima de 13 digitos. Em relação ao John the Ripper realmente é uma otima opção. Usei ele mais a muito tempo mesmo atras. Hoje as minhas senhas são geralmente trocadas de 15 em 15 dias. (Ja estou Falando demais...)
Bem, falar de segurança é sempre muito complicado. Eu definiria segurança como um modo de adiar o momento do ataque, pois um dia você será atacado. Bem, deixando a paranóia de lado. Segurança é algo fundamental, mas que ninguém se preocupa muito hoje em dia.
Claro que para um ambiente seguro, tem que se levar em conta o que se roda, qual a necessidade de se rodar tal programa entre diversos otros fatores. Um firewall, por exemplo, tem que ser o mais seguro de uma empresa. Já um servidor de arquivos, não terá a mesma segurança que o firewall, pois seria quase que impossível utilizá-lo, dar permissões e ser tão flexível como tem que ser.
Boas praticas de segurança? Bem, é complicado, mas não impossível.
Algomas dicas do que se pode fazer em um sistema para deixá-lo mais seguro:
- Hardering
Ou seja, tirar as permissões de quase tudo. Exemplos? SUID de arquivos - Não permitir que nenhum arquivo rode com permissões de dono de outro usuário /etc/passwd com quase nenhum serviço rodando com um shell válido (somente os extremamente necessários) Politica bem definida com o PAM. Limitando acesso por horário, por usuário etc. Ainda no PAM, usar cracklib para definição de senhas etc. Configurar as partições, principalmente /home, /tmp, /var/log com os parâmetros NOSUID, NOEXEC Configurar a variável TMOUT para os usuário logados. Bloquer login de root, só permitindo su, e ainda assim para usuários específicos. SSH com chave. Senha no gerenciador de boot
Criar um sistema que rode em chroot, como serviços enjaulados. Um bom exemplo seria apache, ftp, e serviços que seriam abertos à acessos externos.
Utilizar um registro de eventos com o Syslog-NG
Um IDS bem configurado.
Programas para checar vulnerabilidades.
Bem, por ai já deve-se ter uma idéia do tanto de trabalho que é pensar em segurança. Isso por que não mencionei metado do necessário e possível.
Segurança é algo bem complexo, que exige muito de um Administrador. Analise de logs, acompanhamentos, check-list de verificações.
Tenho um conhecido que fala: "Para se proteger, pense como um cracker. Imagine as formas que você usaria para entrar em sua rede. Para saber se está vulnerável, tente se invadir, mas com determinação, com vontade de quem quer obter lucro tendo acessos à seus arquivos."
Bem, acho que deu pra passar uma idéia do que quis dizer, mas também acho que me delonguei muito.
Abraços.
-- Anderson Kaiser alpkaiser@gmail.com Linux User #: 426240 (1011) 10000011000100100110010000011000 -- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
Rau,
Esqueceu de algumas coisas que muita gente ignora ou apenas desconhece: 1 - Utilizar o tcp_wrapper, para saber se o servidor suporta tcp_wrapper basta um ldd nele e ve se tem libwrap. 2 - Apreender a usar o selinux no lugar de ficar desabilitando (como vejo muita gente fazer). Agora com o setroubleshoot que até da dicas do que esta dando errado não tem desculpa...
Algomas dicas do que se pode fazer em um sistema para deixá-lo mais seguro:
- Hardering
Ou seja, tirar as permissões de quase tudo. Exemplos? SUID de arquivos - Não permitir que nenhum arquivo rode com permissões de dono de outro usuário /etc/passwd com quase nenhum serviço rodando com um shell válido (somente os extremamente necessários) Politica bem definida com o PAM. Limitando acesso por horário, por usuário etc. Ainda no PAM, usar cracklib para definição de senhas etc. Configurar as partições, principalmente /home, /tmp, /var/log com os parâmetros NOSUID, NOEXEC Configurar a variável TMOUT para os usuário logados. Bloquer login de root, só permitindo su, e ainda assim para usuários específicos. SSH com chave. Senha no gerenciador de boot
Criar um sistema que rode em chroot, como serviços enjaulados. Um bom exemplo seria apache, ftp, e serviços que seriam abertos à acessos externos.
Utilizar um registro de eventos com o Syslog-NG
Um IDS bem configurado.
Programas para checar vulnerabilidades.
Bem, por ai já deve-se ter uma idéia do tanto de trabalho que é pensar em segurança. Isso por que não mencionei metado do necessário e possível.
Segurança é algo bem complexo, que exige muito de um Administrador. Analise de logs, acompanhamentos, check-list de verificações.
Tenho um conhecido que fala: "Para se proteger, pense como um cracker. Imagine as formas que você usaria para entrar em sua rede. Para saber se está vulnerável, tente se invadir, mas com determinação, com vontade de quem quer obter lucro tendo acessos à seus arquivos."
Bem, acho que deu pra passar uma idéia do que quis dizer, mas também acho que me delonguei muito.
br-users@lists.fedoraproject.org
-
Adere - Levi / Analista de Suporte Linux -
Anderson Kaiser -
André Felício -
Cristiano Furtado -
Gustavo Picoloto -
Marley Bacelar -
Otto Fuchshuber Filho -
Rafael Gomes