Sobrecarga em tasks do Cron

Autoprojete-se no seguinte cenário da sua infra-estrutura: Existem diversas tarefas agendadas via Cron em seu sistema operacional. No entanto, por alguma razão, elas levam mais tempo para serem executadas do que o previsto. Por que? O que pode estar havendo? Muitas pessoas têm como conceito que as coisas movidas por tecnologias ou funcionam ou não funcionam. No entanto, existem alguns casos que perdas de integridade e confiabilidade não são tão brutas e repentinas. Elas ocorrem vagarosamente assim como um relógio de quartzo pode atrasar eventualmente, enquanto um relógio feito de isótopo de césio 133 apenas atrasará após centenas de anos de utilização, isto é, o início do seu respectivo clock.

 

Basicamente temos que esses atrasos podem significar que as tarefas começaram a se sobrepor e a serem executadas ao mesmo tempo. Se esses cronjobs estiverem atuando sobre os mesmos dados de um banco de dados, por exemplo, isso pode gerar uma corrupção de dados. Se eles estiverem fazendo um grande processamento de dados, esta ação poderá ter como consequência um elevado custo energético para a CPU da máquina. Por causa dessa alta carga, esses cronjobs iniciam um círculo vicioso resultando em mais problemas para o administrador do sistema operacional, uma vez que, os cronjobs mantêm os seus respectivos lançamentos e se sobrepõem uns aos outros.

 

No mundo GNU/Linux sempre estamos nos aperfeiçoando. E para que isto ocorra, problemas precisam surgir. O problema de sobrecarga do Cron apareceu no nosso cotidiano, e uma evolução das nossas ferramentas tornou-se necessária ou pelo menos a integração de soluções modulares disponibilizando-se como algo mais performático e eficaz.

 

Flock

O flock é uma ferramenta muito interessante para o gerenciamento de arquivos de bloqueio. Esses arquivos de bloqueio são usados para determinar se um script ou um aplicativo já está em execução (comparável a um arquivo PID que contém a identificação do processo do script sendo executado). Se o bloqueio existe, o cronjob não será iniciado. Se o bloqueio não existe, é seguro lançar o cron.

 

Veja o seguinte exemplo comum, onde um cron é executado a cada minuto no servidor.

$ crontab -l
* * * * * /usr/bin/php /www/app/cron.php

Se o script leva mais de um minuto para executar, eles começam a se sobrepor.

 

Para evitar isso, você pode mudar com o exemplo flock abaixo.

$ crontab -l
* * * * * /usr/bin/flock -w 0 /root/cron/cron.lock /usr/bin/php /www/app/cron.php

 

O exemplo a cima requer que o flock gerencie esses arquivos de bloqueio. Se isso ainda não existe no seu sistema, a instalação deve ser tão simples como um yum install flock ou apt-get install flock, dependendo de sua distribuição Linux.

 

No momento em que o flock começa, ele bloqueia o arquivo .lock que você especificar no comando. Você pode ver isso ao solicitar o usuário/script que está tendo o bloqueio sobre esse arquivo.

$ fuser -v /path/to/cron.lock
USER        PID ACCESS COMMAND
cron.lock:           root       7836 f…. flock
root       7837 f…. php

 

Ele vai mostrar o processo de IDs (PIDs) do script que está mantendo o bloqueio. Se nenhum script estiver mantendo o bloqueio, o comando fuser retornará simplesmente nada.

$ fuser -v /path/to/cron.lock

 

Então, o flock é uma boa maneira de evitar a sobreposição de cronjobs usando uma ferramenta de linha de comando adicional.
 

 

 

Pgrep

Outro método, sem o uso de arquivos de bloqueio, é utilizar um liner bash-one bem simples que verifica o arquivo de execução atual e o executa se ele não estiver funcionando. O grande segredo aqui é envolver seu crontask em um nome exclusivo do bash-script, assim:

$ cat /root/cron/cron.sh
#!/bin/bash
/usr/bin/php /www/app/cron.php

$ chmod +x /root/cron/cron.sh

 

No seu crontab, ele deve ser listado assim:

$ crontab -l
* * * * * /www/app/cron.sh

O comando acima irá, assim como o primeiro exemplo, executar o nosso script PHP a cada minuto através de um script. Para evitar a sobreposição, ele pode também ser alterado para isto:

 

$ crontab -l
* * * * * /usr/bin/pgrep -f /root/cron/cron.sh > /dev/null 2> /dev/null || /root/cron/cron.sh

O comando pgrep irá retornar falso se não encontrar um processo de execução correspondente ao primeiro argumento, /root/cron/cron.sh. Se ele retornar falso, vai processar a segunda parte da comparação OR  (a linha vertical dupla, ||). Se o processo de execução foi encontrado, pgrep irá retornar o ID do processo (PID) e Bash não vai continuar para a segunda parte do argumento OR, já que o primeiro já retornou verdadeiro.

 

A dica aqui é usar nomes de script muito originais. Se o nome é muito genérico (como “cron.sh”), pgrep pode retornar IDs de processo a partir de outras tarefas cron em execução e não executar o cron que você queria.

 

 

Utilizando bloqueio de arquivos dentro do script

Se os exemplos acima não estão disponíveis para você, você ainda pode usar o conceito de arquivos de bloqueio em seu aplicativo. Um dos primeiros comandos em seu script poderia ser verificar a existência de um arquivo de bloqueio. Se ele existir, o script poderia simplesmente sair (1) do aplicativo e parar de rodar. Se o bloqueio de arquivo não existir, o script poderia criá-lo e evitar que o próximo trabalho seja executado. Como último passo no seu script, você remove o arquivo de bloqueio para indicar que o script terminou e permitir que a próxima execução continue.

 

Baterias – Mitos e realidades

Baterias. Elas estão presentes em todos os dispositivos que usamos, desde o brinquedo da criança até o circuito embarcado utilizado pela NASA em suas sondas eletromagnéticas. Tudo que possui massa precisa de energia, de força para realizar algum tipo de trabalho. Por isso, a bateria está contida mais do que possamos imaginar. Se nos humanos há carbonos, nas máquinas há baterias ou de forma mais fundamental, elétrons.

Quando a energia elétrica da sua distribuidora elétrica falha, são elas que tomam pra si a responsabilidade de suportar toda a infraestrutura antes suprida pela energia elétrica alternada anterior. Se você possui um no-break (nome sugestivo) em casa, compreende a importância desta forma de energia – a bateria. Poucos sabem disso, mas nem sempre a energia elétrica é redisponibilizada em poucos minutos por consertos, mas sim, por deslocamentos energéticos advindos de outra área de distribuição energética ou por gigantescas e potenciais baterias que suprem a falha inicial. Com toda certeza, estaríamos perdidos sem esse tipo de energia armazenável.

 Voltando ao nosso nicho tecnológico e as aplicações dessa forma de energia à nossa área de trabalho temos um cenário comum: grande parte dos problemas nos notebooks e afins ocorrem envolvendo baterias. Muitas vezes, não por defeito do produto ou do fabricante mas por uma utilização inadequada. A seguir alguns dados sobre as baterias:

 Atualmente, as baterias mais utilizadas em dispositivos portáteis são, geralmente, baterias de íons de lítio, também denominadas Li-Ion. Antes delas, víamos no mercado outros tipos de baterias formadas por outros compostos químicos. Estes eram mais prejudiciais e menos performáticos que a bateria de Li-Ion, por isso, foram substituídos. Por exemplo, alguns compostos utilizados no passado na fabricação de baterias eram de Níquel-Cádmio (Ni-Cad) ou Níquel e Hidrato Metálico (Ni-MH). Além disso, as baterias de lítio conseguem armazenar até 3 vezes mais carga do que as Ni-Cad e até 2 vezes mais do que a Ni-MH.

 Informações e cuidados que os usuários deveriam ter

A maior parte das baterias deste tipo são compostas por 3 a 9 células independentes. Quando expostas a altas temperaturas, acima dos 60 graus, ou caso sejam carregadas além de seu limite energético, poderão explodir, devido à instabilidade do lítio. Também se as células se mantiverem completamente descarregadas durante muito tempo, acabam sofrendo um fenômeno físico-químico chamado oxidação.

 As baterias Li-Ion, utilizadas em computadores portáteis, estão geralmente associadas a um circuito inteligente, que controla a carga da bateria. Este circuito tem duas funções: interromper o fornecimento de energia quando a carga atinge um valor limite; interromper o gasto de energia quando esta atinge valor demasiado baixos. Para tal, o circuito está montado num componente externo à bateria e não em cada célula. Assim, evita-se que as células, em conjunto, entrem num estado de descarga profunda, potencialmente irrecuperável.

Agora, note bem: ao contrário do que muitos afirmam e do que muitas empresas recomendam, não deixem que a sua bateria fique totalmente descarregada. E não tente utilizá-la novamente quando o computador entrar em modo de hibernação. Ao contrário das baterias Ni-Cad e Ni-MH, as Li-Ion não ficam “viciadas”, isto é, não sofrem efeito de memória. Acontece sim que, muitas vezes, certas baterias passam a durar muito menos tempo do que inicialmente. E isso é normal. Há um desgaste natural pela utilização tal como ocorre com as rochas na área de geologia.

 Este problema deve-se à calibração deste componente. Com o tempo, o circuito controlador de carga começa a perder a sua capacidade de calcular corretamente a carga existente na bateria pois, não controla cada célula individualmente.

Por isto, o circuito interrompe o gasto de energia, muito embora as células se mantenham completamente saudáveis. A solução é, como já deve ter percebido, calibrar o circuito, reajustando os seus padrões. Para tal, recomenda-se que realize um ciclo de carga/descarga completo de 30 em 30 ciclos normais de utilização.

E então como faço isso? Carregue a bateria por completo e mantenha-a ligada à corrente por cerca de duas horas. Depois, utilize o portátil, só com a bateria, até que esta se descarregue por completo e o computador entre em modo de hibernação. Mantenha-o nesse estado durante pelo menos cinco horas. Por fim, volte a carregar a bateria.

Como já deve ter reparado, quando utiliza o computador portátil apenas com a bateria, este diminui a utilização alguns recursos: diminui o brilho do monitor, a velocidade de utilização do processador, etc. Deve descarregar a bateria gradualmente, não de forma brusca. Não tente utilizar em pleno todas as capacidades do seu computador, a não ser que este esteja ligado à corrente.

Mas há mais! Se prentender guardar a sua bateria e utilizar o computador apenas com o adaptador, leia com atenção. Vários estudos comprovam que as baterias Li-Ion se deterioram mais rapidamente quando completamente carregadas ou quando descarregadas, por isso, o ideal é deixar a bateria com 50% de carga, no máximo. Além disso, conserve-as a baixas temperaturas – mas não no congelador!

Uma outra informação importante é que não há prejuízo em ter a bateria 100% carregada e estar com o adaptador AC/DC ligado, pois a bateria assim que chega aos 100% deixa de receber energia. Após a carga estar completada é feito um bypass diretamente para o sistema de alimentação do notebook.

No entanto, existe uma desvantagem em manter a bateria no portátil quando ligado à corrente, mas apenas, se esta estiver a sofrer aquecimento gerado pelo hardware do portátil. Portanto:

  • Uso normal do portátil sem aquecer (CPU e disco na ordem dos 30~40ºC) – manter a bateria.
  • Uso intensivo que leva a um grande aquecimento (Jogos) – retirar a bateria para que esta não aqueça.

O calor, aliado ao fato de estar a 100% de carga são o grande inimigo da bateria e não o cabo do transformador, como muitos pensam!!

Outro mito diz que se deve utilizar o portátil sem a sua bateria para maximizar o seu tempo de vida útil. Embora possa ser benéfico para a bateria, o seu portátil estará mais suscetível a picos de tensão provenientes da rede elétrica. Ainda assim, se vai utilizar o computador sempre no mesmo local, ligado à corrente, durante muito tempo, o melhor é mesmo é retirar a bateria para evitar que esta fique exposta a altas temperaturas.

Nunca descarregue e carregue a bateria de forma contínua. Estes componentes têm um limites de ciclos de carga/descarga. Quando se deve fazer a substituição da bateria de lítio?

Façam-no apenas quando esta estiver mesmo no fim da sua vida e já não suportar mais cargas. Não guardar a bateria para futuras utilizações após a compra de uma nova bateria pois esta acabará por se degradar com o tempo de inutilização. Muita atenção à data de fabrico da bateria e se não for da marca original muito cuidado com as tensões (volts) e correntes da mesma (amperes). A durabilidade média de uma bateria de lítio é de 3 anos de utilização moderada.

5 Dicas

  • Utilize a bateria até o computador entrar em modo de hibernação;
  • Não exija demasiado do computador quando utilizar apenas a bateria;
  • Guarde a bateria em locais frios e com cerca de 40-50% de carga;
  • Utilize regularmente a bateria do portátil mas evite o sobreaquecimento;
  • Realize a calibração da bateria uma vez por mês;

Referências:

  1. MELLO, S. Pilhas e baterias: indústria terá de oferecer opções para descarte. Saneamento Ambiental, v. 10, n. 61, p. 26- 29, 1999.
  2. VINCENT, C.A.; BONINO, F.; LAZZARI, M. e SCROSATI, B. Modern batteries: an introduction to electrochemical power sources. Londres: Edward Arnold, 1984.
  3. http://blogdokauffmann.wordpress.com/2007/08/16/baterias-de-litio-uma-alternativa-ao-chumbo-ao-cadmio-e-ao-hidreto/

 

Mandatory Access Control – AppArmor

Um servidor bem permissionado significa um servidor mais seguro. Isso desde os primórdios até os dias atuais. Por isto, devido a essa poderosa e conservadora forma de evitar ataques apresentaremos neste artigo como se proteger de modo eficiente.

Mandatory Access Control (MAC) e Discretionary Access Control (DAC)

MAC e DAC são dois modelos de controle de acesso que se diferem nas entidades que especificam as permissões.

No modelo DAC as permissões de um recurso são especificadas pelo utilizador que é dono do recurso. O dono do recurso decide quem pode, ou não pode, realizar as varias operações sobre o recurso (o conjunto de operações de um recurso varia conforme o tipo do recurso, um arquivo, um socket, etc). Um exemplo do modelo DAC é o controle de acesso a arquivos num sistema UNIX, onde as permissões de leitura escrita e execução são especificadas pelos donos dos arquivos. O problema do modelo DAC é que qualquer processo iniciado por um utilizador tem as mesmas permissões que esse utilizador. Isto pode comprometer a segurança, caso uma aplicação tenha algum bug ou seja uma aplicação “mal intencionada”, pois a aplicação tem as mesmas permissões que o utilizador que a iniciou.

No modelo MAC as permissões são especificadas pelo sistema. Essas permissões são baseadas numa política global, no nível de segurança do utilizador e na classificação do recurso. A política de segurança não pode ser alterada ou removida a não ser pela utilização de operações privilegiadas. Este modelo permite implementar uma política de segurança que siga o princípio least privilege, onde cada aplicação apenas deve ter autorização para realizar as operações estritamente necessárias para o seu bom funcionamento, sendo as restantes operações não permitidas. Desta forma é criado um ambiente mais seguro, pois é limitada a quantidade de estragos que uma aplicação “mal comportada” pode fazer. Por exemplo, se limitarmos o acesso de uma aplicação editora de texto apenas ao que está sendo editado, mesmo que a aplicação tenha alguma vulnerabilidade, esta não conseguirá comprometer mais nada além do arquivo que está sendo editado.

O DAC é bem conhecido, e este artigo não contemplará ele. Focaremos no MAC, razoavelmente pouco conhecido, mas muito eficaz.

Atualmente existem vários tipos de MACs: SELinux da Red hat, AppArmor utilizado no Ubuntu, Smack um MAC focando em simplicidade e o Tomoyo que possui uma espécie de inteligência artificial baseada no histórico de ações tomadas previamente. Destacaremos, de forma breve, o poder de fogo do AppArmor.

AppArmor

O AppArmor foi incluído no kernel Linux oficial em sua versão 2.6.36, mas seu desenvolvimento (e uso) começou já em 1998, na distribuição GNU/Linux Immunix. Com a aquisição pela Novell em 2005, o AppArmor (aparentemente o principal motivo da aquisição) foi adotado no SUSE Linux Enterprise. Num caso infeliz e bastante noticiado, no entanto, em 2007 a equipe de desenvolvimento do AppArmor foi dispensada pela empresa.

O AppArmor se baseia nos caminhos dos arquivos para definir seu contexto de segurança. Os arquivos de configuração, assim com os domínios de segurança, estão nos diretórios /etc/apparmor/ e /etc/apparmor.d/.

Assim como os demais sistemas MAC, o AppArmor também dispõe de dois modos de operação: enforcement (ativo) e complain (reclamação, equivalente ao permissivo do SELinux: relata violação das políticas mas não impede nada).

Para desabilitar o AppArmor como um todo, basta parar o serviço deste.

As políticas se localizam em /etc/apparmor.d/. Dentro deste diretório, temos os mais vastos serviços ou utilitários que rodam sobre a autoridade do AppArmor. Por exemplo:

                      /usr/sbin/tcpdump → /etc/apparmor.d/usr.sbin.tcpdump

                      /sbin/dhclient3 → /etc/apparmor.d/sbin.dhclient3

O perfil é associado ao programa no momento em que este é executado. Portanto, como nos informa a man page do AppArmor, não é possível confinar um programa que já esteja em execução.

Os perfis em uso, juntamente com seus respectivos modos de operação no momento, podem ser obtidos com uma consulta ao securityfs (já montado por padrão pelo Ubuntu):

                      root@Umbreon ~ # cat /sys/kernel/security/apparmor/profiles

                      /usr/sbin/tcpdump (enforce)

                      /usr/lib/connman/scripts/dhclient-script (enforce)

Esta saída significa que nosso sistema atualmente tem quatro perfis de segurança, para os dois programas exibidos na saída, e o modo de operação de todos eles é o enforce.

O AppArmor trabalha com o daemon auditd para exibir suas mensagens. Se o audit não estiver instalado, ele utilizará as mensagens de kernel normal do Linux, ou seja, o syslog. É muito interessante instalar o auditd e utilizá-lo para que tenhamos um log limpo do nosso sistema e do que ocorre com ele.

A visualização do MAC AppArmor é simples. Basta executarmos o comando apparmor_status, que surgem nossos perfis e políticas:

               root@lab01 ~ # apparmor_status

               apparmor module is loaded.

               24 profiles are loaded.

               2 profiles are in enforce mode.

                /sbin/dhclient3

                /usr/sbin/tcpdump

              4 profiles are in complain mode.

              /bin/ping

              /usr/lib/dovecot/pop3

             /usr/lib/dovecot/pop3-login

             /usr/sbin/avahi-daemon

            4 processes have profiles defined.

             1 processes are in enforce mode :

            /sbin/dhclient3 (859)

           1 processes are in complain mode.

            /usr/sbin/nmbd (825)

Para alterar perfis do AppArmor basta utiliza o sintaxe:

aa-mode command

            root@lab01 ~ # aa-enforce /bin/ping

            root@lab01 ~ # aa-complain /etc/apparmor.d/*

Já me disseram que o AppArmor não é tão bom por ser muito fácil de desativar — basta parar o serviço. Porém, não creio que essa característica seja, de fato, uma falha de segurança. O próprio bootloader GRUB possui opções como essa.

A comparação do AppArmor com o SELinux é inevitável, uma vez que estes são os dois únicos sistemas MAC a virem ativados por padrão em alguma distribuição GNU/Linux. O SELinux em Red hats e o AppArmor no Ubuntu. De uma forma geral, enquanto o SELinux é capaz de se interpor fortemente entre o administrador e seu objetivo, o AppArmor parece ser menos intrusivo.

Todavia, como segurança e facilitade são sempre opostas, tem-se a impressão de que o AppArmor é menos seguro, já que este, possui menos inconvenientes. O importante, no entanto, é alcançar o objetivo principal dos sistemas MAC: o controle de acesso. Se seu sistema MAC preferido é capaz de bloquear o acesso de serviços do sistema a arquivos sensíveis, seja ele AppArmor ou SELinux, parabéns pela segurança implementada.

Monitoração – Essência de qualquer alta disponibilidade

Nagios é uma ferramenta muito interessante (e eficiente) para monitorar serviços e servidores. Por outro lado, pode ser uma tarefa árdua e trabalhosa para alguns. Precisam ser investidas algumas horas em cima de vários arquivos de configurações para poder colocá-lo em funcionamento. Nós da Intercom vimos o quanto isso pode tirar a eficiência do Nagios para os nossos clientes, pois hoje todos têm horror a qualquer serviço ou aplicação sem interface gráfica. Por isso apresentamos o Nagios Web Config.

O Nagios Web Config é um software que serve para configurar os hosts, serviços, grupos de hosts, comandos e todas as demais configurações do Nagios (exceto a configuração inicial do mesmo) de forma visual e prática utilizando para isso o seu browser. Por isso mesmo, ele já foi planejado para ser implementado na própria sidebar do Nagios, o que facilita ainda mais seu uso.

E como ele trabalha ? Ao ir adicionando/deletando/editando as configurações ele vai armazenando as mesmas em um DB MySQL. Depois você pode solicitar que ele escreva as configurações e ele próprio irá gerar os arquivos necessários sem que haja necessidade de editá-los manualmente. Além disso, como os dados ficam num DB caso você precise reinstalar o servidor (ou por exemplo decida colocar o Nagios em outro servidor), não haverá necessidade de refazer todas as configurações.

 

Para quem ainda não conhece, o Nagios Web Config é uma excelente ferramenta que permite configurar o Nagios através do browser, tornando essa tarefa muito mais rápida e agradável.

 

Outro amigo dos profissionais que trabalham com o Nagios realizando monitoração é o  nagstamon. Este é um software que permite que você controle múltiplos servidores Nagios diretamente no seu desktop, sem a necessidade de uso do browser. Ele pode residir no systray ou pode ser visualizado como uma barra de status flutuante, resumindo ou exibindo todos os alarmes existentes. Além disso, ele possibilita a conexão aos servidores pelo seu menu de contexto, possui alarmes sonoros e também permite o uso de expressões regulares e categorias para realização de filtros, entre tantos outros recursos.

Leia a lista completa de recursos e baixe o software aqui.

Juntamente com o Nagiosweb essa é uma ferramenta essencial para administradores de servidores Nagios.

 

 

Se você tem um nagios, talvez verificar os hosts pelo painel do próprio não seja tão eficiente quanto utilizar o Nagstamon.

Claro que você pode configurar o Nagios pra enviar email, sms etc. Mas se você não olha freneticamente todos os emails que chegam e também não liga muito para os sms que chegam, você instala esse nagstamon e ele fica no canto no Painel da sua máquina, e então atualiza constantemente e mostra os alarmes que estão rodando pra você.

Olha só um exemplo simples que ta aqui na minha máquina agora:

E quando você passa a barra por cima do Warning, ele mostra mais detalhes:

Pra instalar esse cara no Debian por exemplo: basta executar um aptitude install nagstamon. É possível compilá-lo utilizando o tar.gz também contido no sourceforge.

 

Depois de instalado vá em Aplicativos -> Sistema e abra o programa.

Aparecerá uma tela como essa:

Não vou detalhar, pois o que se deve inserir em cada campo é bem sugestivos.

E fim! Só dar o OK e nem precisa olhar email nem nada, porque os alarmes irão piscar direto no seu painel!

Pra quem usa firefox, existem plugins para ver alarmes como este.

 

Ulimit – Ilimitando sua administração

Hoje, teremos como objetivo esclarecer como impôr limites a nível de processos em execução, quotas de memória, quotas de espaço em stack, número de arquivos abertos, etc.

Isto pode ser útil para evitar que um usuário ou serviço utilize sem limites o recurso do hardware. Com as políticas ulimit devidamente aplicadas estamos protegidos de gargalos de recursos, e consequentemente, crash do sistema.

Um detalhe importante sobre o ulimit é que ele se relaciona com a shell que você utiliza. Porém, mesmo executando uma nova shell diferente dentro da sua shell padrão, os limites se aplicam, pois a nova shell é um processo child daquela que impõe os limites, herdando tudo da mesma, com exceção do pid.

Portando para burlar o ulimit, o utilizador deve programar uma shell do zero e posteriormente setá-la como shell padrão. Isso porque o administrador pode aplicar os limites a todas as shells disponíveis no sistema. A única maneira de burlar é desenvolvendo uma shell que o administrador não setou tais limites. Desta forma, temos que as regras ulimit são seguras.

 
Os limites disponíveis

Abaixo a lista de possíveis limites:

  • Tamanho de arquivos core
  • Tamanho do segmento de stack
  • Tamanho do segmento de dados
  • Memória alocável
  • Número máximo de processos
  • Tamanho de arquivos
  • Tamanho máximo dos pipes
  • Número de filedescriptors (arquivos abertos)
  • Tempo de utilização de cpu
  • Tamanho máximo de memória virtual

Core – Tamanho máximo de um arquivo cujo contéudo de memória de um processo é escrito para um arquivo quando este crasha.

Stack – Espaço máximo que um utilizador pode ocupar na stack ou pilha de dados. A stack é utilizada para passar parâmetros nas chamadas de sub-rotinas, ou para guardar o estado da máquina em sistemas multi-programadas.

Seg. Dados – É o tamanho máximo que o segmento de dados de processos do usuário pode ocupar. Um processo tem um mapa de memória, e este divide-se em zonas, e uma delas é o segmento de dados.

Memória – Alocação máxima de memória que o usuário pode utilizar.

Processos – É o numero máximo de processos que o usuário pode ter, isto é, o número máximo de programas em execução que o utilizador pode ter. Ou seja, processos child da shell, porque no caso do X-Windows, este número não tem limite.

Tamanho de Arquivos – É o tamanho maximo que um arquivo pode ter, claro que isto também é limitado pelo espaço livre no sistema de arquivos e o tipo de sistema de arquivos definido, uma vez que, dependendo do sistema de arquivos utilizado, temos um limite por arquivo. Por exemplo: FAT32 possui o limite de aproximadamente 2GB/arquivo.
Tamanho Pipes – Tamanho máximo que um pipe pode ter. Pipe é um mecanismo de
comunicaçao entre processos da mesma família.

Número Filedescriptor – Número máximo de filedescriptors que podem estar abertos.
Filedescriptor é uma ligação entre um processo e um arquivo em disco. De uma forma mais simples, esta opção permite impor um número máximo de arquivos abertos.

Tempo de CPU – Tempo máximo que o usuário tem para utilizar o CPU. Desta forma, definimos o tempo a partir do qual ele não pode utilizar mais o processador.

Tamanho Memória Virtual – Tamanho máximo de memória virtual que o usuário pode utilizar.

Segurança

Em um passado não muito distante, um servidor configurado corretamente tinha seus riscos de ser invadido, mas esse risco era fisicamente dimencionado até os limites da sua rede local. Mas nos dias de hoje isso não é mais possível, por causa da chegada da Internet.

O grande crescimento de computadores interconectados, o crescimento de serviços virtuais e a quantidade de softwares com finalidades ilícitas, trazem como consequência a preocupação de se defender dessas pessoas mal intencionadas que posso utilizar esses softwares que tentam de várias formas invadir seu computador.

Existem vários aplicativos voltados a detectar a invasão do seu sistema, mas existem dois tipos de IDS, o que trabalha na user space (nível de usuário) ou kernel space (nível de kernel).

Podemos dizer que os IDS do tipo tripware que trabalha na camada de usuário podem ser mais vulneráveis, sendo assim burlados com mais facilidade, porque a maioria desses IDS tem arquivos de configuração, onde é informado , quais diretórios ou arquivos que precisam ter a proteção do IDS.

Caso a pessoa que efetuar a invasão não precisar fazer nenhuma alteração em arquivos, que estão relacionados no arquivo de configuração do IDS, somente fizer alterações em arquivos não configurados no IDS ou na camada de kernel ela possivelmente ela não será notada,tudo depende do contexto como o acesso arbitrário ocorreu.

Já com um sistema configurado com um IDS que esteja na camada de kernel, a dificuldade aumenta porque tudo o que a pessoa estiver tentando executar, gerará uma chamada no kernel(systemcall), assim como o IDS está na camada de kernel, todas as chamadas feitas geram mensagens de logs.

O registro das atividades dos usuários e serviços dos sistemas é, notoriamente, muito importante para os administradores e como foi citado o fato de todas as chamadas ao sistema que são negadas serem registradas, cria um cenário muito importante para auditorias futuras.

A importância de registro dos eventos do sistemas é tanta, que na norma NBR ISO/IEC 17799, o item 9.7.1 é todo dedicado ao “Registro (log) de eventos. Deixando claro que registro de eventos são também prioridade em uma política de segurança.

Em um sistema de log, oficialmente somente o root poderia alterar os arquivos de log, já com o Lids aplicado, nem o root teria o poder de alterar esses arquivos.

Lids é um path de segurança no nível de kernel, ou seja, é necessário a recompilação do kernel para a aplicação do path. Esse patch pode ser encontrado no site oficial do LIDS “www.lids.org” e o fonte do kernel em “www.kernel.org”
As ferramentas que acompanham o patch do Lids “lidsadm e lidsconf” são fáceis de utilizar e de configurar, elas estão no nível de usuário e servem para configurar as ACLs que serão determinadas pelo root, que, dependendo da configuração das ACLs do Lids, não será mais o dono do sistema, mas sim somente um usuário comum.

Como o Lids está no nivel de kernel, ele é acionado já no início do boot do sistema, portanto, já na inicialização o sistema se encontra protegido.

Com esse sistema de proteção no boot, ela nega permissão a muitos serviços padrões do sistema, como o dmesg, que gera um relatório de todo a inicialização do kernel. Isso é muito importante, por isso que se deve liberar o dmesg a gravar no diretório /var/log/.

# lidsconf -A BOOT -o /var/log/dmesg -j WRITE

 

Todos sabem que o arquivo /etc/shadow contém as senhas de todos os usuários do sistema e que as senhas estão criptografadas. Mesmo assim, existe um grande risco de alguém descobrí-las.

Por esse motivo, o LIDS trabalha da seguinte forma: ainda como usuário root é possivel determinar que nenhum binário vá conseguir o acesso a esse arquivo de senhas, colocando uma regra de DENY (proibido), por exemplo:

# lidsconf -A -o /etc/shadow -j DENY

 

Mas o mais importante é que para toda regra existem as exceções, podendo assim liberar qual binário poderá acessar o /etc/shadow como READONLY (somente leitura). Um exemplo claro, seria o binário /bin/login, que precisa ter permissão de leitura no arquivo para que possa efetuar o login normalmente.

# lidsconf -A -s /bin/login -o /etc/shadow -j READONLY

 

Mas caso se tente visualizar o conteúdo do arquivo com outros binários (por exemplo: vi, cat, more, etc..), o IDS acusará que esse arquivo não existe.
Da mesma que é possivel proibir o acesso as arquivos para todos os binários e liberar para alguns, também existe a possibilidade de ocultar processos, isso mesmo esconder os processos. Veja por exemplo como ocultar o processo do serviço ssh.

# ldisconf -A -s /usr/sbin/sshd -o CAP_HIDDEN -j GRANT

 

Quando tentar listar os processos da máquina, esse processo do serviço ssh não aparecerá, mas o serviço está ativo.

Diante desse poder de fogo sugiro como a melhor opção seria utilizar os dois sistemas de IDS, para que vc esteja protegido na camada de usuário e na camada de kernel. Assim dificultado em muito possiveis atividades arbritárias.

Mesmo hoje tendo recursos como LIDS e outros como o SELinux, GrSecurity, devemos pensar sempre de forma estratégica em tudo que for possivel e viável tanto na Kernel Space como na User Space, pois em algumas situações como uma estação de trabalho fica impraticavel o uso de um recurso com LIDS.

O Lids também é um mecanismo a mais para aumentar o nível de segurança de um sistema operacional buscando atender também as diretrizes inerentes ao nível C2 de segurança no que diz respeito o Sistema Operacional.

O nivel C2 recomendado pelo TCSEC ” Trusted Computer System Evaluation Criteria”, que é nível de segurança minimo requerido pelo governo Americano e utilizada em algumas instituições no Brasil.

Outro valor agregado nessa história é que somente conhecendo profudamente como o sistema funciona e as respectivas aplicações que estejam sendo executadas, conseguimos tirar proveito de um recurso como LIDS, pois do contrário, simplesmente nada vai funcionar corretamente, ou seja, além de melhoramos a segurança do sistema, nossa base de conhecimento se aprimora.

Storage corporativo

Empresas de médio porte, e até de pequeno porte, já tem se beneficiado da tec­nologia de sistemas de armazenamento de alta capacidade, conhecidos como sto­rages. Estes equipamentos já são parte padrão do ambiente de TI de empresas de grande porte, e são peça essencial para projetos de virtualização ou para as polí­ticas de continuidade de negócios.

Um storage é um equipamento que serve para concentrar toda necessidade de armazenamento de um grupo de servidores, provendo uma solução flexível, de alta velocidade e confiabilidade. Em vez de colocar HDs diretamente nos servidores, todos os HDs ficam no storage, e a capacidade combinada pode ser distribuída entre as máquinas. Isso reduz o desperdício de espaço e permite também que a ca­pacidade seja realocada de acordo com a necessidade, sem que seja preciso des­ligar um servidor para instalar mais HDs. O storage também possui sistemas de proteção que garantem que em caso de falha de um HD, seja possível fazer a troca sem perda de informação e sem necessidade de interrupção do serviço.

Dentro do datacenter, o storage é ligado aos servidores por meio de cabos di­retos, usando uma tecnologia apropriada. A opção mais comum é o Fibre Channel, que permite acesso de alta velocidade aos discos de forma muito parecida com uma conexão local utilizando o protocolo SCSI. O Fibre Channel opera em taxas tí­picas de 1 Gbps até 8 Gbps. Recentemente vários fabricantes começaram a in­vestir mais pesado em outras formas de interligação, para reduzir o custo. As princi­pais são o iSCSI (interface de disco SCSI sobre IP) e o FCoE (Fibre Channel over Ethernet). Em ambos os casos, o transporte passa a ser feito por uma rede Gigabit Ethernet padrão.

A interligação de servidores e storages dentro do datacenter é simples, e pode ser feita com cordões ópticos diretos. Porém, muitas empresas tem necessidade de interligar prédios distantes, dentro de uma cidade ou até mesmo entre cidades. Esta interligação permite que as empresas tenham um datacenter de reserva, ga­rantindo a continuidade de negócios em caso de desastres. Além de ser uma boa idéia, também é uma obrigação legal de empresas do setor financeiro (graças à Re­solução 3380 Banco Central), e de empresas listadas em Bolsa de Valores desde a lei Sarbanes-Oxley.
A ligação de storages exige um protocolo compatível. Storages menores e mais modernos (que utilizam tecnologia iSCSI ou FCoE) podem ser interligados por meio de uma rede Metro Ethernet padrão. A taxa de transmissão deve ser suficiente para as necessidades do cliente; a velocidade típica fica entre 100 Mbps e 1 Gbps, que permite a replicação dos dados em tempo real. O atendimento neste caso pode ser feito com um Connect Flex, que é um link dedicado de alta velocidade.

Para storages de maior capacidade (que utilizam o protocolo Fibre Channel) é ne­cessário dispor de um canal óptico totalmente transparente. Isto pode ser feito com uma fibra apagada, ou seja, uma fibra óptica que não passa por nenhum equipa­mento da operadora. O problema é que este tipo de ligação depende da disponibili­dade do serviço na região. A maioria das operadoras não oferece a fibra escura como parte do seu portfolio por questões estratégicas; é um produto caro, que uti­liza de forma exclusiva um recurso valioso que poderia ser “multiplicado” pela opera­dora para atender muito mais clientes. Mas existem algumas alternativas, como a oferta de serviços sobre tecnologia WDM.

O Storage Connect, que permite interligar storages entre prédios distantes dentro da sua área de atuação. Vários clientes corporativos já uti­lizam o Storage Connect, incluindo bancos, empresas do segmento de saúde e ór­gãos públicos. Através desta solução, é possivel interligar diretamente tanto a rede LAN como os storages, sem passar por nenhum equipamento ativo de rede, de forma totalmente transparente.

Solução Storage Connect com Enlace CWDM Simples

O Storage Connect oferece a mesma performance e flexibilidade da fibra apa­gada, mas permite o gerenciamento da solução (algo impossível com a fibra apa­gada normal). A solução utiliza a tecnologia de multiplexação de comprimentos de onda (WDM). O sistema permite que o cliente disponha de até 8 canais ópticos transparentes, que podem ser utilizados para interligação de storages, redes locais, ou qualquer outro sistema que possa ser ligado a uma fibra óptica. A solução também pode ser oferecida de forma redundante, utilizando para isso duas rotas distintas.

 

Solução Storage Connect com Enlace CWDM Redundante

A solução Storage Connect é customizada para cada cliente, de acordo com o número de canais e a velocidade desejada em cada canal. A solução é indicada para ligação em Fibre Channel, em taxas de 1 Gbps a 8 Gbps, ou de rede local (LAN) a 1 Gbps ou 10 Gbps.