UNIX notes

Há um post anterior falando sobre como listar a qual fileset pertence um arquivo. Este post de hoje, mostra o oposto: como listar os arquivos que pertencem a um fileset.

Para isso, usamos a opção “-f” do comando lslpp:

Segue abaixo um exepmlo para o fileset openssh:

1 - Identificar qual o nome do fileset que instala o SSH:

# lslpp -l |grep -i ssh
openssh 4.5.0.1 COMMITTED OpenSSH 4.5p1 Portable for AIX

2 - Listar todos os arquivos deste fileset:

# lslpp -f openssh
Fileset File
—————————————————————————-
Path: /usr/lib/objrepos
openssh 4.5.0.1 /usr/local/bin/ssh-keygen
/usr/local/share/man/man1/ssh-add.1
/usr/local/libexec/sftp-server
/usr/local/bin/ssh-add
/usr/local/bin/ssh-agent
/usr/local/share/man/man5/ssh_config.5
/usr/local/share/man/man1
/usr/local/etc/ssh_config.default
/usr/local/share/man/man5
/usr/local/share/man/man8
/usr/local/share/man/man1/ssh-keygen.1
/usr/local/etc/ssh_prng_cmds.default
/usr/local/etc/moduli
/usr/local/share/man/man8/ssh-keysign.8
/usr/local/etc
/usr/local/share/man/man1/sftp.1
/usr/local/bin/ssh-keyscan
/usr/local/libexec
/usr/local
/usr/local/sbin
/usr/local/share/man/man8/sftp-server.8
/usr/local/bin/scp
/usr/local/etc/sshd_config.default
/var/empty
/usr/local/bin/sftp
/usr/local/share/man/man1/scp.1
/usr
/usr/local/share/man/man8/sshd.8
/usr/local/libexec/ssh-keysign
/usr/local/bin/ssh
/usr/local/share/man/man1/ssh-agent.1
/usr/local/share/man/man8/ssh-rand-helper.8
/usr/local/bin
/var
/usr/local/share/Ssh.bin
/usr/local/libexec/ssh-rand-helper
/usr/local/share/man
/usr/local/share/man/man1/ssh-keyscan.1
/usr/local/bin/slogin -> ./ssh
/usr/local/share/man/man5/sshd_config.5
/usr/local/share
/usr/local/sbin/sshd
/usr/local/share/man/man1/slogin.1 -> ./ssh.1
/usr/local/share/man/man1/ssh.1

O yast é um aplicativo existente na distribuição Suse Linux que oferece uma série de funções administrativas.

Usando o yast já me deparei com a fato dele simplesmente travar. Bem, o que fazer então?

1 - Abrir outra conexão com o servidor

2 - Procurar pelo processo:

# ps -ef |grep -i yast|grep -v grep
root 11082 11027 0 17:22 pts/1 00:00:00 /bin/bash /sbin/yast
root 11104 11082 10 17:22 pts/1 00:00:02 /usr/lib/YaST2/bin/y2base menu ncurses –nothreads
#

3 - Matar os processos:

# kill [PID]

No exemplo do caso acima:

# kill 11082 11104

4 - Verificar se os processos cairam:

# ps -ef |grep -i yast|grep -v grep
#

Feito isso, eu posso tentar usar o yast de novo então? Ainda não. É preciso mais um passo antes disso:

5 - Remover os arquivos de lock caso existam.

Após o kill,, os arquivos de lock podem permancer no diretório /var/run. Podem haver dois deles ou apenas um. Os arquivos de lock:

/var/run/zypp.pid

/var/run/yast.pid

Removendo estes arquivos pode-se usar o yast novamente.

Aos leitores, comunico que este blog ficou offline de 14 a 16 de abril de 2007 devido a interferência indevida da NET/Vírtua.

Alguns problemas de acesso ainda podem ocorrer. Num período de 72 horas tudo deverá estar normalizado.

A explicação completa sobre o ocorrido pode ser vista em:: http://blog.cybershark.net/daniduc/2007/04/17/o-mundo-e-dos-nets-nets-nets/

Um princípio básico em segurança de sistemas, é que todos os serviços que não são utilizados por um servidor sejam desativados.

Um serviço que frequentemente está ativo e muitas vezes não é utilizado, sendo comumente alvo de softwares de scan de segurança nas empresas, é o SNMP.

O SNMP pode ser explorado para se conseguir informações e/ou acesso indevido ao seu sistema.

Abaixo, vou descrever os passos para desativar o serviço SNMP em um servidor rodando o sistema operacional unix Solaris.

Antes de desativar o serviço SNMP, podemos aumentar o nível de log do sistema operacional, editando e configurando o /etc/syslog.conf:

Conforme recomendação no link http://ist.uwaterloo.ca/security/howto/2000-10-04/recommend.html, o log do S.O. pode ser expandido:

#mail.debug ifdef(`LOGHOST’, /var/log/syslog, @loghost)
*.debug ifdef(`LOGHOST’, /var/log/syslog, @loghost)

Agora, para desativar o SNMP, seguir os passos:

1- Parar o serviço:

Devemos parar os 2 daemons ativos através dos scripts init.snmpdx e init.dmi, localizados em /etc/init.d.

foobar:/etc/init.d>ps -ef |grep snmp
root 5565 1 0 Dec 18 ? 0:00 /usr/lib/dmi/snmpXdmid -s foobar
root 5372 1 0 Dec 18 ? 0:02 /usr/lib/snmp/snmpdx -y -c /etc/snmp/conf
root 8761 19661 0 18:24:34 pts/4 0:00 grep snmp

foobar:/etc/init.d>./init.snmpdx stop

foobar:/etc/init.d>ps -ef |grep snmp
root 5565 1 0 Dec 18 ? 0:00 /usr/lib/dmi/snmpXdmid -s foobar
root 11255 19661 0 18:24:43 pts/4 0:00 grep snmp

foobar:/etc/init.d>./init.dmi stop

foobar:/etc/init.d>ps -ef |grep snmp
root 29062 19661 0 18:25:41 pts/4 0:00 grep snmp
foobar:/etc/init.d>

2 - Renomear os scripts de inicialização do SNMP:

Após parar os daemons, deve-se renomear os scripts que iniciam os daemons no processo de boot, para que eles não sejam ativados novamente quando o servidor sofrer um boot. Os scripts ficam localizados normalmente no diretório /etc/rc3.d:

foobar:/etc/rc3.d>ls -l |grep snmp
-rwxr–r– 6 root sys 616 Apr 6 2002 S76snmpdx

foobar:/etc/rc3.d>ls -l |grep dmi
-rwxr–r– 6 root sys 1056 Apr 6 2002 S77dmi

foobar:/etc/rc3.d>mv S76snmpdx DISABLE_S76snmpdx

foobar:/etc/rc3.d>mv S77dmi DISABLE_S77dmi

foobar:/etc/rc3.d>ls -l |grep snmp
-rwxr–r– 6 root sys 616 Apr 6 2002 DISABLE_S76snmpdx
foobar:/etc/rc3.d>ls -l |grep dmi
-rwxr–r– 6 root sys 1056 Apr 6 2002 DISABLE_S77dmi
foobar:/etc/rc3.d>

Feito isso, o serviço SNMP está desativado do seu servidor.

Links:

Security Review: Securing SNMP on Solaris - Information Systems and Technology - University of Waterloo
http://ist.uwaterloo.ca/security/howto/2000-10-04/recommend.html

Eu já escrevi o procedimento para identificar à qual pacote (fileset) pertence um arquivo no Aix. Segue agora o procedimento equivalente para Solaris.

Como faço, por exemplo, para saber qual o pacote de instalação da biblioteca libgcc_s.so.1?

Tendo o arquivo instalado em uma máquina:

1 - Com o find eu localizo o arquivo:

# find / -name libgcc_s.so.1
/usr/local/lib/libgcc_s.so.1
/usr/local/lib/sparcv9/libgcc_s.so.1
/opt/sfw/gcc-3.2/lib/sparcv9/libgcc_s.so.1
/opt/sfw/gcc- 3.2/lib/libgcc_s.so.1

2 - Com o comando pkgchk eu identifico qual o pacote de instalação de um determinado arquivo.

Assim para saber o pacote correspondente ao arquivo /usr/local/lib/libgcc_s.so.1:

# pkgchk -l -p /usr/local/lib/libgcc_s.so.1
Pathname: /usr/local/lib/libgcc_s.so.1
Type: regular file
Expected mode: 0644
Expected owner: root
Expected group: bin
Expected file size (bytes): 169356
Expected sum(1) of contents: 21886
Expected last modification: Sep 12 06:48:00 2004
Referenced by the following packages:
SMCgcc342
Current status: installed

Da man page do comando, as opções utilizadas no exemplo acima:

-l
List information on the selected files that make up a
package. This option is not compatible with the -a,
-c, -f, -g, and -v options.

-p
path
Only check the accuracy of the path name or path
names listed.
path can be one or more path names separated
by commas (or by white space, if the list is quoted).

Para mais informações:

# man pkgchk

Para configurar uma política de senhas no Solaris, edita-se o arquivo /etc/default/passwd.

Neste arquivo podemos definir opções como no exemplo a seguir:

MAXWEEKS=4
MINWEEKS=2
PASSLENGTH=6
WARNWEEKS=1

OBS: Os valores exemplificados acima não são nenhuma recomendação de configuração.

MAXWEEKS: Número máximo em semanas que a senha é válida
MINWEEKS: Número minimo em semanas em que a senha deve permancer sem que possa ser trocada.
PASSLENGTH: Número mínimo de caracteres exigidos na senha
WARNWEEKS: Número de semanas antes da expiração da senha, que o sistema alerta o usuário que sua senha irá expirar.

No entanto, no Solaris, a política de senhas definida neste arquivo se aplica para todos os usuários do sistema.

Agora, e se você precisar que algum usuário não tenha sua senha expirada?

A alteração de um usuário para que ele não esteja mais sujeito as regras de expiração de senha é feita através do arquivo /etc/shadow.

Basta editar o arquivo (vi /etc/shadow) e alterar algum dos campos; min, max, ou warn; para o valor “-1“.

Feito isso, salve o arquivo e execute o comando “pwconv“.

Após o pwconv, o campo que foi alterado para “-1″ ficará vazio.

Este procedimento está documentado na man page do shadow:

http://docs.sun.com/app/docs/doc/816-5174/6mbb98uju?a=view#indexterm-267

“A value of –1 for min, max, or warn disables password aging.”

Estes são os campos do arquivo shadow:

username:password:lastchg:min:max:warn:inactive:expire:flag