Capítulo 03 Reconhecendo o terreno. Especialização em Redes de Computadores Servidores Linux

Transcrição

1 3. Reconhecendo o terreno. Antes de efetuar qualquer alteração em um ambiente de produção é necessário reconhecer o terreno. Saber a qual propósito o sistema se destina, quais os principais serviços ativos (e muitas vezes os inativos), quais as configurações de rede e como estas influenciam o restante da rede, quais as ações possíveis diante de uma quebra do sistema e o que fazer para investigar a causa. Um administrador, quando da implantação de um novo servidor de rede, pode ser levado a tomar atitudes pouco tradicionais por vários motivos: questões envolvendo segurança, políticas da instituição, restrições orçamentárias, imediatismo por parte de seus superiores, incoerência das configurações realizadas por vários administradores diferentes, et cetera. Por isso, um reconhecimento de tudo que acontece num servidor de produção antes de realizar alterações pode ser muito útil. Conhecendo os prováveis erros e prontos fracos na configuração de um servidor, o administrador evitará cair nos mesmos erros ao realizar novas configurações. Neste capítulo, esse é o foco dos estudos o que resulta em poucas modificações no sistema. Isso porém é o subsídio para investigar problemas que acontecerão durante toda a disciplina. Como o sistema não possui praticamente nenhum serviço ativo, esse reconhecimento se concentra nas configurações mais triviais. Um cenário real pode levar o administrador a fazer muitas outras análises além destas. 3. Reconhecendo o terreno Serviços, processos e desempenho Níveis de execução (runlevels) do GNU/Linux Debian Adicionar ou remover serviços da inicialização Serviços de rede e processos em memória Desempenho Diagnóstico de rede Quem usou o sistema? Permissões do sistema Atualização do servidor com APT Exercícios Exercícios de pesquisa Conteúdos relativos Referências Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 1/33

2 3.1 Serviços, processos e desempenho. Não é possível a um administrador realizar intervenções um um servidor sem saber o que ele faz, especialmente, o que ele está fazendo neste momento. Por isso é importante compreender os conceitos envolvendo serviços, inicialização do sistema, processos de usuário e processos do núcleo, consumo de memória real e virtual, et cetera. O primeiro ponto a investigar está relacionado com os serviços e com a inicialização do sistema Níveis de execução (runlevels) do GNU/Linux Debian. O conceito de níveis de execução (runlevels) é imprescindível para compreender o que acontece em uma máquina rodando Linux. Esses níveis definem os serviços a iniciar em um sistema. A tabela a seguir detalha cada um desses níveis [1]: Runlevel Debian Significado 0 halt O sistema operacional inicia o procedimento para deligar o computador. 1/S single user mode O sistema inicia apenas os serviços prioritários. 2 standard O sistema inicia todos os serviços normalmente. 3 unused Configurável no Debian. 4 unused Configurável no Debian. 5 unused Configurável no Debian, às vezes associado à utilização da interface gráfica. 6 reboot O sistema operacional inicia o procedimento para reiniciar o computador. Tabela 1: Níveis de execução (runlevels) do Debian Adaptado de Martin Krafft. Uma máquina rodando GNU/Linux Debian em modo texto raramente iniciará em um nível diferente de 2, apesar de sempre passar pelo nível 1 antes de prosseguir com a inicialização. Para saber em qual nível de execução um sistema está basta usar o comando runlevel. Apesar do GRUB apresentar apenas os níveis 1 e 2 no menu de inicialização, é possível incluir níveis inutilizados para personalizar o sistema. Assim, o administrador pode configurar os níveis 3 e 4, por exemplo, para iniciar um conjunto específico de serviços que considera importante em certas ocasiões. Para tal o usuário deve digitar e no menu do GRUB e editar a linha da seguinte forma [2] e depois digitar Ctrl+X para iniciar o boot: linux /vmlinuz amd64 root=uuid=434fa961-32f4-425d-a89d-5ea0c5530c4f ro 3 Em outras palavras, substituir a palavra quiet pelo número do nível de execução que deseja. Para cada um dos níveis, existe um conjunto específico de scripts que iniciam os serviços presentes em /etc/rcx.d, onde X deve representa o nível de execução. Basta listar o conteúdo do diretório para saber quais os serviços que inicializam com o sistema operacional. Na realidade, o conteúdo destes diretórios não passa de um conjunto de links para scripts no diretório Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 2/33

3 /etc/init.d/, que é onde os scripts de inicialização dos serviços estão na realidade. As letras S ou K no início do nome indicam se o serviço irá iniciar ou parar ao entrar no nível de execução. É por isso que todos os links do nível 0 e do nível 6 iniciam com a letra K. Os dois algarismos na sequência servem para organizar a ordem de execução. Outro arquivo importante intimamente relacionado à inicialização do sistema é o /etc/rc.local [3]. Este arquivo permite que um administrador execute um ou vários comandos durante a inicialização do sistema. Para isso, basta que o administrador inclua a lista de comandos antes da última linha do arquivo (exit 0). A utilização de recursos mais avançados na utilização de scripts será foco de estudos em breve. Por exemplo, o administrador pode incluir nesse arquivo um comando a seguir para listar o nível atual de execução do sistema no fim da inicialização: echo `date` iniciado no nivel: `runlevel` >> /var/log/levels.log Adicionar ou remover serviços da inicialização. Um administrador pode querer adicionar ou remover scripts na inicialização do sistema por vários motivos: para personalizar um script de firewall, para concretizar políticas de segurança ou de backup durante a inicialização, para configurar alertas de que o sistema foi inicializado em determinado modo ou executando determinados serviços de rede, et cetera. Por isso, um administrador deve entender como o GNU/Linux Debian reconhece um script como sendo de inicialização. Os requisitos para que um script seja reconhecido como um script de inicialização de um serviço são [4]: 1º estar no diretório /etc/init.d/; 2º admitir os parâmetros start e stop pelo menos (existem outros parâmetros admissíveis, mas estes são obrigatórios); 3º ter permissão de execução; 4º possuir links nos diretórios /etc/rcx.d/ de acordo com o nível de execução em que deve iniciar. A estrutura de um script de inicialização típico é a seguinte: 1 inicia(){ 2 echo "Iniciando serviço..." 3 (...) 4 } 5 para(){ 6 echo Parando serviço..." 7 (...) 8 } 9 case $1 in 10 start ) inicia;; 11 stop ) para;; 12 restart ) para; inicia;; 13 *) echo Use os comandos start, stop ou restart 14 esac Este script possui três blocos bem evidentes: 1º (1 a 4) função que determina o comportamento de inicialização do serviço; 2º (5 a 8) função que determina o comportamento de parada do serviço; 3º (9 a 14) estrutura de seleção que identifica o parâmetro e executa o comportamento referente a iniciar, parar ou reiniciar (parar e iniciar em seguida) o serviço. Com o script plenamente funcional no caminho /etc/init.d/ o administrador deve usar os comandos chmod para alterar a permissão do arquivo para escrita e update-rc.d para criar os links correspondentes ao nível Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 3/3333

4 de execução. Neste caso um exemplo pode ser mais produtivo: Um administrador quer um script que registre em um log as seguintes informações: data e hora de inicialização e desligamento, utilização de memória e disco do diretório / do servidor. O arquivo que guardará essas informações será /var/log/info.log. Para esse cenário, o administrador deverá criar o arquivo /etc/init.d/info, editá-lo e salvá-lo com o seguinte conteúdo: 1 inicia(){ 2 echo "Servidor iniciado em `date`" >> /var/log/info.log 3 echo `free -m` >> /var/log/info.log 4 echo `df -h /` >> /var/log/info.log 5 echo " " >> /var/log/info.log 6 } 7 para(){ 8 echo "Servidor desligado em `date`" >> /var/log/info.log 9 echo `free -m` >> /var/log/info.log 10 echo `df -h /` >> /var/log/info.log 11 echo " " >> /var/log/info.log 12 } 13 case $1 in 14 start ) inicia;; 15 stop ) para;; 16 *) echo Use os comandos start ou stop 17 esac Depois disso, o administrador deve executar o comando chmod +x /etc/init.d/info para aplicar permissão de execução ao script e o comando update-rc.d -f info defaults para registrar o serviço como obrigatório para todos os runlevels usando a configuração padrão do sistema. Com isso, ao iniciar o sistema, o serviço anexará no final do arquivo /var/log/info.log quatro linhas com a data e hora, informações de memória, informações de uso da partição raiz e um separador. O mesmo acontecerá sempre que o servidor for desligado mudando-se apenas o texto inicial da primeira linha. Se for necessário remover este serviço o comando é similar ao que adiciona o serviço: update-rc.info -f info defaults onde o último parâmetro muda de defaults para remove. Para maiores informações sobre o comando update-rc.d consulte o livro Servidores Linux [5] Serviços de rede e processos em memória. Tudo isso é muito útil para identificar o que inicia junto com o servidor, mas e quanto aos serviços que estão rodando em determinado momento? Encontrar serviços em execução em dados instantes pode ser útil para identificar uma utilização incorreta do servidor quando um usuário abre uma aplicação com conhecidas falhas de segurança, ou quando um vírus ou um cracker abre uma porta para um ataque mais elaborado. Nestas situações, um dos comandos mais úteis é o netstat [6]. É possível ver quais conexões estão estabelecidas e quais estão abertas para atender solicitações. Neste caso os parâmetros são -nta para serviços baseados no TCP, -nua para serviços baseados no UDP ou -ntua para ambos. Uma saída típica para o comando netstat -nta é a Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 4/33

5 seguinte: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreing Address State tcp : :* LISTEN tcp : :* LISTEN tcp : :1035 ESTABLISHED Por fim, o netstat tem a maravilhosa função de apresentar qual programa é responsável por cada uma das portas abertas. Analisando o exemplo anterior, que usa as opções -nta, é fácil perceber que a porta 80, normalmente associada ao servidor WEB, está aberta, mas não dá para saber qual o processo que está escutando nessa porta. Poderia ser um vírus ou trojan que abriu a porta na tentativa de facilitar um ataque. A opção -ntulp soluciona o problema. Ela permite ao administrador saber exatamente quem está usando cada uma das portas e investigar se alguma delas está indevidamente aberta e saber qual a aplicação está associada a cada uma. A saída a seguir é típica deste tipo de situação: Proto Recv-Q Send-Q Endereço Local Endereço Remoto Estado PID/Program name tcp : :* LISTEN 1487/portmap tcp : :* LISTEN 2008/apache2 tcp : :* LISTEN 1959/exim4 udp : :* LISTEN 1487/portmap Por fim, o netstat permite compreender as rotas ativas em um servidor, o que será muito útil em servidores que interconectam vários segmentos da rede ou até mesmo várias redes diferentes. Essa abordagem será foco de estudos em breve usando o comando route. O netstat seria igualmente útil. Existem também muitas utilizações bem práticas do netstat que vão além do conteúdo deste capítulo. A leitura das referências [6] [7] são interessantes nestes casos. Após isso, o administrador vai querer uma lista dos processos em memória para identificar os que estão abrindo portas. Dois comandos importantes para essa tarefa: o ps e o pstree [8]. O primeiro deles apenas lista os processos em memória. O comando sem parâmetros adicionais mostra os processos abertos pelo usuário que utiliza o sistema no instante de sua execução. Porém, os administradores constumam utilizar o parâmetro -aux. A opção -a indica que processos vinculados a todos os terminais devem estar na lista, -u informa o nome do usuário que iniciou cada processo e -x indica que processos não vinculados a terminais também devem estar na lista. A saída típica do comando ps com esses parâmetros seria: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root ? Ss 05:58 0:01 init [2] root ? S 05:58 0:00 [kthreadd] root ? S 05:58 0:00 [migration/0] root ? S 05:58 0:00 [ksoftirqd/0] (...) daemon ? Ss 05:58 0:00 /sbin/portmap root tty1 Ss 05:58 0:00 /bin/login root tty2 Ss+ 05:58 0:00 /sbin/getty tty2 (...) root tty1 S 05:58 0:00 -bash root tty1 R+ 06:37 0:00 ps -aux A lista acima, apenas uma pequena amostra do que seria visto em uma saída completa, é suficiente apenas para Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 5/33

6 elucidar o significado de cada uma das colunas: Coluna USER PID Significado Nome do proprietário do processo. Número de identificação do processo. %CPU Utilização de CPU (%). %MEM Utilização de memória (%). VSZ RSS TT STAT START TIME CPU COMMAND Tamanho da memória virtual utilizada pelo processo. Tamanho da memória real utilizada pelo processo. Terminal associado ao processo. Status do processo. Momento em que o processo foi iniciado. Tempo de utilização de CPU. Comando utilizado para iniciar o processo. Tabela 2: Campos da saída do comando ps -aux Adaptado de Manpages. Alguns processos estão anexados ao núcleo e por isso não estão associados a terminais e não apresentam algumas das informações estatísticas. Os valores em STAT seguem uma pequena tabela, acessível através do manual do comando, que significam: em execução (R), adormecido (S), adormecido ininterruptamente (D), parado (T), morto (X) e zombie (Z). Essas indicações podem ser seguidas de outras: alta prioridade (<), baixa prioridade (N), páginas bloqueadas na memória real (L), líder de seção (s), multi-thread (l) e em primeiro plano (+). Já o comando pstree [8] mostra a lista de processos evidenciando a hierarquia entre eles. A hierarquia entre processos é muito forte nos sistemas baseados em Linux (muito mais que nos sistemas baseados em Windows). Por isso, em muitos casos, o administrador precisa compreender a hierarquia de processos para compreender o que acontece em um servidor. A figura a seguir ilustra a saída do comando pstree: Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 6/33

7 Ilustração 1: Saída do comando psrtee. A primeira observação, indispensável para a compreensão de processos nos sistemas derivados do Linux, é o fato de que todos os processos derivam do init, que será sempre a raiz da hierarquia. Seguindo a hierarquia na figura, em um de seus ramos estão login, bash e pstree. Isso significa dizer que no momento em que o comando pstree gerou sua saída, o usuário estava logado usando o bash como shell. Exitem ainda cinco terminais não logados como indica a linha superior. O asterisco indica multiplicidade de processos, exatamente como no caso do apache que possui 56 processos em memória. O apache é um forte exemplo de como uma aplicação pode usar o esquema hierárquico de processos do Lunix. Para evitar que o pstree use a multiplicidade, basta usar a opção -a. A opção -p também pode ser útil, já que mostra todos os PIDs dos processos na árvore. Os comando ps e pstree vão exibir a lista dos processos em memória, sob diferentes perspectivas, aliada a uma série de informações úteis ao administrador. Mas, em muitos casos, especialmente em se tratando de administradores inexperientes, muitos desses processos podem ser desconhecidos. Por isso, um outro comando interessante para compreender melhor o que cada processo faz é o comando whatis [8]. Ele dá uma descrição resumida do comando como no exemplo abaixo: whatis cron cron (8) - daemon to execute scheduled commands (Vixie Cron) Apesar de ser uma descrição sumária, usando o whatis dá para saber que este é um serviço do sistema que executa comandos agendados. O cron será alvo de estudos futuros, já que é especialmente útil em servidores. Uma outra forma de obter informações sobre um comando ou serviço é a utilização de seu manual. No Debian, alguns manuais já foram traduzidos, mas a maioria ainda está em inglês. O comando para acessar o manual do cron e parte da saída estão no exemplo abaixo: man cron CRON(8) CRON(8) NAME cron - daemon to execute scheduled commands (Vixie Cron) SYNOPSIS cron [-f] [-l] [-L loglevel] DESCRIPTION Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 7/33

8 cron is started automatically from /etc/init.d on entering multi-user runlevels. OPTIONS -f Stay in foreground mode, don t daemonize. -l Enable LSB compliant names for /etc/cron.d files Sob vários aspectos, os manuais não são uma leitura muito didática e raramente incluem exemplos, mas apresentam de forma sucinta todos os parâmetros associados a um comando ou arquivo de configuração. Portanto, o procedimento geral é este: listar processos em memória em busca de processos problemáticos ou prejudiciais; identificar o que eles fazem e, em muitos casos, consultar os arquivos de configuração para verificar se fazem o que deveriam; e retirá-los da memória em casos que se percebe algum problema. Para retirar um processo da memória os comandos são o kill e o killall [8]. Em ambos os casos o parâmetro para estes comandos é o processo que deve deixar a memória, mas eles diferem em como este parâmetro deve ser passado. No caso do kill o parâmetro deve ser o PID do processo presente na saída do ps. No caso de matar o cron, por exemplo, o comando seria: kill O parâmetro -9 indica que deve ser utilizada a maneira mais violenta para encerrar o processo. Se o parâmetro -9 não estivesse presente, seria enviado o sinal de finalização que indica ao processo que ele deve concluir sua execução para ser encerrado. Administradores diante de um serviço indisponível ou de uma suposta ameaça tendem a ser muito pouco pacientes e sempre usam a opção -9, entretanto. Se no lugar do comando kill fosse usado o comando killall para o mesmo efeito o exemplo ficaria: killall cron Como o cron é um serviço e como servidores de rede normalmente rodam muitos serviços, há uma outra forma de lidar com este tipo de situação usando os scripts em /etc/init.d Desempenho. Os comandos ps e pstree dão várias informações sobre os processos, mas não são tão úteis para verificar o estado geral da máquina. Não tão úteis quanto o top [9]. Seu principal diferencial em relação ao ps é o fato de ficar em memória atualizando valores constantemente. Com o auxílio de uma metáfora, de certa forma, usar o ps é como exibir uma foto dos processos em memória enquanto o top exibe uma transmissão ao vivo. Outra diferença marcante do top é o sumário que apresenta nas cinco primeiras linhas detalhando a utilização do processador, da memória real, da memória virtual e o número de processos em cada estado. Normalmente, não é possível ver todos os processos amo mesmo tempo e por isso, a saída do top pode não parecer completa. Mesmo assim ele leva em consideração todos os processos na memória para calcular todos os valores. A saída do top é a seguinte: top - 23:08:41 up 2:14, 3 users, load average: 0.17, 0.08, 0.02 Tasks: 98 total, 1 running, 96 sleeping, 1 stopped, 0 zombie Cpu(s): 1.3%us, 9.3%sy, 0.0%ni, 87.7%id, 1.7%wa, 0.0%hi, 0.0%si, 0.0%st Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 8/33

9 Mem: k total, k used, 52528k free, 47728k buffers Swap: k total, 0k used, k free, k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2513 root m 6904 S :21.92 Xorg 3329 root m 9700 S :26.02 gnome-terminal 2436 root S :12.42 hald-addon-stor 2873 cicerow S :08.98 gnome-screensav 3555 root R :00.14 top 2869 cicerow m 12m S :44.01 gnome-panel 2989 cicerow S :51.39 multiload-apple 1 root S :02.26 init 2 root S :00.02 kthreadd 3 root RT S :00.00 migration/0 4 root S :03.42 ksoftirqd/0 5 root RT S :00.00 watchdog/0 6 root S :03.80 events/0 7 root S :00.02 khelper 39 root S :00.18 kblockd/0 41 root S :00.00 kacpid 42 root S :00.00 kacpi_notify 88 root S :00.02 kseriod 126 root S :00.00 pdflush 127 root S :00.58 pdflush 128 root S :00.00 kswapd0 129 root S :00.00 aio/0 547 root S :00.00 ata/0 548 root S :00.00 ata_aux 584 root S :00.00 ksuspend_usbd 585 root S :00.06 khubd Diferente do ps, o top fica exibindo a lista todo o tempo. Sob vários aspectos o top se parece com o gerenciador de tarefas do Windows, em especial, com a aba processos. Todas as opções do top estão disponíveis ao pressionar a tecla interrogação (?). Abaixo uma descrição sumária dos campos em cada uma das linhas do cabeçalho: Linha Campos, na ordem em que aparecem 1ª linha Hora do sistema, tempo ligado, quantidade de usuários logados, carga de utilização. 2ª linha Número de processos e estados: rodando, adormecidos, parados e mortos. 3ª linha Consumo de processamento: pelo usuário, pelo sistema, nice, disponível, para aguardar entrada/saída, para tratar IRQs, para tratar interrupções de software (traps), por máquinas virtuais. 4ª linha Consumo de memória: total, usada, livre e buffers. 5ª linha Consumo de memória virtual: total, usada, livre e caches. Tabela 3: Lista de campos do cabeçalho do top - Adaptado de Manpages. A maior parte dos cabeçalhos de coluna apresentados na saída do top são coincidentes com as colunas da saída do ps. Destaque apenas para NI (ou NICE) que lista processos dispostos a ceder seu tempo de processador (parecido com o que acontece quando se manipulam as prioridades de processos); RES, VIRT e SHR respectivamente uso de memória Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 9/33

10 real, virtual e compartilhada com outros processos; TIME+ tempo de uso de processador de cada processo. Entre as opções de linha de comando do top, as mais interessantes são: mudar o intervalo de atualizações que por padrão é de três segundos (s); retirar as linhas de cabeçalho para carga do sistema (l), processos e tempos de processador (t) e uso de memória (m) o que permite ver mais processos ao mesmo tempo; adicionar ou remover colunas na tabela de processos (f) ou mudar a ordem (o); matar um processo (k); modificar o nice de um processo (r de renice) Diagnóstico de rede. Não é possível realizar nenhum diagnóstico de rede sem configurar a rede. Portanto, o início desta seção mostra uma configuração básica da rede, mesmo não sendo este o objetivo maior. A configuração de rede fica no arquivo /etc/network/interfaces. O exemplo abaixo mostra um pequeno exemplo. 1 #The loopback network interface 2 auto lo 3 iface lo inet loopback 4 #The primary network interface 5 auto eth0 6 iface eth0 inet dhcp 7 hostname SRV01 8 #Configuração da interface secundaria 9 auto eth1 10 iface eth1 inet static 11 address netmask broadcast As linhas de 1 a 3 configuram a interface de loopback. É uma exigência dos Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 10/33

11 dispositivos Ipv4. Portanto, é uma regra que todo dispositivo deve obedecer. As linhas de 4 a 7 configuram uma interface por DHCP. A opção auto faz com que o script de inicialização execute esta configuração. A linha 6 é a que realmente configura a interface e a linha 7 informa uma opção adicional dispensável. As linhas de 8 a 13 configuram uma interface com endereço estático. A linha 10, a exemplo da linha 6, é a responsável por isso. Contudo, para configurar uma interface estaticamente, é necessário fornecer maiores informações. Neste caso, as informações das linhas 11 e 12. A linha 13 é opcional. Após configurar as opções, o administrador de usar o script (/etc/network/interfaces) para reiniciar o serviço de configuração de rede. O diagnóstico de rede começa reconhecendo as configurações atuais. Se nenhuma dúvida, um dos comandos mais úteis para iniciar a coleta dessas informações é o ifconfig [10]. Esse comando lida diretamente com a rede e permite configurar vários parâmetros dos adaptadores de rede, inclusive ativá-los e desativá-los. O comando ifconfig sem parâmetros adicionais lista os adaptadores de rede atualmente ativos. Já o comando ifconfig -a lista todos os adaptadores, mesmo os que estiverem não ativos. ifconfig ifconfig -a Muitas vezes não é necessário ver a configuração dos adaptadores, mas sim informações estatísticas. Neste caso o comando ifconfig -a -s lista informações estatísticas como no comando netstat -i. ifconfig -a -s Qualquer comando, incluindo o ifconfig, pode gerar saídas volumosas, em Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 11/33

12 especial nos servidores que possuem muitas placas de rede. Saídas que ocupam muito espaço na tela e são de difícil visualização. Usar o canalizador ou pipe ( ) seguido do comando less soluciona este problema. O comando less trata a saída do primeiro comando permitindo navegar pelo texto com as teclas de navegação. Como o comando em execução é o comando less exibindo a resposta de outro comando (no caso o ifconfig), para sair basta digitar a tecla q. Essa dica vale para qualquer comando. ifconfig -a less O comando ifconfig faz muito mais que apenas apresentar informações da rede. Como ele é possível configurar, ativar e desativar uma placa de rede, mudar seu endereço físico, colocar a placa em modo promíscuo, habilitar ou desabilitar funções como a resolução ARP, entre outras coisas. Mas para o diagnóstico, os parâmetros acima são os mais comuns e suficientes por enquanto. O estudo do ifconfig em outros cenários será tema de outras práticas durante a disciplina. Outro comando essencial para o diagnóstico da rede é o comando route [11]. Este comando serve para configurar rotas para redes externas, mas também lista as rotas atuais. A criação de novas rotas será foco de práticas futuras e o comando route sem parâmetros adicionais será suficiente por enquanto. Toda máquina que se conecta com a Internet tem pelo menos duas entradas na tabela de roteamento: uma para a rede local, que não é uma rota na realidade levando em consideração o conceito de rotas; e uma rota padrão para a Internet. Como já deve ser evidente para a maioria de vocês, essa tabela pode crescer muito se existirem rotas entre as equipes, por exemplo. A saída típica de um comando route é a Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 12/33

13 seguinte: Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface * U eth * U eth1 default UG eth0 A rota padrão (default) leva a todos os endereços para os quais não existam rotas específicas. O roteador (informação na segunda coluna) é o que normalmente se conhece como Next Hop (próximo salto). Enfim, é o próximo roteador no caminho que a informação deve percorrer até chegar ao destino da primeira coluna. Entre as flags da quarta coluna, o comando route pode exibir: rota disponível (U); o alvo é uma máquina específica (H); o caminho para por outros roteadores ou gateways (G); rota rejeitada (!); e informações relativas ao roteamento dinâmico (R D M). A métrica indica a distância em saltos até o alvo e interface a placa de rede pela qual os pacotes devem ser enviados para alcançar o destino. Todas as outras informações são bem específicas, dificilmente são diferentes do padrão ou se aplicam a roteamento dinâmico (que não está no escopo desta disciplina). Algumas delas serão alvo de estudos futuros, mas nem todas. Por fim, na atualidade, de pouco adianta ter acesso à Internet sem ter um servidor DNS funcionando apropriadamente. Três comandos são igualmente úteis para este Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 13/33 33

14 diagnóstico: o nslookup, mais antigo e conhecido, porém à um forte indício de que não terá mais suporte; o dig, mais parecido com o nslookup e seu modo interativo; e o host, mais parecido com os comandos tradicionais usando vários parâmetros na linha de comando. O host será foco de estudos, mas qualquer um deles é igualmente útil, sem restrições para o GNU/Linux Debian. A utilização mais comum deste comando é verificar a associação entre nomes de hosts e endereços de rede, como no exemplo abaixo onde o comando da primeira linha recebe a resposta nas próximas: 1 host uol.com.br 2 uol.com.br has address uol.com.br has address uol.com.br has IPv6 address 2804:49c:319:430::100 5 uol.com.br mais is handled by 10 mx.uol.com.br Receber uma resposta como essa já seria suficiente para garantir que o serviço de DNS funciona. Mas é interessante compreender todas as informações dessa resposta. As linhas de resposta 2 e 3 apresentam dois endereços IP para o nome uol.com.br. Essa é uma tática de distribuição de carga bem comum. A linha quatro diz repeito ao endereço IPv6 e a última ao servidor de deste domínio. O oposto também é muito comum. O exemplo abaixo mostra exatamente isso. Mas há um grave problema. O nome da resposta não é o mesmo da consulta anterior como se torna evidente na segunda linha. host Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 14/33

15 in-addr.arpa domain name pointer home.uol.com.br Isso se deve ao seguinte fato. O endereço o nome real relativo ao endereço não é uol.com.br mas sim home.uol.com.br. Consultando o outro endereço é fácil perceber que uol.com.br também não é o nome real deste servidor. Pesquisas inversas são muito úteis nesse caso. Outra utilização interessante do host é localizar o servidor DNS para um domínio específico. A utilização seria a seguinte: 1 host -t NS uol.com.br 2 uol.com.br name server borges.uol.com.br 3 uol.com.br name server charles.uol.com.br 4 uol.com.br name server eliot.uol.com.br Portanto, os servidores borges, charles e eliot.uol.com.br são os servidores DNS para o domínio uol.com.br. O interessante é perceber que a mesma consulta com a opção -t NS para os domínios bol.com.br, charges.com.br, folha.com.br e pagseguro.com.br também retornam alguns destes mesmos nomes que constam nas linhas 2, 3 e 4. Isso significa que um mesmo servidor DNS pode servir a vários clientes ou domínios. É exatamente assim quando alguém contrata um nome de domínio de algum revendedor que têm uma grande quantidade de clientes. Muitos outros diagnósticos são possíveis com o comando host, mas estes bastam para compreender a que se destina. Quando oportuno, outras consultas DNS com outras finalidade serão foco de estudos. Reconhecendo a configuração atual, um administrador vai querer compará-la aos Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 15/33

16 arquivos de configuração para verificar se conferem. Isso pode evidenciar uma tentativa de ataque ou uma alteração indevida por parte de algum outro usuário ou administrador. O principal arquivo de configuração de interfaces de rede é o /etc/netwok/interfaces. É um arquivo simples e sua sintaxe se parece com a do exemplo a seguir nos casos mais comuns Quem usou o sistema? Essa é outra questão importante para tentar compreender o que ocorre com o sistema. Para responder a esta questão nada melhor que o comando last [12]. A saída deste comando exibe uma tabela com o nome do usuário, o terminal e a origem no caso de ser remoto, data e hora e o intervalo em que o usuário usou o sistema. Sabendo quem usou o sistema dá para ter uma ideia de quando ocorreram as últimas modificações. Se não é um servidor desconhecido, dá até para prever o que aconteceu baseado nos terminais e nos horários de acesso. E mais importante, dá para investigar usos inapropriados dos servidor. Por exemplo, a utilização da conta de root para logar no servidor ao sábado usando o console pode evidenciar falha no acesso físico, ou a utilização de um acesso remoto no fim de semana em um horário inapropriado pode identificar uma tentativa bem sucedida de invasão. E um sistema com tais falhas deve passar por outros processos mais complexos de reconhecimento. Obviamente, apenas isso não é suficiente para comprovar uma falha de segurança, mas dá ao administrador possibilidades para isso. O administrador pode tentar identificar o que aconteceu no sábado para verificar o que o usuário estava buscando. Vale lembrar que para cada usuário, em seu diretório home, há um Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 16/33

17 arquivo com os últimos comandos (.bash_history). Pode tentar identificar novos serviços ou aplicações em execução que possam facilitar outro acesso de um invasor no futuro. Pode verificar se o arquivo /etc/passwd continua intacto na tentativa de identificar usuários que não deveriam fazer parte da lista. Existem ainda os comandos lastb e lastlog [13] que exibem respectivamente os usuários com logon ativo e a lista de usuários e seu último logon. Os comandos last e lastb usam informações do arquivo /var/log/wtmp. Já o comando lastlog usa as informações do arquivo /var/log/lastlog como referência. Obviamente, crackers cuidadosos e experientes vão tentar acobertar seus acessos modificando esses arquivos, mas isso normalmente deixa algum vestígio Permissões do sistema. Continuando neste tema, o reconhecimento completo de um ambiente requer compreensão das permissões do sistema. A princípio, o estudo das permissões estará concentrado nos sistemas de arquivos [13]. Muitos administradores podem se perguntar: por qual motivo usar partições diferentes para os vários diretórios do Linux? Algumas razões como limitar o tamanho de um diretório ou colocá-lo em uma área mais rápida do disco foram alvo de estudo nos capítulos anteriores. Ainda assim, um administrador pode achar que elas não são fortes o suficiente quando imagina que seu diretório /var já está cheio enquanto o seu diretório /home tem espaço de sobra. Portanto, segue a principal dessas vantagens: segurança. A montagem de sistemas de arquivos pode ter vários opcionais de segurança Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 17/33

18 interessantes. Mas só é possível aplicá-las ao /home sem interferir no /var se estes diretórios estiverem em partições diferentes. Um exemplo pode facilitar o entendimento. Imagine que um usuário de algum serviço da rede, serviço este que exige um diretório /home para cada usuário, colocou uma senha fraca por algum motivo bem pessoal. Obviamente, o administrador não sabe (ainda) quais usuários usam senhas fortes ou fracas. E um cracker certamente terá êxito se tentar quebrar a senha desse usuário. Partindo do pressuposto que tudo isso é afirmativo, cedo ou tarde, um invasor vai ter acesso a um diretório dentro do /home no servidor. O próximo passo do invasor será subir um rootkit ou trojan para um ataque mais robusto e destrutivo. Mas o administrador cuidadoso montou a partição /home sem permissão de execução. Então esse rootkit nunca irá rodar enquanto o atacante não editar o arquivo /etc/fstab ou usar o comando mount diretamente no prompt de algum SHELL. Basicamente, o atacante voltou à estaca zero. Mas o administrador não pode fazer isso se todos os diretórios estiverem em uma única partição. Se ele impede a execução nessa partição nenhum usuário vai executar nada a partir de local algum. Por isso, um particionamento mais complexo, mesmo correndo o risco de uma partição lotar antes mesmo do espaço em disco se esgotar, é sempre uma boa ideia do ponto de vista da segurança. Duas opções de montagem são mais interessantes do ponto de vista de segurança: nosuid e noexec. Ambas dizem repeito a como acontece a execução de aplicações nas partições. A primeira das opções, nosuid, impede que uma aplicação rode em modo de superusuário de acordo com a permissão de SUID BIT, tática top-of-mind dos invasores de plantão. Assim um invasor que consiga Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 18/33

19 acessar a partição /home e copiar um rootkit para lá, ou mesmo editar um script na tentativa que ele rode com as configurações equivocadas de algum serviço, vai ver a iniciativa falhar quando perceber que não vai conseguir rodar a aplicação em modo superusuário, mesmo mudando corretamente as permissões dos arquivos. A outra opção de montagem, noexec, vai impedir que o invasor ou qualquer usuário rode qualquer coisa, mesmo que a permissão do arquivo afirme o oposto. Isso é muito útil em sistemas em que os usuários usam sua pasta home como um repositório apenas. A tabela abaixo é uma sugestão de quais opções de montagem, do ponto de vista da segurança, são interessantes. Obviamente, exceções podem existir. O administrador deve levar tudo isso em consideração antes de tomar isso como uma regra ou prescrição: Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 19/33

20 Diretó rio nosuid noexe c /boot x - / - - /home x x /usr x - /tmp x? /var x? Descrição Os procedimentos do boot são de responsabilidade do init (root) que precisam de permissão de execução, mas independem do SUID BIT. Precisa de ambas as permissões pois contém os diretórios /bin, /sbin, /mnt, /media, /root, et cetera. Na maioria dos casos não precisa de nenhuma das permissões quando se trata de um servidor. Como mantém os binários da maioria dos aplicativos precisa da permissão de execução. Em alguns casos específicos pode precisar da permissão SUID BIT, mas são raros. A princípio nenhuma das duas permissões, mas há um caso bem específico que pode levar a pensar no caso da opção no exec. O /tmp é um dos preferidos do invasor. A princípio nenhuma das duas permissões, mas há um caso bem específico que pode levar a pensar no caso da opção no exec. O /var é crítico já que alguns uploads podem cair bem aí. Tabela 4: Diretórios e sugestão de opções de montagem envolvendo segurança. O caso do /var e do /tmp dizem respeito a instalação de aplicações. Durante o processo de instalação o APT usa essas partições com permissão de execução. Se a montagem dessas duas partições usa a opção noexec o APT terá problemas. Muitas aplicações que não usam o APT como o comando dpkg ou scripts que compilam a aplicação durante a instalação também usam o /tmp. Por isso a recomendação é instalar tudo e adicionar a opção noexec depois de tudo pronto. Essa tabela poderia facilmente crescer quando o administrador leva em consideração os serviços que irão rodar no servidor. Só a título de exemplo: um servidor FTP com uma partição específica para o /srv, um servidor WEB com uma partição específica para /var/www, um servidor SNORT com uma Professor: Cícero Woshington Saraiva Leite (cicerow.ordb@gmail.com) 20/33