UNIX notes

As informações a seguir foram escritas num Forum do “LinusQuestions.org” pelo usuário “Harry Seldon“.

Achei um resumo útil e decidi salvar aqui no “meu” bloco de notas.

Fonte: http://www.linuxquestions.org/questions/aix-43/aix-default-user-list-612651/

“I work at a company that gets audited all the time. The ones we’re most commonly asked to remove are guest, lpd, uucp, nuucp (if it’s there) and imnadmin. Here’s a list of accounts I put together about a year ago; most of it is relevant, I think:

daemon - The daemon user account exists only to own and run system server processes and their associated files. This account guarantees that such processes run with the appropriate file access permissions.

bin - The bin user account typically owns the executable files for most user commands. This account’s primary purpose is to help distribute the ownership of important system directories and files so that everything is not owned solely by the root and sys user accounts.

sys - The sys user owns the default mounting point for the Distributed File Service (DFS) cache, which must exist before you can install or configure DFS on a client.

adm - The adm user account owns the following basic system functions:
* Diagnostics, the tools for which are stored in the /usr/sbin/perf/diag_tool directory.
* Accounting, the tools for which are stored in the following directories:
o /usr/sbin/acct
o /usr/lib/acct
o /var/adm
o /var/adm/acct/fiscal
o /var/adm/acct/nite
o /var/adm/acct/sum

uucp - Owner of hidden files used by uucp protocol. The uucp user account is used for the UNIX-to-UNIX Copy Program, which is a group of commands, programs, and files, present on most AIX systems, that allows the user to communicate with another AIX system over a dedicated line or a telephone line.

guest - Allows access to users who do not have access to accounts.

nobody - The nobody user account is used by the Network File System (NFS) to enable remote printing. This account exists so that a program can permit temporary root access to root users

lpd - Owner of files used by printing subsystem. This account has been disabled.

imnadm - IMN search engine used for Documentation Library Search.

lp - Possibly something to do with printing.

invscout - Surveys the host system for currently installed microcode or Vital Product Data (VPD).

snapp - The account that manages Snapp, an extensible, XML-based application that provides a menu-driven interface for UNIX system administration tasks on a handheld PDA.

sshd - The user account for managing the sshd service.”

O sendmail é um servidor de email que apresenta diversas vulnerabilidades.É possível incluir algumas opções em seu arquivo de configuração que minimizam alguns desses problemas.

Incluir a seguinte linha:

# don’t allow operations which are potential security problems
#
# These three flags (needmailhelo,needvrfyhelo,needexpnhelo) cause
# sendmail to require a valid HELO/EHLO command from the client
# before accepting certain other commands
#
#
Opnoexpn,novrfy,authwarnings,needmailhelo,needvrfyhelo,needexpnhelo

Mais informações sobre as opções configuradas:

http://www.onlamp.com/pub/a/onlamp/excerpt/sendmailckbk_chap01/index1.html?page=last

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

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

Como bloquear o login de um usuário no Solaris?

Para isso utilizar o comando:

# passwd -l [nome do usuário]

Dessa forma o usuário não poderá se logar no sistema embora sua conta continue existindo.

Referência:

http://es.tldp.org/Manuales-LuCAS/doc-unixsec/unixsec-html/node136.html