[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Atualizações do debian!



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/02/2007 02:06 AM, Marcos Lazarini wrote:
> Em 31/01/07, Felipe Augusto van de Wiel
> (faw)<felipe@cathedrallabs.org> escreveu:
>> On 01/31/2007 08:31 PM, Marcos Lazarini wrote:
>> > Em 31/01/07, Felipe Augusto van de Wiel
>> > (faw)<felipe@cathedrallabs.org> escreveu:
>> >> > E quando ele pergunta "deseja usar a versão do mantendor ou a versão
>> >> > atual?" O que acontece?

[...]
> Espero que vc não esteja insinuando que não devo mexer nos arquivos de
> configuração!

	Não estou "insinuando" nada.


> Vou dar outro exemplo: eu tenho um roteador desprovido de capacidade
> de processamento (um 486). Porém notei que de tempos em tempos a
> máquina ficava lerda por alguns segundos (30~40s) e depois voltava.
> Descobri que ela tinha vários serviços cron que ligavam a cada 5 min
> ou 10 min, todos um por cima do outro (mrtg, logcheck, o do sar, são
> os que me lembro agora). Entrei lá e mudei p/ cada um começar num
> minuto diferente e agora a máquina está mais 'suave'. Não ia achar nem
> um pouco legal perder essa configuração a cada atualização de
> segurança...

	Você não deveria perder estas configurações.

	Quando você configura o postfix e tem uma atualização de
segurança, ele deveria atualizar o pacote sem tocar nos seus
arquivos, no entanto isso pode acontecer em alguns arquivos se
uma mudança no arquivo de configuração for necessária e entrar
em conflito com suas opções, por isso, muitos arquivos tem uma
seção mágica pro DebConf, e outros tem uma área ".d" pra você
fazer suas personalizações.


> Então p/ mim, perder isso seria um bug - quero que ele pergunte; 

	OK, pra certas pessoas o fato de ter o Windows instalado
no computador é um bug, nem por isso as pessoas podem todas afirmar
isso em conjunto como se fosse algo líquido e certo.


> agora p/ uma pessoa que queria automatizar a atualização e ele 
> parar peguntar, isso vai ser bug p/ ele tbm! conflito de
> interesses...

	Hmmm... se a configuração estiver correta, ele não vai
perguntar, parece que você não está entendendo isso. Você pode
fazer o mesmo que fez com o cron de outra forma, usando o cron.d
e sem ter conflitos.

	O apt e o cron-apt tem configurações que permitem certa
flexibilidade na hora de tomar ações quanto a decisões, além
disso, é como eu disse, pode ser que você prefira ficar com
seu servidor vulnerável ao invés de perder suas configurações,
essa é a opção de cada sysadmin.


> (ainda comentando sobre o cron: outra coisa que fiz foi mudar o
> horário padrão dos cron.{daily|weekly|monthly}, pois são todos 6 e
> pouco por padrão. Alguns programas, como o locate, logcheck (p/ citar
> dois), demoram um certo tempo, e ai o cron de um período encavalava no
> outro, a maquina usava swap, etc e tal)

	Pra isso existe divert e outros recursos, pra não
perder a configuração, ou você acha que é a única pessoa
do mundo que muda esses horários? :)


[...]
>>         Então eu acho que você não cuida de servidores críticos.
>> É melhor ter o serviço seguro por default do que sua configuração
>> querida. :-)
> 
> Certamente a configuração padrão funciona, mas ela pode não ser
> adequada - veja situação que descrevi acima. Se procurar um pouco,
> certamente vão existir casos em que não é nem um pouco interessante a
> substituição do arquivo de configuração (o que me vem a cabeça agora é
> o 915resolution - ele só funciona depois q vc o configura)

	E por isso você pode configurar o apt pra não trocar o arquivo
e não questioná-lo sobre isso.


> Mas eu parto do pressuposto de que se vc mexe no arq. de configuração
> sabe o que está fazendo, e assume a responsabilidade - não acho que o
> mantenedor do pacote deva ditar qual deve ser minha preferência sobre
> o aplicativo que ele mantém.

	O mantendor do pacote não faz isso... não fale besteira.


>> > De qquer maneira, queria saber qual a diferença, e depois do pacote
>> > instalado, dá bem mais trabalho saber...
>>
>>         debdiff, aide, fcheck e controle de versão serve exatamente
>> pra isso. :-)
> 
> Essas coisas oferecem rollback? :-)

	Oferecem.


> Agora não tenho noticia de um gerenciador de pacotes que use controle
> de versão nos arquivos q ele instala

	O apt tem um protótipo pra isso e você pode mudar o seu /etc pra
usar svk naturalmente e controlar as mudanças nas suas configurações.


> Pelo menos já é um começo...

	Yeah... sure.


[...]
> Certamente - mas se a janela for de 1 h ou 1 dia, a meu ver não faz
> muuita diferença: vc foi exposto da mesma maneira e pode ter sido alvo
> da mesma forma. Por isso, são necessários outros métodos (como os IDS
> q vc citou acima) p/ cercar por outros caminhos eventuais explorações
> de vulnerabilidades. Estou pensando nas relacionadas a escalada de
> privilégios; se o prob. é um DoS, ai é potencialmente mais tranquilo.

	Não vou nem discutir o aspecto de ficar exposto por 1h ou por
24h, quando menor a janela de exposição melhor, e você pode configurar
atualização pró-ativa, sob demanda, ou seja, sai a atualização você
dispara os robôs.


> Sem contar que numa intranet, o ambiente supostamente tem uma relação
> de confiança maior do que com outro micro da internet. Agora, em
> servidores o assunto é bem diferente.

	Tem certeza? _Vários_ estudos mostram que a maioria dos ataques
bem sucedidos é interna ou com participação interna.


>> > Se fosse 100% seguro automatizar assim as atualizações, eu aposto que
>> > certamente já viria ligado por default, ou então seria mto fácil ligar
>> > isso. Prefiro a moda antiga ainda :-)
>>
>>         É 100% seguro (com security stable). Tanto que muita gente usa.
>>         ;)
> 
> A pergunta que não quer calar é: pq não é ao contrário então? já não
> vem ligado e desliga se vc não quiser?

	Por que o Debian tem uma postura conservadora, ele não assume
que você tem conexão 24h por dia e logo não assume que você queira
automaticamente atualizar listas e pacotes.


> Em ultimo caso, eu faria todas as máquinas automáticas, mas a minha
> eu ia atualizar na mão p/ acompanhar o processo e ver se correu tudo
> bem nas outras - eventualmente pode ser necessário um procedimento de
> correção.

	Eventualmente pode ser necessário desentupir o banheiro, ou
seja, "shit happens". O ponto é que há formas de automatizar o processo
com segurança, se você não teve boas experiências com isso, pode apontar
os problemas e suas impressões, mas não defenda que o processo é
fundamentalmente falho, pois ele não é.

	Caso não tenha ficado claro, eu cuido de mais de um servidor
fazendo atualizações automáticas com alta periodicidade sem problemas
nos últimos 12 meses.

	Abraço,

- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFw4bPCjAO0JDlykYRAiGuAJ9srGwgGw8Q/DnXLnxvcIsR29/vgwCcDuiA
aCYjkE7UK09nsz5tVgBkUgI=
=Aukv
-----END PGP SIGNATURE-----



Reply to: