[GTER] SQUID squid-3.1.0.14 + TPROXY

[Herbert Faleiros]

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...

:)

-- 
Herbert