[GTER] SQUID squid-3.1.0.14 + TPROXY

[Renato Murilo Langona]

Como citei, novamente, vc tem varias formas de controlar os limites, nao 
apenas limits.conf...

Para ficar mais claro. Vamos usar o seguinte exemplo. Vc usa o kernel 
HUGE do slackware, correto? Ele consome bastante memoria e recursos por 
si so, porem, tenho certeza que isso nao te atrapalha, ja que vc faz seu 
tuning "on-the-fly", correto? Essa eh sua administracao e ela, 
provavelmente, nao te atrapalha, ou seja, vc nao deixa que o kernel 
ENORME, cheio de recursos, funcionalidades e etc que NAO SAO para seu 
hardware subutilizem ou denigram seu hardware/sistema. Eh exatamente 
isso que vc faz ao modificar o kernel. Vc eh o administrador e deve 
estar no controle do sistema e nao o contrario, utilizando os recursos 
que seu conhecimento permitirem, sejam eles default ou nao...

Um comentario dos proprios desenvolvedores do kernel sobre a seguranca 
de alterar os limites do mesmo. Do fs.h:

/*
 * It's silly to have NR_OPEN bigger than NR_FILE, but you can change
 * the file limit at runtime and only root can increase the per-process
 * nr_file rlimit, so it's safe to set up a ridiculously high absolute
 * upper limit on files-per-process.
 *
 * Some programs (notably those using select()) may have to be
 * recompiled to take full advantage of the new limits..
 */


#define NR_FILE  8192   /* this can well be larger on a larger system */


Alias, estamos esquecendo o principal, a funcao da maquina, nesse caso, 
proxy/cache... E isso ressalta o que vc disse abaixo:

"Se o ambiente é controlado e você sabe o que está fazendo, ok!"

Abs!


Herbert Faleiros escreveu:
> 2009/11/21 Renato Murilo Langona <renato at linuxsecurity.com.br>:
>   
>> Na verdade, pela sua linha de pensamento, o perigo vai morar em utilizar o
>> default e nao em alterar o kernel :-) Ateh porque dificilmente vc utilizara
>> o padrao menor do kernel tbem para suas aplicacoes ou servicos... Se vc nao
>> for root nao vai ultrapassar os limites que o administrador impor para o
>> sistema de qualquer forma, por isso essa nao eh a questao, correto?
>>     
>
> depende, se jogou o limite (default) lá no alto (alterando o kernel),
> qualquer usuário vai seguir o que o kernel setou/configurou. Lembre-se
> que no Slackware não temos o /etc/security/limits.conf, então o
> sistema usa o que o kernel repassa, não adianta configurar isso
> manualmente, na verdade adianta, mas vai ser complicado manter (por
> usuário).
>   
>   
>> Esta claro que vc deve administrar os limits, conforme mencionei...
>>     
>
> mais ou menos, deixo o sistema default, sem modificações globais e
> aumento *apenas* o que a aplicação (e não o usuário) precisa a mais
> (por processo). Como no caso do Squid.
>   
>> Em um servidor proxy, com squid "unlimited" ou com limite altissimo, as
>> probabilidades de DoS ou "problemas de seguranca" sao exatamente os mesmos
>> com ou sem alteracao, afinal seu limite ja esta alto de qualquer forma,
>> correto?
>>     
>
> depende do hardware e do nível de "confiabilidade" que você tem na
> aplicação, deixar qualquer coisa usar um limite alto é diferente,
> deixar algo controlado, que você sabe o que faz usar um limite alto é
> outra coisa.
>
>
>   
>> Alto em termos tambem, ja que, com o poder de processamento dos
>> servidores atuais, eh tudo uma questao de tuning...
>>
>> Muitos administradores tem medo de alterar o kernel, mas a maioria segue as
>> receitas de bolo para "performance tuning" on-the-fly na Internet e, a
>>     
>
> o problema em modificar algo como o que citou no Kernel (patch) é que
> a modificação é global, você deixa o Squid feliz, mas abre a porteira
> p/ todo mundo.
>
>
>   
>> primeira coisa que muitos fazem, eh realizar alteracoes de portas limites,
>> hard e soft limits, numero de inodes, file-max, brincar com sysctl e etc...
>> Isso sim eh um perigo realizar sem calcular a escalabilidade de seu servidor
>> e sua utilizacao,
>>     
>
> analogia: um bruta-montes com um machado na frente de um servidor faz
> um estrago daqueles...
> Não adianta "brincar", o cara tem que saber o que está fazendo.
>
>
>   
>> ateh porque nao adianta setar limite alto em um servico
>> que vai utilizar uma funcao do kernel com limite menor, correto? Nao teria
>> nexo...
>>     
>
> o Kernel, desde a série 2.4 suporta essa configuração, não há
> limitação, há configuração "default" (parâmetros pré-configurados). Se
> fosse assim, não adiantaria usar ulimit/sysctl, o Kernel não deixaria,
> já que foi compilado com uma restrição em relação a isto.
>
>
>   
>> Alterar o teto no source nao libera esse teto para toda e qualquer
>> aplicacao. Como administrador, vc continua no controle de tudo, seja via
>> limits, via sysctl/ulimit, ou por vias menos convencionais como grsecurity,
>> lids, lsec, etc...
>>     
>
> aí você inseriu toda uma estrutura que não existe por default no
> sistema, que na verdade é até mais restritiva que não "patchear" o
> kernel.
>
>
>   
>> Por isso a seguranca do sistema esta em sua administracao, pura e simples...
>>     
>
> claro! Se o ambiente é controlado e você sabe o que está fazendo, ok!
>
>
>   
>> Alias, muito bom poder debater sobre esse assunto, lhe agradeco por isso...
>>     
>
> :)
>
>