[1] Comentário enviado por gustavo_marcon em 02/12/2004 - 09:14h:

Ótima dica pra quando se perde a senha, mas qualquer pessoa poderá alterar a senha root da máquina desde que tenha um live cd então.

Sabe como configurar o linux de alguma forma onde seja "impossível" de alterar a senha root (ou de qualquer outro user) ou quase isso??

Pois pude entender isso como uma "brecha de segurança"!

[2] Comentário enviado por intelitec em 02/12/2004 - 09:59h:

mto show a dica..... mto util tb.... c vc n kizer q ng mude sua senha d root, coloque uma senha na bios e deixe o boot pelo hd, no caso d serum servidor, mantenha-o em um lugar seguro....
PoPo

[3] Comentário enviado por gustavo_marcon em 02/12/2004 - 10:03h:

Será que essa é realmente a única solução pra ñ alterarem a senha ??

[4] Comentário enviado por y2h4ck em 02/12/2004 - 10:30h:

gustavo_marcon...
deixe o seu linux com o LIDS instalado... e coloque o seu /etc/shadow como DENY
assim ninguem pode altera-lo ;)

[5] Comentário enviado por gustavo_marcon em 02/12/2004 - 10:35h:

legal vou dar uma olhada nisso, valeu pela dica...

[6] Comentário enviado por removido em 02/12/2004 - 10:46h:

O marcon falou algo muito sério: é uma VULNERABILIDADE DE SEGURANÇA NO LINUX ADVINDA DA CRIAÇÃO DIOS LIVE CDS...
tEMOS DE DESENVOLVER UMA "DEFESA" PARA ISSO...

[7] Comentário enviado por felipebalbi em 02/12/2004 - 11:45h:

Mto bom.
Tendo acesso físico à máquina, a senha do root não importa mais.

O jeito agora é por senha na BIOS e configurar pra dar boot direto do HD.

=P

[]'s
Felipe Balbi

[8] Comentário enviado por morvan em 02/12/2004 - 12:05h:

Jonatas, sugiriria apenas, ao invés de usar o "$ df", utilizar "fdisk -l /dev/hd?", pois o fdisk mostrará todas as partições em hd?, ao contrário do df, que mostrará só os FileSystems montados.
veja o extrato de um man df:
" df - report filesystem disk space usage

SYNOPSIS
df [OPTION]... [FILE]...

DESCRIPTION
This manual page documents the GNU version of df. df displays the
amount of disk space available on the filesystem containing each file
name argument. If no file name is given, the space available on all
currently mounted filesystems is shown. Disk space is shown in 1K
blocks by default, unless the environment variable POSIXLY_CORRECT is
set, in which case 512-byte blocks are used.

If an argument is the absolute file name of a disk device node contain-
ing a mounted filesystem, df shows the space available on that filesys-
tem rather than on the filesystem containing the device node (which is
always the root filesystem). This version of df cannot show the space
available on unmounted filesystems, because on most kinds of systems
doing so requires very nonportable intimate knowledge of filesystem
structures".
um abraço e parabéns pelo artigo.

[9] Comentário enviado por mundoguero em 02/12/2004 - 13:02h:

Caros
Não se trata de brexa de seguança nem nada disso. A segurança de um servidor não é só lógica, não adianta escolher uma senha forte, instalar e configurar um superfirewall se alguém for lá arrancar o micro da tomada! A segurança física é muitas vezes mais importante que a lógica, principalmente em grandes empresas. Tudo tem que ser pensado como um conjunto de normas a fim de se evitar o pior.

[10] Comentário enviado por mundoguero em 02/12/2004 - 13:18h:

Morvan
Escrevi este artigo sem muito tempo, obrigado pelo complemento. Faltou também explicar o comando

#chroot / vi /mnt/hdx/etc/shadow

Ele apenas faz com que o sistema adote outro ponto qualquer do file system como sendo o raíz e interpreta o comando que vier a seguir.

Assim se apenas montassemos a partição e tentassemos apagar a senha de root da partição /mnt/hdx/etc/shadow ele iria retornar um erro de falta de permissão, pois somente o root daquele file system poderia fazê-lo.

[11] Comentário enviado por jllucca em 02/12/2004 - 13:33h:

Oi,

apenas uma duvida. Não daria pra usar o chroot pra "entrar" no HD e partir dai alterar a senha?

Depois de montar o HD, algo parecido com:

# chroot /mnt/hda3
# mount /proc
# passwd -
# logout

O que me impede de "entrar" no HD e usar "passwd" pra alterar a senha???

[]'s

[12] Comentário enviado por fabio em 02/12/2004 - 14:16h:

Anderson,

O LIDS está na imagem do kernel, mas se você bootar a partir do live CD, o LIDS não estará carregado, não vai adiantar.

Antonio, isso não é falha de segurança do Linux, com acesso físico a máquina, é praticamente impossível deter os invasores. Por exemplo, tenho aqui em casa uma distro de 5MB usada pra trocar senha de usuários Windows.

Não sei se já existe, mas uma possível solução seria criptografar os arquivos do HD. Alguém sabe se existe algo nesse tipo?

[]'s

[13] Comentário enviado por Caiapó em 02/12/2004 - 14:32h:

Essa dica é muito boa partindo do pressuposto que o acesso ao computador seja esclusivamente via senha do root.
Se isso não for necessário e somente no caso de vc ter acesso à máquina, bastaria o comando:
$ sudo passwd
Enter new unix password: *********
Retype new unix password:*********
Passwd: Password updated succesfully

Fim do problema. Acesse com a nova senha criada.

[]s!

[14] Comentário enviado por morvan em 02/12/2004 - 15:40h:

Jonatas, o meu comentário não visou - jamais o farei - a enxovalhar o seu artigo, apenas, como você mesmo comentou, um complemento. com relação à questão suscitada (segurança), estão felizes os que não vêem a segurança como algo meramente em nível da caixa; de fato, em empresas que lidam com segurança - no sentido mais rigoroso - após a sessão de "boot" o sistema de IO (principalmente teclado e mouse) é travado e ao sair do trabalho a 'galera' leva consigo os mesmos. senha no bios, também, só resolve se se constranger o acesso à caixa, pois um simples RESET do bios poria tudo abaixo. lembrem-se também dos "Bioses Erasers". qualquer 'minino' conhecedor do Debug (MsDos) ou do Dbg, com poucas linhas ASM faria o 'trabalho sujo'.
um abraço.

[15] Comentário enviado por streetlinux em 02/12/2004 - 22:42h:

Parabéns pelo artigo. Muito bom.

[16] Comentário enviado por FMC em 03/12/2004 - 10:45h:

Para ter controle total da distro que está no HD a forma mais simples é bootar pelo liveCD, abrir terminal, logar como root e depois usar o chroot da seguinte forma:
#chroot <ponto de montagem> /bin/bash
depois basta
#passwd
senha
confirma
Pronto! :-)

Existem formas de criptografar o HD, saiu uma matéria sobre isso na segunda edição da Linux Magazine, da trabalho, mas acho que vale a pena!

Flw!

[17] Comentário enviado por mundoguero em 03/12/2004 - 14:30h:

Galera! Este foi justamente o motivo pelo qual me levou a escrever este artigo! Eu tentei todas essas manhas que foram postadas aqui, nenhuma funciona efetivamente, a não ser a do sudo, mas ele tem que estar instalado e o usuário previamente cadastrado para poder fazer isso. Se tentar dar o comando

"#chroot / /mnt/hda3 /bin/bash" ou

"#chroot /mnt/hda3
# mount /proc
# passwd"

Teoricamene deveria funcionar, mas o que temos?:

passwd: Authentication token manipulation error

O porquê eu não sei ainda,seria uma boa coisa para se pesquisar, mas no meu raciocínio tem algo relacionado ao processo de hash da senha de root, tipo o sistema que cria a senha é o único capaz de entendê-lá e portanto alterá-la, lembre-se, o processo de criptografia é uni-direcional. Um sistema não seria capaz de alterar a senha criada por um outro.
Portanto foi necessário eliminá-la para que então pudessemos recriar no sistema de origem.

Por favor corrijam-me se estiver falando besteira.

Todos os complementos a este artigo são bem vindos!

[18] Comentário enviado por schatten em 04/12/2004 - 12:48h:

Eu já aprendi isto num curso que fiz, porém com alguma variações...

[19] Comentário enviado por schatten em 04/12/2004 - 12:49h:

Poir isto roost e admins em geral, coloquem senha na bios e nunca deixem os boots via cd habilitados nos servidores...

[20] Comentário enviado por leo_mxs em 05/12/2004 - 12:07h:

Essa falha de segurança pode ser usada pra invadirem o meu pc ou mesmo para que um virus, altere minha configurações ???

E alguém pode explicar melhor esse lance de colocar o boot na BiOS ???

[21] Comentário enviado por lucassaqua em 15/01/2005 - 20:08h:

aqui não funcionou!!!...eu mudo td certinho no arquivo shadow...mas quando vo logar da a msm coisa...login incorrect...uso lilo 2.22

[22] Comentário enviado por hra em 04/05/2005 - 17:26h:

Ótima dica, é uma coisa que passa despercebida pela maioria das pessoas:
O acesso fisico ao computador significa o mesmo que ACESSO TOTAL.

Colocar senha na BIOS não resolve, pois basta abrir a cpu, resetar a bios (demora 2 minutos, ou menos, pra fazer isso) e lá se vai a senha.

A solução definitiva é criptografar o disco rígido. Tem um artigo recente no VOL que ensina a fazer isso. Aí além da senha do root terá uma outra senha a ser digitada no momento do boot, e essa senha não está gravada em lugar nenhum, nem é possível "limpa-la" com um LiveCd.

A questão de não ser possível usar um passwd é por causa da hash de criptografia mesmo, esta é carregada pelo kernel no momento do boot e como o boot é do LiveCd então não combina com a hash do hd montado.

Isso é outro ponto interessante, uma vez que todos os LiveCds são cópias, em todos eles está gravada a mesma hash de criptografia, que foi gerada no momento da instalação do linux original, que foi usado como base para o LiveCd. Isso quer dizer que qualquer um que tenha um cd do kurumin pode [hipotéticamente] decriptografar o arquivo de senhas de outro kurumin. Mas isso é teoria e assunto pra um artigo inteiro, e não é tão simples como parece.

O linux não é inviolável, só é mais seguro que o windows.

Parabém ao autor, e lembrando, exise também uma possibilidade extra para limpar a senha do root que é mandar o lilo entrar em modo mono-usuário, daí não pede senha nenhuma.

HRA

[23] Comentário enviado por ysnapfabiano em 17/11/2005 - 12:21h:

Todo mundo esta se preocupando com o boot do micro no setup. Devemos nos lembrar que os gerenciadores de partida tambem tem as suas vulnerabilidades.

[24] Comentário enviado por miltonb em 23/12/2005 - 10:36h:

Achei todos os comentários válidos... Mas, esqueceram de uma questão básica de que vale uma segurança de alto nível um sistema operacional se a segurança de acesso fisíco do servidor não existe... Onde "qualquer um" pode chegar no servidor e ao invés de quebra senha de root levar peças ou micro todo.

Portanto e bom ficar claro que nenhuma segurança de software é eficaz se alguém tem acesso físico. então para 99 % das dicas acima a segurança física do servidor resolve.

[25] Comentário enviado por Bruno Faria em 15/02/2006 - 20:36h:

Colocar senha na BIOS adianta de nada se o acesso físico está disponível. Sabe-se que em segundos é possível resetar a BIOS para seu estado original de tal forma que a senha simplesmente desaparece. Ai vc coloca um live cd e o servidor estará vulnerável.

[26] Comentário enviado por feraf em 30/04/2006 - 23:15h:

Artigos como esses devem sempre ser guardos. Me salvou um bocado de trabalho de reinstalar tudo só por que perdi a senha do root. Valeu cara!!

[27] Comentário enviado por badfly em 12/09/2006 - 13:36h:

Blz digamos que eu tenha acesso a root, mais naum saiba a senha tem como de alguma maneire eu ver qual e a senha.

[28] Comentário enviado por danilopalhano em 06/12/2006 - 13:27h:

Muito boa essa dica. Mas não tenho uma distro para eu realizar o procedimento. E agora, o que eu faço?

[29] Comentário enviado por Bruno Faria em 07/12/2006 - 20:45h:

Amigo, pegue 15 reais, vah a banca mais proxima e compre uma revista com um livecd. Ou dependendo da hora na lan house ai na sua cidade, compre algumas horas e queime uma midia ;)

[30] Comentário enviado por K1LL -9 em 09/12/2006 - 15:16h:

Pensando com meus botões ...

O camarada que se prestar pra criptografar um hd e e ter uma política de gerenciamento de senhas .... do tipo:

"Putz .... qual é a senha mesmo ?"

É um verdadeiro ol$%# *? C$@ e tem mais que se F$%#!! mesmo.

Será que terá ambientes corporativos onde se aventurem a isso, só um saberá a senha e não tenha guardado em nenhum outro lugar ?

[31] Comentário enviado por K1LL -9 em 09/12/2006 - 15:22h:

Mas hra , creio que se o kernel for recompilado, em vez de usar uma imagem de kernel fornecida na instalação, o hash não irá ser diferente ?

Aí não adiantará usar o "mesmo kurumin" slack ou debian.

[32] Comentário enviado por leloguitar em 13/07/2007 - 15:03h:

ah fala sério meu..
nada v issu de criptografar dados do hd
tem alguma coisa de valro la???
issu só serve pra kem tem algo q vale mto dentro do hd

pra kem tem arkivos comun nao precisa...

agora essa dica eh mto precisa... aiahuiau
abraços...

[33] Comentário enviado por dill_tche em 23/08/2007 - 17:05h:

acesso fisico é uma questão tratada a tempo e nao tem o que ver... se nao fosse necessario ter uma sala com acesso restrito, todos os servidores estariam nas recepções das empresas. Camera, crachá, senha de porta.... Isso é segurança... A sala de Ti nunca é o corredor da empresa, nao foi feita para pessoas de outros setores estarem circulando e sala dos servidores nem se fala, qualquer sistema com um live cd já era...

[34] Comentário enviado por fabioarnoni em 03/01/2008 - 21:34h:

Parabéns, muito bom o artigo !!! Estou passando por um problema sério aqui onde trabalho, algumas pessoas sabem desse macete mas para windows XP... Já coloquei senha na BIOS das maquinas e tirei os drives de boot mas quando ligam, elas tem aquela maldita opção de ficar apertando F8 e ai aparecem todos os drives e você escolhe um para bootar, ou seja, a senha não adianta nada e nada se resolve e o pior de tudo é que não existe uma opção no BIOS que desabilite essa opção na inicialização ... Essa questão de poder tirar senha de admins via live CDs é muito séria pois usuarios comuns tem cada vez mais acesso à essas coisas e como se proteger em uma escola com 80 computadores onde não há como mudar o BIOS ????

[35] Comentário enviado por LeoWalker em 23/01/2008 - 15:16h:

Senhores.... pode-se montar um live sem esquentar a cabeça num simples pen-drive. o que pega mais ainda ... ou seja, o cara vai la e arranca o drive de CD mas ai temos um coleguinha esperto e cópia o live num pendrive, vai la e f@#*@ tudo.....E uma questão complicada, o correto é um NOC ou CPD e responsabilizar alguem pelas maquinas. " detalhe a sala deve sempre ficar trancada ... rsrsrs "

[36] Comentário enviado por dill_tche em 03/06/2009 - 16:47h:

Valeu pela dica Jonatas, hoje precisei fazer isso. No Suse 11.1 tirei entre os dois pontos e quando fui entrar deu um erro, como se eu tivesse já tentando as 3 chances da senha. Então voltei como o LIVE CD do OpenSUSE mesmo, e coloquei entre os dois pontos a mesma senha criptografada do meu usuario restrito e na hora de entrar deu certo. Aos que pensam que o linux com isso não é seguro, estudem um pouco de segurança de informação, tem algo falando sobre segurança física. ZZZzzzZZZzzzzZzz