Inicializa??o do Slackware

Inicializa??o do Slackware
Inicializa??o do Slackware

Piter Punk

Existe muita documenta??o a respeito do m?todo de inicializa??o System V, utilizada por v?rios *nix comerciais e pelos RedHat-like (Mandrake, Conectiva, etc…). J? o Slackware, utiliza como m?todo de inicializa??o o estilo BSD, muito mais compat?vel com a filosofia de manter tudo simples dominante no Slack…
1 Introdu??o
Quem j? utilizou v?rios Linux j? percebeu, o boot do Slackware ? mais r?pido. E o grande respons?vel por isto ? o m?todo de inicializa??o dele. Ao contr?rio dos sistemas baseados em SystemV, que carregam dezenas de scripts para cada servi?o a ser utilizado, o Slackware carrega apenas uns poucos scripts, mais r?pidos e eficientes…

Todos estes scripts est?o hospedados sob o /etc/rc.d, cada um deles respons?vel por uma das etapas da inicializa??o:

rc.S – Este ? o script de Start do Slackware;
rc.K – Carregado quando entramos no runlevel 1, para manuten??o do sistema;
rc.M – Modo multiusu?rio, utilizado nos demais runlevels;
rc.4 – Aciona o login gr?fico (runlevel 4);
rc.0 e rc.6 – Respectivamente desliga e reboota o computador.
Al?m destes, existem v?rios outros que s?o chamados a partir destes primeiros, alguns deles setam apenas um servi?o, outros configuram o hardware da m?quina, s?o eles:

rc.modules – Carrega os m?dulos do kernel;
rc.pcmcia – Suporte a dispositivos pcmcia (muito utilizados em notebooks);
rc.serial – Configura as portas seriais da m?quina;
rc.cdrom – Verifica se existe um CD no drive e monta-o automaticamente;
rc.gpm – Configura e carrega o gpm (suporte a mouse);
rc.font – Carrega a fonte de console a ser utilizada;
rc.keymap – Ativa o mapa de teclado apropriado e;
rc.ibcs2 – Modo de compatibilidade bin?ria com outro *nix para 386.
Tamb?m temos scripts especiais para a configura??o das interfaces e servi?os da rede:

rc.netdevice – Carrega o m?dulo para a placa de rede correta.
rc.inet1 – Configura IP, Gateway, etc…
rc.inet2 – Carrega v?rios servi?os, como o rpc.portmap, ypbind, nfsd, lpd entre outros;
rc.samba – Ativa o protocolo SMB;
rc.atalk – Uso do protocolo AppleTalk (algu?m usa isso?!?!??!?) e;
rc.news – Carrega os news services;
rc.httpd – Ativa o Apache.
Por ?ltimo, carregamos o rc.local, que cont?m as configura??es pr?prias da m?quina local. Algumas pessoas colocam aqui suas regras de firewall (outras preferem colocar em um rc.firewall), outras usam o rc.local para carregar programas como monitores de rede, etc…

Nas pr?ximas se??es, iremos descrever em detalhes o que fazem cada um destes scripts. Nos acompanhe -;)

2 Os b?sicos…
Bom, considerei como b?sicos os scripts respons?veis por cada runlevel (0,1,2,3,4,5,6), lembrando que os n?veis 2 e 5 na realidade carregam o runlevel 3.

2.1 rc.S
O rc.S faz as primeiras configura??es da m?quina, como ativar a swap e checar os sistemas de arquivos. ? um arquivo cheio de coment?rios, sendo facilmente modific?vel (embora n?o seja t?o aconselh?vel). Para deixar sua box r?pida desde o boot, esse ? o melhor lugar para colocar as suas configura??es do hdparm -;)

Logo que o rc.S ? executado, ele ativa a swap e faz um update das bases de dados. Estas s?o utilizadas pelo comando whereis, which, etc… logo em seguida ? verificada as parti??es de seu disco. ? aqui que a parti??o root ? montada.

Em seguida s?o montadas as outras parti??es, exceto as NFS, j? que os m?dulos de rede e os servi?os apropriados ainda n?o foram carregados.

Na seq??ncia, s?o apagados alguns arquivos tempor?rios e em seguida ? setado o rel?gio do sistema. Caso sua parti??o / seja do tipo UMSDOS (como no ZipSlack), ? neste momento que ela ser? sincronizada e organizada para ser utilizada corretamente.

Se voc? j? tentou modificar o issue (apresenta??o da sua m?quina) percebeu que toda vez que o computador ? rebootado ele volta ? forma original. Isso acontece porque o rc.S apaga e recria o issue (e o motd) toda vez que o computador ? bootado. Se voc? pretende alterar o issue, apague (ou comente com um #) as linhas relativas a ele.

Em seguida, s?o configurados os dispositivos PnP (atrav?s do isapnp), ? carregado o rc.modules e o rc.pcmcia, o que garante que todo o seu hardware estar? reconhecido e funcionando para os pr?ximos scripts.

As ?ltimos comandos executados pelo rc.S, chamam o rc.serial e carregam a semente rand?mica do sistema. A partir daqui o sistema ir? carregar o rc.K, no caso de estar sendo iniciado o runlevel 1 ou o rc.M no caso de ser 2, 3, 4 ou 5. Se algum louco colocou o runlevel 0 ou 6 como default, a m?quina ir? se desligar ou rebootar (ap?s ler o script apropriado).

2.2 rc.K
O rc.K ? utilizado quando o sistema entra no modo monousu?rio. Ele desativa todos os daemons, desabilita os m?ltiplos logins e mant?m os sistemas de arquivos montados (para que seja poss?vel efetuar a manuten??o neles)

A primeira providencia tomada pelo sistema, ? desativar as quotas. Em seguida come?a o processo de desligar os daemons. Primeiramente ? mandado o sinal de HUP, os processos restantes recebem o sinal de TERM e os ultimos recebem o KILL, at? que n?o hajam mais processos em execu??o.

Em seguida o sistema entra no modo monousu?rio e realiza o update das bases de dados. Apesar de extremamente ?til, este script tamb?m ? extremamente curto -;)

2.3 rc.M
Respons?vel pelo modo Multiusu?rio (da? vem o M), o rc.M configura o sistema e carrega o necess?rio para que possamos usufruir do Linux em todas as suas capacidades…

A primeira provid?ncia tomada pelo rc.M ? configurar o tempo de inatividade para que o monitor seja “desligado”. Se isto te incomoda, ou se ? prefer?vel um tempo menor, basta comentar ou alterar este trecho…

Logo em seguida, ele verifica se existe um rc.cdrom e o carrega (caso exista). O pr?ximo passo ? setar o nome da m?quina, se n?o houver nenhum nome configurado (/etc/HOSTNAME) ser? colocado o nome default, darkstar.example.net. Nas pr?ximas linhas ele separa apenas a primeira parte para ser o nome da m?quin (darkstar) o restante fica como nome do dom?nio.

? verificada a exist?ncia do rc.inet1, caso exista, tanto ele quanto o rc.inet2 ser?o carregados. Se ambos n?o existir, ser?o carregados alguns daemons considerados essenciais, o klogd, o syslogd e o lpd (um captura as mensagens de log do kernel, o outro do sistema como um todo e o ?ltimo cuida dos servi?os de impress?o).

Aproveitando que os servi?os de rede j? est?o on-line, o rc.M carrega o m?dulo rc.atalk, para comunica??o com redes Appletalk. Depois inicializa o crond e o atd (ambos executam tarefas agendadas).

O pr?ximo passo ? remover os lockfiles e restaurar a sanidade do sistema. Tamb?m ? executado o ldconfig, que localiza e identifica as bibliotecas do sistema (toda vez que voc? incluir uma biblioteca nova, ? necess?rio rodar o ldconfig).

Agora v?m um grande trecho comentado. Nele h? uma pequena explica??o de como configurar quotas em um sistema Slackware, abaixo desta explica??o est?o os comandos para verificar se existem quotas, chec?-las e ativ?-las.

? ativado o sendmail (se estiver instalado no seu sistema) e o apmd (suporte a APM, se voc? tiver uma fonte ATX, ele pode desligar o seu micro). Antes de ativar o apmd ele verifica se o kernel est? compilado com suporte ? apm.

Estamos na reta final… aqui ? chamado o rc.font, o rc.keymap e o rc.ibcs2, respectivamente respons?veis pelas fontes do console, o mapeamento do teclado e a compatibilidade bin?ria. Os pr?ximos s?o o rc.httpd, rc.samba, rc.gpm, rc.sysvinit e rc.local. Caso voc? n?o queira que algum destes servi?os sejam carregados, basta fazer:

# chmod -x rc.nonono

Assim, o script em quest?o n?o estar? mais como execut?vel. Como o rc.M sempre verifica primeiro se o script ? execut?vel antes de tentar cham?-lo, transformando o script em arquivo comum voc? impede que ele seja carregado. No meu caso o rc.samba, rc.atalk, rc.httpd est?o todos como n?o-execut?veis.

O ?ltimo rc que o rc.M chama ? o rc.local, onde devem ser colocadas as altera??es particulares da sua m?quina.

Quando voc? entra nos n?veis de execu??o 2, 3 ou 5, a inicializa??o p?ra por aqui e carrega o programa de login, geralmente o agetty. Se voc? entrou no n?vel 4, ao inv?s do agetty ser? lido o rc.4…

2.4 rc.4
Script muito simples. Ele verifica se existe o kdm instalado, se houver executa. Se n?o houver kdm, ele procura o gdm e executa. Se n?o houver gdm ele executa o xdm e se n?o houver xdm ele imprime na tela uma mensagem de erro!

Editando este arquivo voc? pode fazer que ele apresente o seu login gr?fico preferido, o meu ? o xdm (ent?o eu comentei todas as linhas e deixei s? a que executa o xdm). Se voc? gosta do wdm, basta inclu?-lo nesta lista (e instalar o wdm na tua m?quina).

2.5 rc.0 e rc.6
Um deles ? um link para o outro. Este script quando chamado rc.0 desliga o computador e quando chamdo rc.6 reinicia a m?quina. Ele salva o rel?gio, desativa as quotas e guarda a semente rand?mica.

Depois ele desmonta os sistemas de arquivo remotos, desativa a swap e desmonta os sistmas de arquivos. Para garantir a integridade do sistema, os discos s?o sincronizados e os dispositivos RAID s?o desativados. O ?ltimo passo ? o desligamento ou o reboot da m?quina.

3 Configura??o da m?quina…
Estes scripts s?o respons?veis por carregar o suporte ao hardware (rc.modules e rc.pcmcia), configur?-lo (rc.serial, rc.cdrom e rc.gpm) ou simplesmente tornar o sistema mais confort?vel (rc.font e rc.keymap). Neste grupo ficou tamb?m o rc.ibcs2, que providencia a compatibilidade bin?ria entre o SCO Unixware (e outros *nix) e o Linux.

3.1 rc.modules
Este arquivo ? respons?vel pelo carregamento dos m?dulos para o kernel. No geral, ? uma extensa lista com todos os m?dulos poss?veis e imagin?veis, sendo que voc? precisa apenas descomentar a linha apropriada (removendo o # da frente) para que o m?dulo seja carregado durante o boot.

Primeiramente ele verifica a exist?ncia de novos m?dulos e realiza o update das depend?ncias. Ou seja, monta uma tabela com o que cada m?dulo precisa para funcionar (por exemplo, o m?dulo para SoundBlaster necessita do SoundCore para funcionar…)

Logo em seguida ele verifica se o suporte a porta paralela est? embutido no kernel, caso n?o esteja, ele carrega o m?dulo para a porta paralela. Perceba que na linha comentada est? um outro modo de carregar o m?dulo, em que se ganha performance (de verdade!). Ao inv?s de carregar o m?dulo sem par?metros, carregue-o informando o io e a irq.

O mesmo m?todo ? utilizado para verificar se o kernel tem suporte a lp (impressora) ou se ? necess?rio carregar o m?dulo. Se voc? usa plip, ou mesmo se tem um zip na paralela e n?o uma impressora, ? uma boa comentar estas linhas, para que o m?dulo lp n?o venha a ser carregado.

Em seguida, vem uma extensa lista com nomes de m?dulos (e alguns par?metros) comentados. Se voc? quiser carregar algum deles, ? s? retirar o # da frente da linha. Apesar de haverem d?zias de m?dulos com placas de rede, a configura??o destas ? prefer?velmente feita atrav?s do rc.netdevice, que ? editado pelo script netconfig (e nada impede que seja feito na m?o).

Este ? um arquivo que merece uma boa olhada, m?dulos para mouses, placas de som, placas de rede, placas SCSI, sistemas de arquivos, etc…

3.2 rc.pcmcia
Como n?o tenho experi?ncia com dispositivos pcmcia, n?o posso dar muitas indica??es de como este arquivo funciona. Observando a sintaxe do script, podemos constatar que ele verifica a exist?ncia de um barramento PCIC, existindo este barramento, ele carrega uma s?rie de m?dulos e o cardmgr, um programa para gerenciar os cart?es.

3.3 rc.serial
Este arquivo ? o respons?vel pelo carregamento de drivers e inicializa??o dos dispositivos seriais de seu computador. ? uma ?tima id?ia mant?-lo exatamente do jeito que est?, e se necessitar de alguma altera??o, mexer preferencialmente no /etc/serial.conf (pode parecer meio covarde, mas em time que est? ganhando n?o se mexe!)
3.4 rc.cdrom
Este script verifica se o CDROM est? montado. Caso n?o esteja, o sistema tenta autodetectar o drive de CDROM (onde geralmente obtem sucesso) e montar o CD. Caso ele n?o consiga carregar nem um CDROM do tipo ATAPI/IDE nem SCSI, ele tenta carregar o m?dulo apropriado para o seu modelo de CDROM (que pelo jeito deve ser um daqueles alien?genas).

Fato interessante, se o CDROM no seu drive for o do Slackware, ele ir? informar:

Mounting Slackware Linux CD-ROM on /cdrom

Acho isso muito show -;)

3.5 rc.gpm
Aqui ? configurado o mouse para o console. Lendo o script ele explica como utilizar a mesma configura??o no X tamb?m. ?tima pedida -:) Se voc? n?o sacar direito como fazer essa “repeti??o” do mouse, leia o meu artigo a respeito do GPM -;)
3.6 rc.font e rc.keymap
Estes dois servem para deixar as coisas mais agrad?veis no console. Por exemplo, colocar uma fonte com acentos e um mapa de teclado que aceite esses acentos -;). Se voc? colocar o mapa com acentos e uma fonte sem acentos, vai ter na sua tela sinais de interroga??o de cabe?a para baixo, carinhas sorridentes e outros s?mbolos estranhos. Se voc? colocar uma fonte com acentos e n?o utilizar o mapa apropriado, voc? ter? v?rios acentos mas nunca ir? conseguir digit?-los… por isso ? importante deixar as coisas bem integradas. Divirta-se!

4 Servi?os de rede
Carregando o m?dulo da placa de rede, configurando a rede e iniciando os mais variados servi?os est?o v?rios outros scripts. Em geral s?o chamados pelo rc.M, mas se voc? n?o quiser carreg?-los basta torn?-los n?o execut?veis. Est? explicadinho na se??o sobre o rc.M -;)

4.1 rc.netdevice
Este script serve unicamente para carregar o m?dulo da placa de rede… ele ? gerado pelo netconfig. Facilita um pouco o trabalho de trocar o m?dulo quando se troca de placa de rede, mas n?o muito…

4.2 rc.inet1
Neste script s?o configuradas as suas interfaces de rede. Tanto a lo (interface de loopback) quanto a eth0 (placa de rede). Aqui ser? dado um IP, m?scara de rede, endere?o de rede e o do broadcast.

Se voc? est? recebendo seu IP por DHCP, basta substituir onde est? DHCP=”no” por DHCP=”yes”.

Ap?s estas etapas, ser? adicionada a rota default. Apesar de poder ser configurado “na unha”, ? muito mais simples configurar este script utilizando o netconfig. Este ? o local apropriado para hackear e colocar mais uma placa de rede, interface plip, etc…

4.3 rc.inet2
Neste script s?o inicializados os servi?os b?sicos de rede. Logo de in?cio s?o setadas algumas vari?veis, uma delas chamada IN_SERV. Por default, o ?nico servidor listado nesta vari?vel ? o lpd, mas podem ser colocados outros servidores aqui. Em servidores NIS, eu costumo colocar o ypserv (a? fica assim: IN_SERV=”lpd ypserv” )

Em seguida, o sistema verifica se o IPV4_FORWARD deve ser ativado ou n?o. Por default ele est? ativado, se voc? n?o gosta muito da id?ia, basta substituir o “1” pelo “0”. Caso voc? tenha mantido o forward ativado, automaticamente o sistema inclui uma prote??o contra ip-spoofing, por?m esta prote??o pode atrapalhar em alguns casos, para desabilit?-la, ? s? descomentar as linhas que tratam do rp_filter (existe um grande coment?rio a respeito no pr?prio rc.inet2, leia-o com aten??o).

Agora ? carregado o rpc.portmap e, se o seu kernel possuir suporte ao NFS (e voc? tiver dispositivos NFS para montar) ser?o montados todos sistemas de arquivo NFS listados em seu fstab. Interessante verificar que ? poss?vel ter o /usr via NFS, j? que o rc.inet2 ? um dos primeiros scripts chamados pelo rc.M.

Neste momento os daemons s?o inicializados. Come?ando pelo syslogd e klogd (j? comentados na se??o sobre o rc.M). Depois ? ativado o inetd, um servidor encarregado de acionar e chamar outros daemons de internet por demanda. Ou seja, voc? n?o precisa manter um servidor de telnet, um de ftp, um de rlogin e outros funcionando ao mesmo tempo, voc? mant?m o inetd e quando chegar uma requisi??o de ftp ele carrega o servidor de ftp, quando chega a de telnet ele aciona o servidor de telnet… a configura??o deste superservidor est? em /etc/inetd.conf.

Em seguida, ? verificada a exist?ncia do servidor de SSH na m?quina. Se o sshd estiver em /usr/local/sbin ou em /usr/sbin, ele ser? carregado. Depois ? testado o named (observe que existem duas maneiras de carregar o named). O mesmo processo ? aplicado ao routed e ao rwhod. Ap?s tudo isto, s?o carregados os servidores contidos na vari?vel IN_SERV.

O pr?ximo trecho trata do NIS. os coment?rios ajudam bastante. Se voc? quiser rodar a tua m?quina como um cliente NIS, precisa descomentar as linhas que configuram o nisdomainname e as que acionam o ypbind. Voc? sendo um server, ? uma boa id?ia (muito boa) habilitar a mudan?a de senhas via yppasswd, ent?o descomente as linhas referentes ao rpc.yppaswdd.

Agora s?o carregados o rpc.mountd (monta dispositivos NFS) o rpc.nfsd (exporta dispositivos NFS) e outros dois que eu n?o tenho a m?nima id?ia do que fa?am (rpc.pcnfsd e rpc.bwnfsd).

Pronto! Acabou o rc.inet2…

4.4 rc.samba
Apenas verifica a exist?ncia dos servidores do samba (smbd e nmbd) e ent?o ativa os dois. Sem mist?rios…

4.5 rc.atalk
Algu?m, REALMENTE usa isso? Este script carrega uma s?rie de servidores para prover o Linux com o protocolo AppleTalk. ? uma esp?cie de samba para redes AppleTalk. Autentica??o de nomes, zonas, etc…

4.6 rc.news
Carrega um servidor de newsgroup. Se voc? estiver como usu?rio, n?o conseguir? olhar este arquivo (que na realidade ? um link para /usr/lib/news/bin/rc.news).

Interessante ? ele rodar o como usu?rio “news” e n?o como root. Outro fato interessante ? ele n?o ser chamado por nenhum outro script. Para cham?-lo, ? necess?rio introduzir no rc.local:

su news -c /etc/rc.d/rc.news

4.7 rc.httpd
? o mais curto de todos os scripts, se constitui de uma ?nica linha acionando o Apache.

5 The End…
O ?ltimo script carregado ? o rc.local. Este ? o lugar onde colocamos as nossas personaliza??es. Por exemplo, podemos colocar aqui alguns comandos para recriar o issue, assim n?s sobrescrevemos o criado pelo rc.S.

Podemos colocar no rc.local chamadas para outros scripts, como o rc.news ou mesmo um rc.firewall. No caso do meu roteador, que ? uma m?quina “dedicada”, est? no rc.local o comando para discar para o provedor…

Depois de lidos todos estes scripts, o sistema carrega os programas de login: agetty no caso dos terminais texto e o rc.4 (que carrega o xdm) no modo gr?fico. ? poss?vel disponibilizar o login em um terminal serial, mas isso foge do escopo deste artigo.

Quaisquer sugest?es, d?vidas ou cr?ticas mande um e-mail para: piterpk@terra.com.br

Esta not?cia veio de LinuxDicas – Artigos, Dicas e Not?cias Sobre o Mundo Linux
http://www.linuxdicas.com.br/index.php

O link desta not?cia ?:
http://www.linuxdicas.com.br/index.php/modules.php?name=Sections&op=viewarticle&artid=96

Posted in Sem categoria

Compactados auto-extratores com bash script e tar

Artigo retirado do site Dicas-L da Unicamp

Colabora??o: Marcelo Criscuolo

Recentemente me deparei com o problema de
criar um arquivo compactado que fosse capaz de se
“auto-descompactar” e realizar algumas outras “tarefinhas
burocr?ticas”. Lembrei-me ent?o que o instalador do J2SDK
da Sun para Linux ? um shell script e resolvi descobrir
como ele era feito. A solu??o ? bem elegante e simples de
ser implementada, trata-se de criar um arquivo composto por
um shell script no in?cio e o arquivo compactado (bin?rio)
no final.

Suponhamos que voc? deseja compactar todo o diret?rio
basedados que cont?m scripts SQL e envi?-lo para algu?m
de maneira que seja necess?rio apenas um comando como
./atualizar-base.sh para o arquivo seja descompactado
e a base seja atualizada com base nos arquivos contidos
no diret?rio.

Para come?ar, o velho tar resolve a primeira parte
do problema:

tar cvzf basedados.tar.gz basedados/“

Agora precisamos do script que vai fazer o “trabalho sujo”,
o atualizar-base-codigo.sh:

#!/bin/bash

# extraindo o arquivo
tail -n +XX $0 > basedados.tar.gz # linha IMPORTANTE

# Descompactando o arquivo extra?do
tar xzf basedados.tar.gz

# Arquivo descompactado, hora de rodar os scripts
for i in basedados/*; do
echo “Rodando o script $i”
# Aqui voc? poderia rodar os scripts. Por exemplo,
# se a base da dados fosse Postgres voc? poderia
# fazer: psql -U usuario base -c “\i $i” , para
# rodar todos os scripts do diret?rio
done

exit 0 # outra linha IMPORTANTE

? hora de fazer o nosso trabalho sujo agora:

Vamos contar as linhas do arquivo:

wc -l atualizar-base-codigo.sh“

Preste aten??o ?s linhas marcadas com IMPORTANTE.

Nesse caso o wc retorna 18, re-edite o arquivo e
substitua o XX da primeira linha marcada como importante
por 19 (18+1), salve o arquivo sem adicionar mais nenhuma
linha. Vamos juntar tudo agora:

cat atualizar-base-codigo.sh basedados.tar.gz > atualizar-base.sh“

Pronto! Concatenamos um arquivo texto e um bin?rio!

O tail extrai as linhas finais de um arquivo, mas
quando o n?mero de linhas ? precedido pelo sinal + ele
extrai todo o final do arquivo, daquela linha em diante
(veja man tail), ? esse o papel do -n +19.

No nosso exemplo, o tail vai extrair o final do pr?prio
shell script (a vari?vel $0 ? expandida para o nome
do arquivo atual) a partir da linha 19, que corresponde ao
arquivo basedados.tar.gz contenado a ele anteriormente.

Por o ?ltimo, o > basedados.tar.gz ? respons?vel
por escrever a sa?da do tail num arquivo ao inv?s de
escrever na tela.

O arquivo ? descompactado com o tar na linha seguinte
e o seu conte?do ? processado pelo for.

Finalmente, na segunda linha marcada com IMPORTANTE,
tem-se o exit 0; esse comando serve para dizer ao
bash que pare de interpretar o script antes de atingir
os dados bin?rios.

Um aviso importante: n?o edite mais o arquivo gerado
pelo cat pois se o editor colocar um EOF no final
o seu arquivo compactado ser? corrompido. ? por isso que
se usa o arquivo atualizar-base-codigo.sh para fazer
a edi??o.

Outra coisa legal que d? pra fazer com isso ? gerar
patches auto-aplic?veis. Ao inv?s de concatenar o
arquivo com um compactado voc? concatena com a sa?da do
diff (o patch). Neste caso o exit 0 tamb?m
? essencial, pela mesma raz?o citada anteriormente, mas
agora o arquivo gerado pode ser editado, j? que um EOF
a mais ou a menos n?o faz diferen?a para o patch. 😉

Posted in Sem categoria

Fazendo um Check-list nos Servi?os do Sistema

Artigo retirado do site Dicas-L da Unicamp

Configurar servi?os hoje em um sistema Linux, n?o ? mais t?o complicado como antigamente. Muitos servi?os, depois de instalado j? saem funcionando com a sua configura??o padr?o, ou muitos j? vem instalados no sistema. Embora quando pensamos em seguran?a j? ? assumido que n?o devemos colocar um servi?o em produ??o com configura??es padr?es sem que as mesmas sejam testadas pensando nos principios de seguran?a.

Mas o que muitos administradores iniciantes e at? mesmo experientes n?o sabem tirar proveito de ferramentas cl?ssicas para checar se o servi?o est? funcionando corretamente, verificar em qual porta ele est? trabalhando, se ele est? recebendo requisi??es corretamente e at? mesmo, em alguns casos, ver se nenhum invasor fez algo em seu sistema que possa prejudica-lo, para isso mostrarei alguns comandos que podem formar o que costumo chamar de Check-List.

Primeiramente temos que saber a qual porta determinado servi?o est? associado. Podemos ver algumas portas padr?es do sistema no arquivo /etc/services. Exemplo de algumas portas

# cat /etc/services
# cat /etc/services | grep -i ssh
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp

Ap?s termos uma no??o das portas em que os servi?os rodam, podemos utilizar um comando chamado netstat. Esse comando vai nos fornecer algumas informa??es sobre os servi?os de rede do nosso sistema. ? v?lido lembrar que encontramos implementa??es do netstat em outros sistemas operacionais e n?o necess?riamente as op??es e mesmos os recursos s?o implementados da mesma forma.

# netstat -nlt

-n : Op??o para fazer o netstat n?o resolver os IP’s para nomes.
-l : Listar os Sockets que est?o Ouvindo(Listen), ou seja, que est?o prontos para receber uma conex?o.
-t : Listar somente os Sockets no protocolo TCP. Poderiamos utilizar o -u para protocolos UDP.

Com isso podemos ver v?rias informa??es sobre os Sockets que est?o aguardando conex?es. Exemplo:

Proto Recv-Q Send-Q Endere?o Local Endere?o Remoto Estado
tcp 0 0 0.0.0.0:22 0.0.0.0:* OU?A

Proto ? o protocolo que este Socket est? trabalhando. No Endere?o Local vemos que a porta 22 pode responder a qualquer interface de rede no sistema (0.0.0.0:22), no Endre?o Remoto mostra que n?o h? nenhuma conex?o relacionada ? aquela porta e que no Estado ela est? em OU?A, ou seja, aguardando conex?es.

Poderiamos utilzar o netstat com o -a tamb?m, no lugar do -t para vermos todos os Sockets tanto os que est?o ouvindo, que n?o est?o ouvindo e os Estabelecidos, que v?o ser muito importantes. Nos Estabelecidos podemos ver em qual interface o servi?o est? conectado e a qual porta e de onde est? vindo a conex?o.

# netstat -nat
Proto Recv-Q Send-Q Endere?o Local Endere?o Remoto Estado
tcp 0 0 192.168.0.1:32778 200.123.123.123:143 ESTABELECIDA
tcp6 0 0 ::ffff:192.168.0.1:22 ::ffff:192.168.0.8:32796 ESTABELECIDA

Agora que sabemos quais sockets est?o dispon?veis, podemos ver qual processo(servi?o) est? rodando nesse socket com o comando fuser.

# fuser -v 22/tcp
-v: Modo Verbose
USER PID ACCESS COMMAND
22/tcp root 3943 f…. sshd

Com ele podemos ver qual usu?rio est? rodando o processo, o PID que ? o n?mero do processo e o programa que est? rodando que nesse caso ? o sshd. Para cada processo que est? rodando, o sistema cria um diret?rio com PID dele no /proc, onde podemos obter algumas informa??es do processo, um deles ? o arquivo cmdline que mostra o caminho completo do programa, nos mostrando assim que aquele programa ? ele mesmo e n?o um program forjado.

# cat /proc/3943/cmdline
/usr/sbin/sshd

Outra ferramenta que poderiamos utilizar ? a lsof, que vai nos mostrar informa??es parecidas com a do netstat e a fuser, s? que em uma ?nica ferramenta. A lsof mostrar? os Socktes que est?o Ouvindo, que est?o Estabelecidos e entre outros, e nos mostrar? tamb?m o usu?rio, o PID e o programa que est? rodando, ou seja, poderiamos dizer que a lsof ? uma jun??o da netstat e a fuser. Por?m a lsof n?o vem instalada em todas as distro Linux, sendo necess?rio instala-l? via pacotes ou pelo source.

# lsof -i

-i : Listar? todos os processos ou arquivos relacionados a uma interface de rede, se n?o for especificado uma interface de rede, como fizemos ele mostrar? do todas as interfaces.

firefox-b 4652 user 36u IPv4 22723 TCP 192.168.0.1:38138->64.233.161.19:www (ESTABLISHED)
ssh 8342 root 3u IPv4 100376 TCP 192.168.0.1:54751->192.168.0.8:ssh (ESTABLISHED)

Uma coisa que muitos administradores tamb?m esquecem de olhar s?o os Raw Sockets, que s?o os Sockets que n?o dependem de um protocolo espec?fico, permite acesso direto a protocolos de baixo n?vel como ICMP, TCP, UDP, e IP, mais considerados por muitos como como um potencial foco de problemas de seguran?a devido ao fato que poucos administradores verificam as atividades de Raw Sockets de seus sistemas.

Podemos ver se existe algum Raw Socket aberto no nosso sistema utilizando o netstat com uma outra op??o.

# netstat -nlw
-w : Lista os Raw Sockets.

Provavelmente n?o ter? nenhum aberto, ent?o retorna um resposta vazia. Mas devemos ter muito cuidado com os Raw Sockets pois muitas BackDoors mais modernas utilizam o Raw Socket para abrir o seu sistema sem depender de um protocolo. O hping pode ser utilizado como uma BackDoor em seu sistema aproveitando-se do Raw Socket para poder executar comandos remotamente em seu sistema. Veja mais detalhes na documenta??o do hping.

Sa?da de uma respota positiva, utilizando o netstat para listar os Raw Sockets.

Proto Recv-Q Send-Q Endere?o Local Endere?o Remoto Estado
raw 0 0 0.0.0.0:255 0.0.0.0:* 7

E um ?ltimo programa que podemos utilizar ? o nmap que ? um poderoso programa para varreduras de portas ,nesse caso vamos ter a possibilidade de fazer uma an?lise interna ou externa do nosso sistema para vermos quais portas/servi?os est?o dispon?veis. O nmap n?o vem por padr?o nas distribui??es Linux, sendo necess?rio instala-lo. Ent?o de uma outra m?quina podemos fazer o seguinte teste.

Para Portas TCP.

# nmap -sT 192.168.0.1

-sT : Varredura de portas TCP completas.
192.168.0.1 -> Seu IP.

PORT STATE SERVICE
9/tcp open discard
13/tcp open daytime
21/tcp open ftp
22/tcp open ssh

Ou podemos testar localmente.

# nmap -sT localhost

# nmap -sT -p 22 localhost

PORT STATE SERVICE
22/tcp open ssh

Para Portas UDP

# nmap -sU 192.168.0.1

-sT : Varredura de portas TCP completas.
192.168.0.1 -> Seu IP.

PORT STATE SERVICE
9/udp open|filtered discard
53/udp open|filtered domain
111/udp open|filtered rpcbind

Ou podemos testar localmente.

# nmap -sU localhost

# nmap -sU -p 53 localhost

PORT STATE SERVICE
53/udp open|filtered domain

Ou ainda olhando as portas TCP e UDP simultaneamente

# nmap -sU -sT 192.168.0.1

Em alguns casos o uso do Nmap pode ser interessante para fazer o checklist de todas as portas ativas no servidor.

# nmap -sU -sT -F 192.168.0.1

-F: Todas as portas decladas no services

Ou olhar porta a porta at? 65535

# nmap -sU -sT -p- 192.168.0.1

Sendo assim conseguiremos ver todas as portas que est?o dispon?veis em nosso sistema.

Podemos ver tamb?m os banners dos servi?os que est?o rodando. Que para um invasor pode ser um informa??o preciosas.

# nmap -sV 192.168.0.1

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.8.1p1 (protocol 2.0)
25/tcp open smtp Exim smtpd 4.50
111/tcp open rpcbind 2 (rpc #100000)
113/tcp open ident OpenBSD identd
MAC Address: 00:50:BF:63:D0:E7 (Mototech)

O nmap possui muitas op??es, veja o manual dele para ver todas as op??es de uso.
CONCLUS?O.

Com o conhecimentos dessas ferramentas um administrador poder? fazer um bom check-list em seu sistema, e ter? um total dom?nio de todos os servi?os que est?o rodando no sistema.

Posted in Sem categoria

Alterando imagem no Grub

Neste artigo iremos apresentar como alterar as imagens no boot loader Grub.

as linhas de seu arquivo /boot/grub/menu.lst deve estar assim

default 0
timeout 30
fallback 1
splashimage=(hd0,1)/grub/splash.xpm.gz

color black/blue white/blue

Salve o arquivo e crie um link simb?lico de /boot/grub para /grub, coloque os arquivo no formato xpm.gz dentro do diret?rio do Grub.

Posted in Sem categoria