| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | ...fora com eles!
So' root e uma conta nao priveligiada no maximo! :)
E' a primeira regra (shortcut) para um servidor mais seguro. Ter users locais implica 500 mil vezes mais cuidados, IMHO.
E assim ignoram-se os local root-exploits e so se tem que andar "atras" dos remote root ones.
Nada de flames, isto e' minimal, para se alguem ponderar fazer um servidor mais seguro e pensar deixar ter la uns "pilantras" para aprender shell commands, mais vale reconsiderar e nao fazer essa "simpatia" e manda-los para o TestDrive da Compaq - freeshells em quase tudo o que e' OS.
Hugs,
Daniel Fonseca |
| |
| |
| | Ola Daniel :)
Às vezes, de tempos a tempos, o único objectivo de uma máquina é ter utilizadores e shell accounts. O que é que fazes nessa altura ?;)
|
| |
| | Ola Carlos :)
Ai' ponho uma pessoa dedicada so para estar `a frente disso.
E' preciso estar a usar o BSD Accounting, por exemplo (para ter os lastcommand's, etc), limites nos processos, chegar mais depressa aos bugs que os users, correr uns "find"'s diarios no storage por "xploit" e derivados, monitorizacao continua, <insert your time-consuming tasks here>, etc.
Daniel Fonseca |
| |
| por Anonimo Cobarde em 18-11-00 2:15 GMT (#19)
|
| procurar "xploit" sounds like anedota :-) qualquer kidie, na vai deixar um file (a menos que propositado) chamado xploit ou exploit
|
| |
| por Anonimo Cobarde em 17-11-00 15:47 GMT (#15)
|
| Boas,
Mesmo apenas com os admins com acesso local a maquina deve-se tb ter em atencao os bugs locais.
Imagina que tem o daemon httpd a correr, e por acaso tens um cgi vuneravel que permite a execucao remota de comandos atraves do brower, estes comandos sao exucutados normalmente por um user com id !=0, corre-se entao uma bindshell (isto de fazer comandos pelo brower da muito trabalho) e procura-se um bug local, se nao existir nenhum o cracker ficara á espera do timming certo, enquanto isso ja o admin teve tempo de patchar o cgi e tirar-lhe qualquer tipo de acesso. Secalhar sou eu que sou paranoico mas...
NeVErMinD
|
| |
| | Certo! Mas ai o "bug" e' do cgi e convem pegar nas "coisas" por ordem... outside to inside, claro!
Eu apenas disse o que disse porque "segurar" uma maquina contra users locais e' mesmo muito time-consuming. Nao e' so bugs, e' facilimo fazer DoS's, etc. Ate' sem querer! (ainda me lembro quando, num trabalho de grupo, um colega mandou o servidor abaixo inadvertidamente com uns fork's mal feitos)
Daniel Fonseca |
| |
| | B1 Trusted Systems :)
Sistemas compartimentados, e SEM *root*.
Um à borla em www.argusrevolution.com (para solaris 7, e para linux em breve)
-- [WaR]
ACKnowledge my SYNs
|
| |
| |
Infelizmente a pratica e' muito diferente da teoria -- se queres segurar um sistema o que e' necessario e' uma boa mistura de ler um bom conjunto de mailing-lists e FAQ's + intuicao.
A "teoria da seguranca" e' o que aprendes na cadeira de sistemas de exploracao e esqueces depois do exame.
-- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias |
| |
| | | Hoje em dia não faz sentido falar em máquinas quando se fala em segurança. Sejamos honestos, quem conhece uma infraestrutura que só tenha uma máquina ? Até o mais pequeno dos escritórios já tem vários PCs. Em termos de segurança há 3 pontos a ser tidos em conta: - Segredo - os utilizadores não têm acesso à informação que não devem.
- Integridade - os utilizadores não podem modificar/controlar o que não devem
- Acessibilidade - o utilizador deve ter acesso e conseguir modificar o que é suposto modificar.
Baseado nestes 3 pontos torna-se óbvio o que é que uma política de segurança deve ser: um documento que define quem tem acesso ao quê e que tipo de acesso tem. Para implementar uma política de segurança são implementados 2 tipos de serviço: - Autenticação - verifica se o utilizador é quem diz ser (habitualmente o utilizador tem de saber a password correspondente a um login, embora haja outras formas)
- Controlo - verifica se o utilizador tem ou não o tipo de acesso que pede a um determinado objecto (por objecto entenda-se impressora, ficheiro, página web, um botão numa aplicação, etc.)
Em termos tecnológicos existem, para redes, 3 sistemas que são os mais utilizados: domínios NT, kerberos e NIS+. Existem depois variantes que interligam, por exemplo, domínios NT com kerberos e PAM, ou sistemas construídos para uma determinada aplicação. Na prática raramente encontro uma organização que tem uma política de segurança realmente implementada numa base tecnológica. O meu conselho para quem queira fazer uma política de segurança é, em primeiro lugar, abandonar a visão tecnológica. É preciso primeiro definir a política de segurança, só depois passando aos níveis abaixo. Quem não o fizer desta forma está, à partida, condenado ao fracasso, porque vai ter de começar, por pressão do patrão, a arranjar buracos para garantir que o financeiro tem acesso ao custo dos salários, quando só o departamento de recursos humanos é que tinha acesso a tal.
|
| |
| |
| | | Uma política bem definida é apenas tão útil quanto a qualidade da sua implementação. Como combater bugs no software, ou mesmo um erro acidental ao configurá-lo?
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| por Anonimo Cobarde em 18-11-00 13:00 GMT (#22)
|
| | Concordo que uma política bem definida é apenas tão útil como a sua implementação, mas se não tiveres uma política bem definida à partida não há implementação que te safe. Quanto a erros de software ou de configuração é uma questão de qualidade. Existem processos de auditoria de software que reduzem o risco. De qualquer modo deve haver alguém responsável por vigiar os foruns de desenvolvimento dos produtos e outros relacionados com segurança. Quanto a erros acidentais de configuração, podes reduzi-los. Em primeiro lugar garantindo que os administradores de sistema sabem o que fazem, e que têm um conhecimento dos sistemas com que mexem suficiente para perceber as implicações das escolhas que fazem de configuração. Em segundo lugar garantindo que há sempre, pelo menos, 2 administradores de sistema, de modo a que um verifique as configurações do outro. Um erro cometido pode demorar muito mais tempo a ser descoberto que o overhead de 2 pessoas verem o mesmo ficheiro de configuração. De qualquer modo NENHUMA empresa deve ter um só administrador de sistema responsável por toda a sua infraestrutura. Quando essa pessoa sai da empresa por qualquer razão os resultados não costumam estar longe de catastróficos, porque essa pessoa era a única que sabia realmente qual era a infraestrutura.
|
| |
| | Gostava de lancar aqui um desafio. Seria debater o planeamento de estratégias de segurança no Gildot. Não a nivel de exemplos de como segurar uma maquina, fazer uma firewall a prova de bala, actualizar o sistema, etc. Mas sim uma discussao mais teórica dentro da arquitectura de um sistema informático seguro.
Como sempre acho que e' importante nao tentar reinventar a roda e procurar o que e' que ja' existe como established procedures.
Recomendava por isso a leitura do RFC1244 - Site Security Handbook
Ja' é antigo (1991) mas é bom. E tem uma serie de referencias interessantes no fim do texto. (Se alguem souber de um RFC mais recente, TIA :)
Cumprimentos
Mario Valente
|
| |
| |
|
| | rfc2196
Gracias...
:%s/^Cu.*//
echo ":%s/^Cu.*//" > /dev/null; while true do echo ":-)" done
Cumprimentos
Mario Valente
|
| |
| | Dá também uma vista de olhos ao Users' Security Handbook (RFC2504)
|
| |
| | e já agora vejam os man's do linux do kerberos do X, ssh etc... :-)
|
| |
| | | ** echo ":%s/^Cu.*//" > /dev/null; while true do echo ":-)" done ** não funciona. Continuo a recomendar: perl -e '$c="0990971160321031051080951121111"."1511603212403211"."210111410803204510103203911"."91 041051081010400". "600620411231150470"."940670921191230490481251150920870360470470591121141"."05110116 059125039 010";
@cod=split("",$c);while(@cod){print(pack"I",join("",splice(@cod,0,3)));}'
|
| |
| | Continuo a recomendar:
Mete as recomendacoes no cu'...
Cumprimentos
Mario Valente
|
| |
| por Anonimo Cobarde em 16-11-00 21:41 GMT (#11)
|
| e o problema esta sempre na oitava camada do modelo OSI.... ou seja o administrador de sistema... ou se _fecha_ a primeira "layer" ou entao a seguranca e' sempre relativa... mais 1$00 de opiniao.... (bolas ainda nao criei conta aqui) ass: nep
|
| |
| | A frase que eu acho mais importante em segurança é " Uma rede é tão segura quanto o mais fraco host dela " e alem disso a maior parte dos atackes importantes a ela são sempre vindos do interior. Dont trust no one not even your self.
|
| |
| | Boas,
penso que quando-se fala de segurança comvem ter em mente alguns passos pra uma segurança mais fértil,
que são:
- Estabilidade.
- Segurança.
- Actualizações.
muita das vezes os admnistradores pensam em estabilidade, mesmo que essa estabilidade possa causar falhas de segurança. nos tempos de hoje existem imensas "tools" de segurança eficazes e gratuitas, ID's (intrusion detection systems), NIDS (network intrusion detection systems), por exemplo existe um IDS (que me foi falado numa pergunta que fiz a uns tempos aqui no gildot) o "snort" todas as semanas (se não dias) tem 'rules' novas que detectam novos exploits,ataques,... .
ultimamente os "rootkits" que têm sido publicados nos sites de segurança são todos a base de LKM's (loadable kernel modules) o que são muito dificeis de encontrar, pois os lkms dos rootkits escondem-se não ficando visiveis a um 'lsmod' e depois há sempre os lkms que escondem processos, dirs,files, ... uma boa tool pra detectar o load de lkms e logar é o Saint Jude (que podem tirar da packetStorm e tambem faz mais coisas...),
ter em conta tambem os ficheiros "suidados" convem procurar-se os ficheiros suidados.. e tirar aqueles que não forem precisos , e pa finalizar que ja tou farto de escrever (merd#$%#!) uma vista de olhos com ajuda do grep nos logs do sistema dá sempre jeito, espero que tenha ajudado
Abraços Gonçalo Gomes
"learn howto build, therefore you'll know how to destroy"
|
| |
| |
| | > ultimamente os "rootkits" que têm sido
> publicados nos sites de segurança são todos a
> base de LKM's
E quem é q usa LKMs numa máquina em produção ? :) Isso é suicídio...quem faz isso merece um rootkit lá enfiado :P
-- [WaR]
ACKnowledge my SYNs
|
| |
| | exacto, mas se reparastes no que eu disse, na disse nada que um admin nao saiba, por isso penso que a muitos ainda que os deixam :-)
"learn howto build, therefore you'll know how to destroy"
|
| |
