Se o usuário quiser executar. Arquivos controlados. Tutorial

Transcrição

1 Tutorial Arquivos controlados O utilitário incron fornece uma maneira fácil de iniciar os comandos e scripts desencadeados por eventos do sistema de arquivos. por Paul C. Brown Se o usuário quiser executar uma determinada tarefa a cada vez que um evento específico ocorre, pode empregar várias técnicas para pool ou log assistido; no entanto, o Linux fornece uma solução mais generalista, sob a forma de uma ferramenta chamada incron. O incron usa o subsistema inotify [1] para escutar eventos que afetam um sistema de arquivos, como abrir, criar ou excluir um arquivo; acessar um diretório; ou alterar um atributo. O nome incron sugere o utilitário cron comum; no entanto, tarefas agendadas são acionadas por um momento no tempo (a cada sexta-feira, uma vez por dia às 3 da manhã, em agosto etc.), enquanto incron é desencadeado por eventos de arquivos ou diretórios. As engrenagens na cabeça do usuário provavelmente já estão girando, pensando em todas as possibilidades de uso do incron. Assim, neste artigo, descreveremos como configurar o incron e colocá-lo para trabalhar em alguns exemplos simples. Como obter o incron O conjunto de ferramentas incron geralmente não é pré-instalado por padrão na maioria das distribuições, mas como é uma implementação do subsistema inotify (quadro 1), é provável que esteja no repositório da distribuição, de modo que o usuário pode instalá- Quadro 1: A origem do icron O in no incron vem de inode, a estrutura de dados que contém os detalhes (localização no disco físico, tamanho, usuário proprietário etc.) de cada arquivo e diretório no sistema de arquivos. O inotify é o subsistema do kernel no qual o incron se baseia. Este subsistema monitora alterações de arquivo e diretório consultado por aplicativos, permitindo, por exemplo, que um ícone de nova pasta apareça em tempo real em uma janela do navegador gráfico de arquivos (por exemplo, o Nautilus ou o Dolphin), mesmo que o diretório subjacente tenha sido criado por outros meios (por exemplo, com o comando mkdir de um Shell). Ele também pode ser usado para informar a um aplicativo que um arquivo aberto foi alterado no disco por algum outro programa, permitindo assim que o usuário substitua ou renomeie a versão na qual está trabalhando. 54

2 Evento Eventos comuns IN_ACCESS IN_ATTRIB IN_CLOSE_WRITE IN_CLOSE_NOWRITE IN_CLOSE IN_CREATE IN_DELETE IN_DELETE_SELF IN_MODIFY IN_MOVE_SELF IN_MOVED_FROM IN_MOVED_TO IN_MOVE IN_OPEN Eventos especiais IN_ALL_EVENTS IN_DONT_FOLLOW IN_ONESHOT IN_ONLYDIR Evento curinga IN_NO_LOOP Significado O arquivo foi acessado (lido) Metadados foram alterados (permissões, data e hora, atributos estendidos etc) Arquivo aberto para escrita foi fechado Arquivo não aberto para escrita foi fechado Combina IN_CLOSE_WRITE com IN_CLOSE_NOWRITE Arquivo/diretório criado em diretório assistido Arquivo/diretório deletado em diretório assistido Arquivo/diretório assistido foi deletado Arquivo foi modificado Arquivo/diretório assistido foi movido Arquivo foi movido de diretório assistido Arquivo foi movido para diretório assistido Uma combinação de IN_MOVED_ FROM e IN_MOVED_TO Arquivo foi aberto Combina todos os eventos acima Não elimina a referência do pathname se for um link simbólico Monitora o pathname para um único evento Só assiste o pathname se for um diretório Desabilita o monitoramento de eventos até que o evento atual seja tratado completamente (até que seu processo child seja concluído - evita loops infinitos) lo via gerenciador de pacotes. No entanto, se por algum motivo não for possível instalar os pacotes necessários a partir do repositório, baixe a versão mais recente do site [2] e compile a partir do código-fonte. Note que o incron é uma tecnologia relativamente recente o framework de notificação inotify foi implementado pela primeira vez no kernel por isso, se o usuário estiver executando um kernel antigo, o incron não irá funcionar. O incron compreende vários pedaços, dos quais o principal componente é o serviço incrond. Este daemon se instala em /etc/ init.d. Dependendo do sistema, ele pode ser iniciado com um dos seguintes comandos: # /etc/init.d/incrond start # /etc/init.d/incron start ou, se o usuário estiver utilizando systemd: # systemctl status incron.service ou qualquer variação dessas. Primeiro projeto com incron Uma vez que o serviço esteja em execução, o usuário pode criar seu próprio Olá, mundo!. Neste primeiro projeto, criaremos um arquivo de log e adicionaremos uma linha a cada vez que um arquivo é adicionado a um diretório monitorado. Primeiro, crie o diretório que deseja monitorar: $ mkdir my_dir O sistema incron é semelhante ao cron por salvar um arquivo para cada usuário. Este arquivo, chamado incrontab, contém os eventos que o usuário deseja monitorar ligado às ações que Linux Magazine #111 Maio de

3 Figura 1 O Apache é reiniciado automaticamente a cada vez que o usuário modifica seu arquivo de configuração principal. deseja executar. Embora seja possível editar este arquivo à mão (analisaremos isso mais à frente), o caminho feito para fazer as coisas é usar a instrução incrontab com, neste caso, o argumento -e (para edição): incrontab e Este comando abre o arquivo para o usuário atual no editor padrão pré-configurado isto é, para onde quer que as variáveis de ambiente $EDITOR apontem (ou vi se não estiver apontando para nada). Tal como acontece com o cron, cada par de evento/ tarefa tem que estar em uma linha e inclui: 1 <a path> o caminho para o diretório ou o arquivo a ser monitorado. 2 <a mask> os eventos a serem monitorados (tabela 1). 3 <a command> a ação a ser executada. Pode ser um comando individual ou um script que executa do Shell. Neste exemplo, incrontab contém uma única linha: /home/<user>/my_dir IN_CREATE /home/<user>/bin/hello.sh O arquivo hello.sh contém o script abreviado, #!/bin/bash echo "File created." >> /home/<user>/file_log onde <user> é o nome de usuário desejado. Para que este comando funcione, devemos tornar o script hello.sh executável com o comando chmod a+x bin/. Depois de ter salvo e fechado arquivo incrontab do usuário, o programa irá mostrar a tabela de mensagens atualizada, indicando as mudanças registradas. Agora, se o usuário criar um arquivo em my_dir digitando, por exemplo, $ touch my_dir/file1.txt o arquivo file_log será exibido em seu diretório home contendo a linha File created. Observe a primeira limitação do incron: operações compostas, tais como a instrução echo que redireciona a saída para um arquivo no script hello.sh, devem ser empacotada no script Shell, ou o incron será interrompido. Como o incron não é um interpretador de comandos Shell, ele não entende redirecionamentos, pipes e globbings que compõem uma instrução composta. A única coisa que o incron pode usar na seção de linha de comando é o nome da instrução e seus parâmetros. Por exemplo, o comando: /home/paul/my_dir IN_CREATE echo "File created." >> /home/paul/ file_log não iria funcionar como o esperado, porque seria interpretado da seguinte forma: echo é a instrução a ser executada (correto). File created é um parâmetro para echo (também correto). é outro argumento para echo (incorreto). /home/paul/file_log é outro argumento para echo (também incorreto). Esse comportamento é o padrão para o incron, por isso não irá gerar qualquer erro em seus logs. (o usuário pode acompanhar os erros do incron ou a falta deles, verificando em /var/log/ cron). O incron simplesmente ignora o que não entende e segue adiante. Este exemplo ilustra também a segunda limitação do incron: na linha incrontab, o usuário tem que especificar o caminho absoluto completo para o executável que, neste caso, reside no próprio diretório bin/diretório do usuário. Embora esse diretório possa ser incluído na própria variável de ambiente $PATH do usuário, o daemon incron é executado como superusuário, por isso o executável teria que estar no $PATH do root para que o daemon pudesse encontrá-lo; caso contrário, o usuário teria que especificar o caminho absoluto. Assim, certifique-se de que o executável esteja em /bin, /usr/bin, /usr/local/bin, ou em algum lugar igualmente acessível, ou aponte para o programa com um caminho absoluto. Curingas O programa Olá Mundo do incron é tão bobo como qualquer outro, mas com algumas pequenas modificações o usuário pode torná- lo muito mais útil. Por exemplo, registrar o nome de um arquivo criado no arquivo de log é fácil. O incron fornece uma série de variáveis padrão (por alguma razão chamadas de curingas no jargão incron) que contêm este tipo de informação (tabela 2). Por enquanto, $#, que 56

4 Curinga contém o nome do arquivo afetado pelo evento, é de interesse. Abra o arquivo incrontab novamente (incrontab e) e altere a linha de monitoramento para: /home/paul/my_dir IN_CREATE /home/paul/bin/hello.sh $# Em seguida, modifique o script hello.sh para: #!/bin/bash echo "File $1 created." >> /home/paul/file_log Agora tente criar um novo arquivo em my_dir: $ touch my_dir/file2.txt Se observar em file_log, o u- suário verá que contém uma nova linha que diz File file2.txt created. Apache automático Uma utilização mais séria para incron seria monitorar os arquivos de configuração de um servidor e pedir um reboot se alguma coisa mudar, como um servidor web Apache httpd.conf modificado ou arquivo apache2.con. Comece por descobrir qual usuário tem privilégios para parar e reiniciar o Apache no sistema e edite o incrontab. Para este exercício, suponha que o usuário é root, torna-se superusuário, e o incrontab é um root aberto para edição: $ su # incrontab e Significado $$ Sinal de dólar $@ $# Caminho assistido do sistema de arquivos Nome de arquivo relacionado ao evento $% Flag de evento (textual) $& Flag de evento (numérico) Se o usuário receber um erro onde se lê user 'root is not allowed to use incron (o usuário 'root' não tem permissão para usar incron), edite o arquivo /etc/incron.allow e adicione o usuário root à lista de usuários permitidos. Em seguida, insira a seguinte linha no arquivo incrontab do root: /etc/apache2/apache2.conf IN_MODIFY /etc/init.d/apache2 restart Depois de modificar httpd.conf, ou apache2.conf (por exemplo, alterando o valor do parâmetro timeout) e salvar o arquivo, examine /var/log/apache2/error.log (figura 1). O usuário verá que o Apache foi reiniciado automaticamente quando apertou o botão Save (Salvar) (ou digitou :wq). No entanto, o usuário provavelmente também sabe que faz um bom tempo que o Apache possui apenas um arquivo de configuração. A configuração do Apache foi modularizada e às vezes se aproxima de dezenas de arquivos espalhados por vários diretórios aninhados. Para monitorar todo o lote, adicione o seguinte ao incrontab do root: /etc/apache2/conf.d/ IN_CREATE /etc/init.d/apache2 restart Este método não é muito sutil, mas, mais uma vez, ele vai funcionar. O usuário provavelmente já descobriu que esse código reinicia o servidor web a cada vez que um novo arquivo é adicionado ao diretório /etc/apache2/conf.d/. Ele não verifica se é um arquivo *.conf ou não, mas não importa muito se o diretório conf.d do Apache foi criado para esses tipos de arquivos. Além disso, o usuário desejará monitorar os arquivos dentro do diretório conf.d para ver se qualquer um dos arquivos se altera. Para fazer isso, é possível modificar o incrontab para: /etc/apache2/conf.d/ IN_CREATE,IN_CLOSE_WRITE /etc/init.d/apache2 restart Como o usuário pode notar, se deseja monitorar mais de um evento, terá que separar os triggers com vírgulas. Neste caso, está monitorando os eventos IN_CREATE e IN_CLOSE_WRITE, porque também deseja reiniciar o Apache quando um arquivo de configuração fechar após ter sido modificado. Observe que o arquivo incrontab do root possui agora duas linhas, uma para cada diretório. O usuário provavelmente está pensando que o uso de duas linhas para um diretório e uma para seus subdiretórios é ineficiente, e que seria mais elegante se houvesse uma maneira de monitorar o diretório superior e, em seguida, detalhálo. Mas, estaria enganado em sua percepção. O incron não suporta monitoramento recursivo de diretório, nem existem quaisquer planos para fazê-lo, e há uma boa razão para essa decisão: laços recursivos infinitos. Para o infinito e além Imagine que um usuário deseja monitorar os arquivos em um diretório e escreve uma entrada em um log cada vez que um arquivo é modificado. Ele salva o log por conveniência no mesmo Linux Magazine #111 Maio de

5 diretório que está monitorando. O incrontab poderia ficar assim: </path/to/directory/> IN_CLOSE_WRITE log_changes $# onde log_changes é o seguinte script Bash: #!/bin/bash echo "`date` File $1 modified" >> </path/to/directory/>my.log Começou a notar o problema? Acaba de ser criado um loop infinito. Quando terminar de escrever a entrada em my_log, o evento IN_CLO- SE_WRITE é acionado porque, como sabemos, my_log é um arquivo no diretório monitorado, que foi fechado depois de ter sido escrito. Uma nova entrada é escrita em my_log, e o evento IN_CLOSE_WRITE é acionado novamente, porque o my_log é um arquivo no diretório monitorado, que foi fechado depois de ter sido escrito. IN_CLO- SE_WRITE é acionado novamente e... já sabemos o final da história. Coisas ruins aconteceriam se o usuário deixasse algo assim executar sem controle. Para evitar esse tipo de situação, cada administrador de sistemas que se preze tem duas ferramentas disponíveis: (1) senso comum e (2) o evento curinga IN_NO_LOOP. Esse elemento bloqueia a instrução incrontab até que esteja completamente concluída, evitando que o outro Listagem 1: Decisões de evento incron case "$1" in "IN_ACCESS") warn_admin.sh 05 ;; "IN_CLOSE_WRITE") close_connection.sh 08 ;; *) echo "Event $1 not considered!" 11 ;; 12 evento dispare a mesma iteração e, assim, evitando loops. Embora o que se segue seja uma solução ruim, preguiçosa e de má qualidade (a melhor jogada seria guardar o arquivo de log em outro lugar), o usuário pode resolver o problema descrito acima com a seguinte linha incrontab: </path/to/directory/> IN_CLOSE_WRITE, IN_NO_LOOP log_changes $# Assim, o usuário pode ver que detalhar os subdiretórios de subdiretórios de subdiretórios (incluindo diretórios soft-link), se forem implementados em incron, aumentaria significativamente as chances de loops infinitos, então o monitoramento recursiva não é permitido no incron. Alarme silencioso No próximo exemplo, implementaremos um sistema de segurança contra intrusos que tentam acessar um determinado sistema que possui diretórios contendo documentos sensíveis. Não se Listagem 2: makeincrontab.sh trata da pasta chamada secret_ CIA_documents que todo mundo tem em seu diretório home. Se o usuário aprendeu alguma coisa sobre as preferências da NSA, LulzSec e Anonymous, é que os arquivos mais cobiçados pelos invasores são mensagens de . O contém nomes de usuário, senhas, contas bancárias, números de cartão de crédito, imagens pessoais, contratos de negócios e assim por diante. Uma pasta de muito utilizada é um verdadeiro tesouro para um bisbilhoteiro. No entanto, o monitoramento de uma pasta de real seria um pesadelo, com tantas escritas, reescritas, exclusões e alterações que fazem com que seja impossível filtrar os falsos positivos. Além disso, o usuário tem certeza que deseja que um invasor chegue tão longe a ponto de ser capaz de ler suas mensagens? Não, claro que não. O que o usuário faria, ao invés disso, é compilar um honeypot criando um diretório.mail saindo do diretório home, preenchendo-o com mensagens colhidas a partir 01 #!/bin/bash # The user's name is extracted from the 04 # monitored directory's path ($@) 05 # and is passed as argument $1 from 06 # incrontab # Delete the user's incrontab file 09 rm /var/spool/incron/`echo $1 cut d / f 3` # Examine each item in the user's directory 12 for i in $1/* 13 do #... Build an incrontab rule for 16 # each directory (ignore files). 17 if [ d $i ] 18 then 19 echo " $i IN_CREATE send_mail.sh address@admin.com `cat $1/. address`" '$# $@' >> /var/spool/incron/`echo $1 cut d / f 3` 20 fi 21 done 58

6 Listagem 3: Arquivo incrontab do usuário Joe 01 /home/joe/lm75 IN_CREATE send_mail.sh $# 02 /home/joe/lm76 IN_CREATE send_mail.sh $# 03 /home/joe/shell02 IN_CREATE send_mail.sh $# 04 /home/joe/uu04 IN_CREATE send_mail.sh $# de, por exemplo, a pasta de spam. Isso deve ser feito para uma leitura divertida. Se o seu cliente de já aponta para a pasta para armazenar mensagens, altere imediatamente! Trata-se de uma exposição demasiadamente perigosa. O incron irá monitorar o diretório honeypot como antes, mas com uma diferença: sua ação dependerá do que o intruso fizer. Se o intruso abrir um arquivo para leitura, o usuário ativará o alarme silencioso e avisará o administrador do sistema. No entanto, se o intruso começar a escrever em arquivos, o usuário desligará a máquina da rede com, por exemplo: ifconfig eth0 down O problema com esta solução é que, aparentemente, o usuário precisa de duas linhas para chamar dois scripts diferentes, dependendo do evento disparado. Algo como: /home/<user>/.mail IN_ACCESS warn_admin.sh /home/<user>/.mail IN_CLOSE_WRITE close_connection.sh Mas isso não vai funcionar porque o incron não permite que o usuário monitore a mesma coisa duas vezes. Se tentar executar essas linhas para acionar um dos eventos, o usuário receberá um erro em /var/log/cron que diz: Jul 24 21:17:54 host incrond[9454]: cannot create watch for user root: (16) Device or resource busy Para resolver esse problema, combine ambos os eventos em uma linha e use a variável incron $% predefinida: /home/paul/.mail IN_ACCESS, IN_CLOSE_WRITE access_control.sh $% O curinga $% é passado para o script como um argumento, informando qual evento foi acionado para que o usuário possa lidar com isso, como mostrado na listagem 1. Incrontab dinâmico Outra coisa que pode ser feita é usar o incron para informar aos usuários quando eles possuem novos documentos em um servidor aguardando para serem processados. Por exemplo, imagine que o usuário seja o editor-chefe da Linux Magazine e precisa comunicar aos outros editores quando os artigos estarão disponíveis para edição, correção, revisão, e assim por diante. Em vez de copiar os documentos para o servidor, disparar o cliente de ou fazê-lo manualmente em uma mensagem à parte interessada, o editor-chefe só deseja copiar o documento e concluí-lo. Ele poderia esperar que a equipe verificasse as pastas online regularmente, mas não pode se dar ao luxo de assumir que isso vá ocorrer. é por isso que o script existe. Ao invés do dump de todos os documentos à toa em um diretório, o usuário quer ser capaz de monitorar cada um dos diretórios home dos demais usuários no servidor e, em seguida, monitorar os subdiretórios que são criados para cada revista e liberá-los dentro desses diretórios. Isso leva a outro desafio: como mencionado anteriormente, o incron não implementa recursividade, então o usuário não pode simplesmente monitorar o nível superior e descer para outros níveis quando uma pasta para uma nova edição é criada. Se o usuário monitorar os diretórios de nível superior dos demais usuários, o incron não verá quando um arquivo é adicionado a um subdiretório, por isso ele terá que criar uma linha incrontab para cada novo subdiretório que criar em pasta pessoal de um usuário, e isso parece tão irritante quanto enviar um para cada editor a menos que seja criado um script para fazer isso pelo usuário. O truque é fazer com que o script escreva diretamente em arquivos incrontab dos usuários sem ter que usar o incrontab -e. Os arquivos inrontab residem em /var/spool/incron/, e cada usuário possui o seu próprio com seu nome. Assim, o usuário incrontab joe será /var/spool/incron/joe, o arquivo de usuário jane será / var/spool/incron/jane, e assim por diante. Para conseguir isso, usamos um superusuário incrontab global com uma linha por editor para escrever em cada arquivo. As regras no incrontab principal se parecerão com: /home/joe IN_CREATE /usr/local/bin/makeincrontab.sh $@ /home/jane IN_CREATE /usr/local/bin/makeincrontab.sh $@ /home/jed IN_CREATE /usr/local/bin/makeincrontab.sh $@... Sim, o usuário terá que criar uma regra por editor, mas, a menos que Linux Magazine #111 Maio de

7 esteja continuamente contratando e demitindo mebros da equipe editorial, não será necessário alterar esse arquivo com muita frequência. Cada linha monitora os diretórios home dos usuários e executa o script makeincrontab.sh (listagem 2), sempre que um subdiretório é criado em qualquer um dos diretórios monitorados. O script makeincrontab.sh toma como argumento o nome do u- suário a partir de seu diretório home monitorado (selecionado da variável $@ `` incluída em cada uma das regras ``incrontab do root) e remove o arquivo incrontab existente para esse usuário a partir do diretório /var/spool/incron/. Em seguida, ele faz um loop sobre todos os subdiretórios existentes no diretório home do usuário e cria um novo arquivo com regras para cada subdiretório, indicando que o usuário deve receber um se um novo arquivo for adicionado a qualquer um desses subdiretórios. O endereço de do usuário é extraído do arquivo. address que foi criado anteriormente e colocado no diretório home do u- suário. A beleza de remover um arquivo incrontab do usuário e, em seguida, criá-lo novamente cada vez que o script é executado é que as regras que se referem aos diretórios antigos que foram apagados ficam liberadas do arquivo incrontab. Digamos que, com o tempo, o usuário criou subdiretórios no diretório home de Joe para a Linux Magazine 75 (lm75), Linux Magazine 76 (lm76), Shell Especial 02 (shell02) e Ubuntu Usuer 04 (uu04). O arquivo incrontab gerado se parecerá com a listagem 3. O script send_mail.sh, aliás, terá que ser escrito pelo próprio u- suário. O nosso é na verdade um Python script (não um Bash), que envia uma mensagem com instruções sobre como baixar os arquivos via SSH, com linhas de comando adaptadas (graças novamente à variável $@) que os editores podem copiar e colar em um terminal. Conclusão O incron é divertido! Oferece um conjunto muito completo e poderoso de ferramentas para monitorar e reagir a mudanças no sistema de arquivos, economizando uma tonelada de trabalho e problemas, permitindo conectar eventos e tarefas. n Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em: cartas@linuxmagazine.com.br Este artigo no nosso site: # 10 JUNHO/2013 Os sistemas modernizam-se assim como suas vulnerabilidades. Saiba como tirar o máximo proveito da tecnologia com segurança ADQUIRA O SEU EXEMPLAR EM NOSSA LOJA VIRTUAL LNM.COM.BR/SHOPPING ADMIN SEGURANÇA VIRTUAL HYPER-V VIRTUALIZAÇÃO VIRTUALBOX FIREWALL OPENLAVA HONEYPOTME NEXENTA NETGEAR POWERSHELL OS SISTEMAS MODERNIZAM-SE ASSIM COMO SUAS VULNERABILIDADES. SAIBA COMO TIRAR O MÁXIMO PROVEITO DA TECNOLOGIA COM SEGURANÇA FIREWALL p. 26 Segurança avançada no firewall do Windows Vista/Server 2008 Redes & Segurança Windows Linux Unix Solaris /2013 ADMIN MAGAZINE # 10 CEZAR TAURION p.10 Cloud nas quatro ondas tecnológicas SEGURANÇA Como obter o máximo desempenho em ambientes virtualizados p.13 Utilize um simples navegador para controlar remotamente máquinas virtuais com VirtualBox p.16 Conheça as melhorias da versão 3.0 do Hyper-V p.20 OPENLAVA p. 50 Compartilhe sistemas de alto desempenho através deste poderoso gerenciador de recursos HONEYPOT p. 68 Identifi que ataques e vulnerabilidades em sistemas com o HoneypotMe MARCELO BRANQUINHO p.23 Antecipe-se aos problemas VEJA TAMBÉM NESTA EDIÇÃO: Nexenta VS. Netgear: saiba qual é a melhor plataforma de compartilhamento p.32 PowerShell em linha de comando: muito mais poderoso p.45 W W W. A D M I N - M A G A Z I N E. C O M. B R SEGURANÇA O hardware está mudando constantemente com novas CPUs, aceleradores e a integração de ambos. Como saber quais processadores são ideais para cada código? p. 57 exemplar de Assinante venda proibida