Este capítulo documenta diversos métodos de fazer restrições de contas, limitação de acesso interno/externo, de recursos por usuários/grupos, login, tempo máximo ocioso, e outros modos para limitar o uso de recursos do sistema. Também são descritos métodos para aumentar a segurança do acesso físico a seu servidor e maneiras de restringir o uso de serviços disponíveis no sistema.
Se você deseja restringir o acesso de máquinas na rede ou portas específicas em sua máquina, veja também .
bashVariáveis exportadas na forma comum podem ser modificadas a qualquer momento pelo usuário, e isso pode trazer problemas de acordo com o tipo de sistema que administramos. A definição da variável como somente leitura (readonly) evita a maioria destes problemas:
readonly TESTE="123"
A variável TESTE não poderá ser modificada ou excluída. Com isto o administrador pode "bloquear" a modificação de variáveis que controlam o funcionamento de determinados recursos do interpretador de comandos (alguns deles serão vistos ainda nesta seção).
OBS1: Algumas variáveis de controle de ambientes ambiente do interpretador de comandos já são iniciadas com valores somente leitura (como as variáveis EUID e PPID)
OBS2: Variáveis exportadas como somente leitura em shell scripts são mantidas até a finalização do script e depois liberadas.
O controle de acesso a diretórios de usuários é importante quando desejamos que outras pessoas não tenham acesso ao diretório de outros usuários, violando a privacidade do mesmo e obtendo acesso a partes indesejáveis, principalmente do usuário root. É recomendado restringir o acesso somente ao dono e grupo do usuário, bloqueando o acesso a outros tipos de usuários:
chmod 2750 /root
chmod 2750 /home/usuario
O exemplo acima permitirá o acesso do diretório /root e
/home/usuario somente ao usuário e grupo que pertencem. Este
processo pode ser facilitado na criação dos diretórios de usuários em
/home especificando a variável: DIR_MODE=0750 no
arquivo /etc/adduser.conf.
OBS: Algumas distribuições de Linux garantem o
acesso livre a diretórios de usuários por padrão pois alguns daemons que
requerem acesso a diretório de usuários rodam sob outros usuários ao invés do
root. Um bom exemplo é a utilização do recurso "UserDir" do
Apache para servir requisições como
http://servidor.org/~usuario.
A restrição de diretório home neste caso bloqueará o acesso do servidor web
Apache ao diretório /home/usuario/public_html. Mesmo
assim, uma alternativa para garantir a utilização da restrição é incluir o
usuário do servidor web Apache (www-data) no grupo
"usuario" (que possui acesso ao diretório
/home/usuario):
adduser www-data usuario
Isto garantirá que o servidor Apache continue servindo as
requisições dentro do diretório /home/usuario, com acesso
garantido via grupo. O mesmo principio pode ser aplicado em outros programas,
apenas leve em consideração que se um cracker tomar conta do processo que tem
acesso ao seu diretório home restrito, ele certamente também terá acesso.
Quando o bash é iniciado com o parâmetro -r,
--restricted ou como rbash, o shell restringe o uso
dos seguintes recursos em sua seção:
cd para mudar de diretório.
/
/ como argumento para
o comando builtin (embutido no interpretador de comandos).
/ como argumento a opção -p no comando
hash (embutido no interpretador de comandos).
exec para substituir o shell por outro
comando.
enable
(embutido no interpretador de comandos).
command.
Estas restrições são ativadas após a leitura dos arquivos de inicialização do interpretador de comandos. O shell restrito desliga as restrições quando um shell script é executado.
A variável TMOUT determina o tempo de inatividade de um shell para que ele seja terminado.
export TMOUT=600
Terminará o bash caso nenhum comando seja executado no período de
600 segundos (5 minutos). Veja Uso do comando readonly para
exportar variáveis, Section 18.1.1 como complemento.
Todos os comandos que digitamos em uma seção do shell são registrados no
arquivo ~/.bash_history, as seguintes variáveis fazem seu
controle:
~/.bash_history. Caso não seja especificado, os
comandos não serão gravados após finalizar o shell.
Se você possui muitos usuários em seu sistema, é recomendado ajustar estas variáveis como somente leitura para que o usuário não desative o logging por qualquer motivo (veja Uso do comando readonly para exportar variáveis, Section 18.1.1).
Existem casos onde o usuário precisa estar cadastrado no sistema mas não precisa ter acesso a uma conta de login válida (como um sistema servidor de e-mail ou outros serviços). Neste caso a desabilitação dos serviços de shell aumentará um pouco a segurança do sistema, mesmo conseguindo acesso a conta/senha estará impedido de entrar no sistema (pelo menos terá um pouco mais dificuldade para conseguir isso).
Um programa que é muito usado para desabilitar o shell exibindo uma mensagem ao
usuário que fez a tentativa é o falselogin. Ele deve ser colocado
como o "shell padrão" no arquivo /etc/passwd e exibirá a
mensagem contida no arquivo /etc/falselogin.conf quando o login
para aquele usuário for tentado. Esta operação pode ser facilitada usando a
variável DSHELL=/usr/bin/falselogin no arquivo
/etc/adduser.conf.
Uma forma alternativa de desativar o serviço de login de TODOS os usuários
(exceto o root e os já logados no sistema) é criar um arquivo
chamado /etc/nologin e colocando uma mensagem dentro dele, que
será exibida quando tentarem efetuar o login no sistema.
OBS: Tome cuidado ao usar esta alternativa, este método deve
ser usado somente em caso de EMERGÊNCIA, as distribuições
Linux usam este método para bloquear o login de outros usuários
durante o processo de inicialização, removendo assim que o processo é
terminado. Esteja consciente disso.
Em alguns casos, o uso do PAM pra desabilitar os serviços de login pode ser mais adequado (veja Restringindo/Bloqueando o login, Section 18.2.3).
Plugglable Autentication Modules (Módulos de autenticação plugáveis) são um
conjunto de bibliotecas usadas para fazer autenticação, gerenciamento de
contas, controle de recursos dos usuários no sistema, em adição ao tradicional
sistema de acesso baseado em usuários/grupos. Este recurso permite modificar a
forma que um aplicativo autentica e define recursos para o usuário sem
necessidade de recompilar o aplicativo principal. Os recursos que desejamos
controlar restrições via PAM são especificados individualmente por serviços nos
arquivos correspondentes em /etc/pam.d e então os arquivos
correspondentes em /etc/security são usados para controlar tais
restrições.
Nesta seção assumirei explicações dirigidas aos recursos controlados pelos
arquivos em /etc/security A maioria das explicações são baseadas
em testes e nos próprios exemplos dos arquivos de configuração do PAM.
Um método simples de se determinar se um programa binário possui suporte a PAM é executando o comando:
ldd [programa]
Por exemplo:
ldd /bin/login
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4001c000)
libpam.so.0 => /lib/libpam.so.0 (0x40049000)
libpam_misc.so.0 => /lib/libpam_misc.so.0 (0x40051000)
libdl.so.2 => /lib/libdl.so.2 (0x40054000)
libc.so.6 => /lib/libc.so.6 (0x40058000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Caso a biblioteca libpam for listada, o programa tem suporte a PAM
compilado. Programas que não possuem suporte a PAM deverão ter o código fonte
modificado inserindo as funções para tratamento dos módulos de autenticação.
O Policiamento padrão do PAM é especificado em /etc/pam.d/other e
define o que acontecerá caso nenhum dos arquivos de controle de serviço em
/etc/pam.d confiram com o serviço em questão. Normalmente o
módulo pam_unix.so é usado para fazer o policiamento padrão, para
deixar o sistema mais seguro, utilize a seguinte configuração no arquivo
/etc/pam.d/other:
auth required /usr/lib/security/pam_warn.so
auth required /usr/lib/security/pam_deny.so
account required /usr/lib/security/pam_deny.so
password required /usr/lib/security/pam_warn.so
password required /usr/lib/security/pam_deny.so
session required /usr/lib/security/pam_deny.so
O módulo pam_deny.so é responsável por fazer o bloqueio, e o
pam_warn envia avisos ao syslog (facilidade
auth nível notice) caso serviços módulos PAM que necessitem
do serviço de autenticação sejam bloqueados (isto não é feito automaticamente
pelo pam_deny.so).
OBS: Esta configuração poderá causar bloqueio em muitas coisas
caso possua módulos de autenticação mau configurados. Esteja certo de utilizar
o módulo pam_warn.so (antes do pam_deny.so) nas
diretivas restritivas para entender qual é o problema através da análise dos
arquivos de logs.
Mais detalhes sobre a configuração de módulos de autenticação poderão ser
encontrados no endereço ftp://ftp.us.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html
e http://www.kernel.org/pub/linux/libs/pam/pre/doc/rfc86.0.txt.gz.
Isto é controlado pelo arquivo /etc/security/access.conf. O
formato deste arquivo consistem em três campos separados por ":":
ttyname), nomes de máquinas, nomes de domínios (começando com
"."), endereços IP ou FQDN, porção de rede (finalizando com um
"."). As palavras chave ALL (todos) e
LOCAL (máquinas na mesma rede) também podem ser usadas.
OBS1: - A configuração padrão do access.conf é
garantir o acesso a todos os usuários, através de qualquer lugar (permissiva).
OBS2:: Mesmo se existir uma regra autorizando o acesso ao usuário, as restantes serão verificadas em busca de uma que bloqueie o acesso do usuário. Se nenhuma regra conferir, o usuário terá acesso garantido.
OBS3: - O nome de grupo somente é checado quando nenhum nome de usuário confere com nenhum usuário logado no sistema.
OBS4: - Grupos/usuários NIS podem ser especificados precedendo o nome do usuário ou grupo por uma "@".
Abaixo uma configuração restrita de /etc/security/access.conf:
#
# Desabilita o login de todos os usuários EXCETO o root no terminal tty1
-:ALL EXCEPT root:tty1
# Permite o login no console de todos os usuários especificados.
+:gleydson root:console
# Conexões vindas da rede *.debian.org e *.debian.org.br de usuários pertencendo
# ao grupo operadores são consideradas seguras (exceto para o usuário root).
+:operadores EXCEPT root: .debian.org .debian.org.br
# Qualquer outra tentativa de acesso não definida acima é bloqueada imediatamente.
-: ALL: ALL
Estas restrições são controladas pelo arquivo
/etc/security/time.conf, a sintaxe deste arquivo é quatro campos
separados por ";":
/etc/pam.d).
OBS: O "*" poderá ser usado somente no primeiro, segundo ou terceiro campo em uma mesma regra.
O sinal "!" especifica uma exceção. A faixa de horas é especificada após o dia no formato HHMM-HHMM. Por exemplo:
MoTuWe0000-2400 - Segundas, terças e quartas
MoFrSu0800-1900- - Segundas, sextas e domingo das 08:00 da manha as 19:00 da noite.
FrFr0500-0600 - Não será realizada na sexta (especificações repetidas são anuladas)
de 05:00 as 06:00.
WkWe0731-1456 - Todos os dias da semana a partir de Quarta de 07:31 da manhã as
14:56 da tarde.
AlMo0000-2400 - Todos os dias da semana, exceto segunda-feira.
Por padrão o acesso é garantido a todos os usuários. Abaixo um exemplo de
restrições usando o /etc/security/time.conf:
# Bloqueia o login do usuário user1 ou user2 em qualquer tty, a restrição
# durante todos os dias de 00:00 as 06:30
login;tty*;user1|user2;!Al0000-0630
# Bloqueia o acesso do usuário root ao serviço login nos terminais tty*
# (e não nos terminais ttyp*) nos finais de semana.
login;tty* & !ttyp*;root;!Wd0000-2400
# O usuário 1 não poderá efetuar o login as terças feiras de 00:00 as 06:00
login;!tty*;user1;Tu0000-0600
OBS1: Mesmo se existir uma regra autorizando o acesso ao usuário, as restantes serão verificadas em busca de uma que bloqueie o acesso do usuário. Se nenhuma regra conferir, o usuário terá acesso garantido.
OBS2: Quando as restrições de tempo são ativadas no
/etc/security/time.conf, o daemon logoutd poderá ser
ativado manualmente (através de /etc/init.d/logoutd) para monitora
as restrições neste arquivo, forçando o logout de usuário de acordo com as
configurações do /etc/security/time.conf. Isto ocorrerá
automaticamente na próxima vez que iniciar o sistema (a distribuição detecta a
presença de restrições de tempo no arquivo /etc/security/time.conf
para decidir se deve ou não carregar este daemon).
Quando não está em execução, os limites de tempo são verificados somente no login do usuário, ele poderá ultrapassar este tempo sem ser desconectado do sistema.
Este recurso é controlado pelo arquivo /etc/security/group.conf.
Este arquivo é composto por 5 campos separados por ";" (os 4
primeiros são os mesmos explicados em Restrições de serviços PAM baseados em
dia/hora, Section 18.2.4. O 5o campo contém um ou mais grupos (separados
por espaços ou vírgulas) que serão adicionados aos grupos do usuário quando as
condições dos campos anteriores conferirem.
OBS: Se o usuário escrever um programa que chama um interpretador de comandos e der a permissão SGID (chmod g+s programa), ele terá acesso àquele grupo na hora que quiser. Restrinja o uso de grupos somente a usuários de confiança ou crie grupos específicos para evitar problemas.
Exemplo de configuração do arquivo /etc/security/group.conf:
# Permite que o usuário gleydson tenha acesso ao grupo floppy efetuando o login
# entre 08:00 da manha e 19:00 da noite
login;tty*;gleydson;Al0800-1900;floppy
# Todos os usuários podem ter acesso ao grupo games e sound aos sábados e domingos
login;tty*;*;SaSu0000-2400;sound games
# Todos os usuários podem ter acesso ao grupo games e sound todos os dias
# de 18:00 as 05:00 da manhã (fora do horário de expediente ;-)
login;tty*;*;Al1800-0500;sound,games
# Backups são permitidos fora do horário de expediente (para não sobrecarregar
# a CPU e evitar o uso excessivo de disco).
login;tty*;gleydson;Al1830-2400;backup
OBS:: Mesmo que uma regra confira com o usuário, as outras também serão verificadas para garantir acesso grupos extras.
Estas restrições são especificadas no arquivo
/etc/security/limits.conf. Seu formato consiste em 4 campos
separados por ou ou mais espaços:
Quando somente o limite "hard" (rígido) é especificado, o limite suave assume o mesmo valor.
Os limites aplicados ao usuário podem ser visualizados através do comando
ulimit -S -a (para listar limites suaves - soft) e ulimit -H
-a (para listar limites rígidos - hard). Caso o parâmetro -S
ou -H sejam omitidos, os limites listados serão os suaves (soft). Um
exemplo de /etc/security/limits.conf (retirado da distribuição
Debian GNU/Linux:
* soft core 0
* hard rss 10000
@student hard nproc 20
@faculty soft nproc 20
@faculty hard nproc 50
ftp hard nproc 0
@student - maxlogins 4
gleydson - maxlogins 2
OBS: Estas permissões passam a ter efeito no momento que o
usuário se conecta ao sistema, e não quando elas são modificadas no arquivo
/etc/security/limits.conf.
Usuários podem ter o acesso liberado a diretórios/arquivos execução de
programas de acordo com o grupo que pertencem. Este é um recurso valioso na
administração de sistemas Unix que se bem usado, aumenta as
restrições de acesso e segurança no acesso/utilização de programas em um
ambiente de trabalho. Usuários de sistema tendem a usar o usuário
root para fazer tarefas como conexão com internet, utilização da
placa de som, modem, etc. e as vezes nem sabem que isso pode ser feito através
do mesmo usuário adicionando este a um grupo específico.
Esta tarefa pode ser feita com o comando adduser usuário grupo ou
editando manualmente os arquivos /etc/group e
/etc/gshadow. Podemos ter as seguintes situações facilitadas com
o uso de grupos:
/dev/audio, /dev/dsp, /dev/sndstat, etc.
normalmente tem permissão leitura/gravação para o usuário root e
grupo audio (cheque com o comando ls -la /dev/audio).
Para autorizar determinados usuários usar a placa de som basta adiciona-los
neste grupo: adduser usuario audio.
OBS Certamente o usuário terá acesso aos arquivos de
configuração da discagem do ppp e conseqüentemente a senha de
conexão internet, e esta senha é a mesma usada no e-mail primário do provedor
(com o mesmo nome da conta). Esta mesma situação pode acontecer com outros
programas que autorize o acesso a grupos, é importante que conheça bem as
permissões do programa e entender se existem riscos.
groupadd gp1, a opção -g
permite selecionar manualmente a GID. Opcionalmente você poderá usar um grupo
já existente no sistema (veja o arquivo /etc/group).
mkdir projeto1).
projeto1/ no grupo gp1, somente estes usuários e o
root terão acesso ao diretório (permissões 2770).
A maioria das distribuições Linux vem com uma boa política de
grupos para permitir um controle eficaz de recurso. Se você quer saber quais
arquivos em seu sistema pertencem a determinado grupo (útil para saber o que o
usuário terá acesso se adiciona-lo àquele grupo) execute o comando:
find / -group nome_do_grupo
A ferramenta ideal para isto é o sudo. Através dela é possível
permitir um usuário comum executar um comando como root e
registrar quando isto foi feito. É possível selecionar os usuários/grupos que
terão acesso e quais aplicativos que poderão ser usados, estas configurações
são feitas no arquivo /etc/sudoers.
Por exemplo, para o usuário "john" usar o comando shutdown para desligar o computador: sudo shutdown -h now.
O sudo é um programa muito completo, tomaria muitos Kilobytes
neste guia. Recomendo dar uma lida na página de manual para entender como as
variáveis do arquivo de configuração funcionam. Mesmo assim aqui vai um
exemplo simples deste arquivo para iniciar rapidamente o uso do
sudo:
# arquivo sudoers.
#
# Edite este arquivo com o comando 'visudo' como root
#
#
# Especificação de máquinas. O primeiro campo (Host_Alias) diz que a variável
# LOCALSERVER será um nome/endereço de máquina
Host_Alias LOCALSERVER=192.168.0.1
# Especificação de usuários. O primeiro campo (User_Alias) diz que a variável
# NETMASTERS armazenará nomes de usuários
User_Alias NETMASTERS=gleydson, goodboy
# Comandos. O primeiro campo (Cmnd_Alias) diz que a variável
# C_REDE contém comandos do sistema. Mais de um parâmetro
# deve ser separado por vírgulas
Cmnd_Alias C_REDE=/sbin/ipchains, /sbin/iptables
# Padrões que se aplicam aos usuários da variável NETMASTERS. O parâmetro
# mail_always sempre envia um e-mail ao root avisando sobre o uso do
# sudo
Defaults:NETMASTERS mail_always
# As linha que começam com o nome de usuário ou variável "User_Alias"
# definem o acesso aos recursos. O primeiro campo é o usuário, o segundo
# o endereço de acesso (opcionalmente seguido de um sinal "=" para
# especificar opções adicionais) o terceiro o comando ou lista de comandos
#
# O usuário root não tem restrições
root ALL=(ALL) ALL
# Permite que os usuários especificados na variável NETMASTERS
# acessando dos locais em LOCALSERVER utilizem os comandos
# em C_REDE (sem fornecer senha).
NETMASTERS LOCALSERVER=NOPASSWD: C_REDE
Edite este arquivo com o comando visudo, ele faz algumas checagens
para detectar problemas de configuração.
su
Restrições de acesso através de grupos, bloqueio de acesso, acesso direto sem
senha, etc. podem ser aplicados ao sudo via seu arquivo de configuração PAM
/etc/pam.d/su. Abaixo um exemplo explicativo deste arquivo:
# A configuração abaixo requer que o usuário seja membro do
# grupo adm para usar o 'su'.
# auth required pam_wheel.so group=adm
# Membros do grupo acima não precisam fornecer senha, temos confiança neles.
# auth sufficient pam_wheel.so trust
# Usuário que pertencem ao grupo "nosu" nunca deverão ter acesso ao 'su'
# auth required pam_wheel.so deny group=nosu
# O root não precisa fornecer senha ao 'su'
auth sufficient pam_rootok.so
# Ativa as restrições PAM de /etc/security/limits.conf
session required pam_limits.so
# Isto ativa as restrições PAM de /etc/security/time.conf no
# comando 'su'
account requisite pam_time.so
# Módulos padrões de autenticação Unix
auth required pam_unix.so
account required pam_unix.so
session required pam_unix.so
O serviço identd permite identificar os usuários que estão
realizando conexões TCP, adicionalmente esta característica é usada por
programas para fazer restrições para usuários em adição ao endereço de
origem/destino. A sintaxe usada nas diretivas de acesso é especificada na
forma usuário@endereço. O Servidor ident,
Chapter 13 explica a configuração/utilização/vulnerabilidades e
recomendações sobre este serviço.
Diversos programas que possuem controle de acesso baseado em IP's/hosts aceitam
esta especificação, como o exim, ircd, e o conhecido
tcpd.
Segue um exemplo da utilização do identd com o arquivo
hosts.allow:
# Permite o acesso ao serviço de telnet somente ao usuário gleydson conectando
# a partir da máquina com IP 192.168.1.1
in.telnetd: gleydson@192.168.1.1
# Permite o acesso ao serviço ftp somente ao usuário gleydson conectando de
# qualquer máquina da rede 192.168.1.*
in.ftpd: gleydson@192.168.1.
Note que a utilização do identd torna a utilização do serviço um
pouco mais restrita, somente conhecendo os "logins" de quem tem
acesso ao serviço, um cracker conseguirá ter acesso ao mesmo serviço naquele
sistema (este é um dos motivos que é recomendado sempre divulgar o mínimo
detalhes possíveis sobre o sistema para minimizar riscos de ataques).
Veja mais detalhes sobre o uso do identd em Servidor ident, Chapter 13.
Desative todos os serviços que não serão utilizados no arquivo
/etc/inetd.conf, isto diminui bastante as possibilidades de
ataques em seu sistema. Os nomes de serviços são os parâmetros especificados
na primeira coluna do arquivo /etc/inetd.conf (por exemplo, talk,
ircd, pop3, auth, smtp).
Para desativar serviços neste arquivo, ponha o símbolo "#" no inicio das linhas que deseja comentar e execute um killall -HUP inetd. Alternativamente, o comando update-inetd pode ser usado para facilitar esta tarefa:
update-inetd --disable finger,talk,time,daytime
update-inetd --disable
Este comando envia automaticamente o sinal de reinicio (HUP) ao
inetd. O serviço poderá ser novamente ativado substituindo a
opção --disable por --enable ou retirando o trecho
"#<off>#" no começo da linha do serviço do
/etc/inetd.conf.
hosts.equiv e .rhosts
O arquivo hosts.equiv contém uma lista de usuários
autorizados/desautorizados que podem fazer uso dos serviços "r*" sem
fornecer uma senha (como rsh, rcp,
rexec, etc), veja /etc/hosts.equiv e /etc/shosts.equiv,
Section 4.8.3.3. É muito fácil falsificar um nome de usuário para obter
acesso aos privilégios de outro usuário usando este recurso.
Os arquivos ~/.rhosts, ~/.shosts tem o funcionamento
parecido com o hosts.equiv mas contém somente dois campos, o
primeiro especificando o nome do computador (FQDN) e o segundo o nome do
usuário que tem permissão de acesso sem fornecer senha. Ele garantirá este
acesso ao usuário e máquina remota especificada neste arquivo. Se for definido
somente o nome do computador, o nome de usuário deverá ser o mesmo do local
para que o acesso sem senha seja garantido. É recomendável restringir o acesso
a estes arquivos somente ao usuário/grupo quando for realmente necessário. Um
exemplo de ~/.rhosts:
maquina1.dominio.com.br usuario1
maquina2.dominio.com.br usuario2
O uso destes dois mecanismos e dos serviços "r*" são desencorajados! (o último por usar transferência de dados não criptografadas, veja Servidor ssh, Chapter 15 para uma alternativa melhor). Utilize estes dois mecanismos somente se deseja facilidade no gerenciamento e se sua rede seja absolutamente confiável e a segurança de dados não seja prioridade pra você...
Por padrão todos que tem acesso ao console do sistema podem efetuar o reinicio do computador pressionando CTRL+ALT+DEL. Estas teclas de combinação são definidas pela linha
ca:12345:ctrlaltdel:/sbin/shutdown -r now
do arquivo /etc/inittab. A opção -a (access) do
shutdown restringe isto, permitindo somente o reinicio do sistema
caso um dos usuários cadastrados no arquivo /etc/shutdown.allow
estejam logados no console. Caso nenhum usuário autorizado esteja logado, a
mensagem shutdown: no authorized users logged in é exibida no
console local.
O arquivo /etc/shutdown.allow deve conter um usuário por linha e
32 no máximo.
A mesma linha do /etc/inittab pode ser modificada para a seguinte:
ca:12345:ctrlaltdel:/sbin/shutdown -a -t5 -r now
OBS: Se a opção -a seja especificada e o arquivo
/etc/shutdown.allow não existe, a opção -a é ignorada.
O patch restricted proc fs é um dos melhores para realizar esta
tarefa. Restringindo o acesso ao sistema de arquivos /proc evita
que o usuário normal tenha acesso aos detalhes sobre processos de outros (com
ps aux) ou acesso a detalhes de processos de outros usuários
existentes nos subdiretórios numéricos (equivalentes a PID) em
/proc. Abaixo algumas características do patch restricted
proc fs:
Unix).
/proc, qualquer usuário que
pertença ao grupo especificado poderá visualizar todos os processos e entrar em
qualquer diretório do kernel (sem restrições, como se não tivesse o patch).
Este patch deve ser baixado de http://noc.res.cmu.edu/proc,
existem versões para os kernels da série 2.2 e 2.4, baixe e aplique o patch, na
configuração do kernel ative a opção Restricted Proc fs support.
Compile e instale seu kernel.
No arquivo /etc/fstab inclua um grupo para a montagem do sistema
de arquivos /proc (vamos usar o grupo adm com a GID
4):
# /etc/fstab: informações estáticas do sistemas de arquivos.
#
# <Sist. Arq.> <Ponto Mont.> <tipo> <opções> <dump> <passo>
proc /proc proc defaults,gid=4 0 0
Após reiniciar o sistema, execute o comando ls -lad /proc note que
o grupo do diretório /proc será modificado para adm.
Agora entre como um usuário e execute um ps aux, somente seus
processos serão listados. Para autorizar um usuário específico ver todos os
processos (ter acesso novamente ao diretório /proc), inclua este
no grupo que usou no arquivo /etc/fstab:
adduser usuario adm
Após efetuar o usuário já estará pertencendo ao grupo adm (confira digitando groups), e poderá ver novamente os processos de todos os usuários com o comando ps aux.
OBS1: Incluir um usuário no grupo adm É PERIGOSO,
porque este usuário poderá ter acesso a arquivo/diretórios que pertençam a este
grupo, como os arquivos/diretórios em /var/log. Se esta não é sua
intenção, crie um grupo independente como restrproc para controlar
quem terá acesso ao diretório /proc: addgroup
restrproc.
OBS2: Se a opção gid não for especificada para a
montagem de /proc no /etc/fstab, o grupo
root será usado como padrão. NUNCA adicione usuários ao grupo
root, use o método da observação acima para permitir outros
usuários ver todos os processos em execução.
OBS3 Caso o servidor identd esteja sendo usado na
máquina servidora, será necessário roda-lo com a mesma GID do diretório
/proc para que continue funcionando. Se ele é executado como
daemon, adicione a opção -g GRUPO no script que inicia o serviço em
/etc/init.d e reinicie o daemon. Caso ele seja iniciado via
inetd, faça a seguinte modificação no arquivo /etc/inetd.conf
(assumindo o uso do oidentd):
#:INFO: Info services
auth stream tcp nowait.40 nobody.adm /usr/sbin/oidentd oidend -q -i -t 40
Veja Servidor ident, Chapter 13 para detalhes sobre este serviço.
O sistema de quotas é usado para limitar o espaço em disco
disponível a usuários/grupo. O uso de partições independentes para o diretório
/home e outros montados separadamente não é muito eficaz porque
muitos usuários serão prejudicados se a partição for totalmente ocupada e
alguns possuem requerimentos de uso maior do que outros.
O suporte a Quotas deve estar compilado no kernel (seção FileSystems) e o sistema de arquivos deverá ser do tipo ext2 ou XFS para funcionar.
Abaixo o passo a passo para a instalação de quotas em seu sistema:
quota no sistema (apt-get install
quota).
/etc/fstab:
/dev/hda1 /boot ext2 defaults 1 1
/dev/hda3 / ext2 defaults,usrquota 1 2
/dev/hda4 /usr ext2 defaults,grpquota 1 3
/dev/hda5 /pub ext2 defaults,usrquota,grpquota 1 4
O sistema de arquivos /dev/hda1 não terá suporte a quota,
/dev/hda3 terá suporte a quotas de usuários (usrquota),
/dev/hda4 terá suporte a quotas de grupos (grpquota) e
/dev/hda5 terá suporte a ambos. Por padrão é assumido que os
arquivos de controle de quota estão localizados no ponto de montagem da
partição com os nomes quota.user e quota.group.
quota.user e
quota.group no ponto de montagem de cada partição ext2
acima que utilizará o recurso de quotas. O arquivo quota.user
controla as quotas de usuários e quota.group controla as quotas de
grupos.
quota.user em / (terá suporte
somente a quota de usuários, veja a opção de montagem no
/etc/fstab): touch /quota.user ou echo -n
>/quota.user.
quota.group em /usr (terá
suporte somente a quota de grupos): touch /usr/quota.group ou
echo -n >/usr/quota.group.
quota.user e quota.group em
/pub (este sistema de arquivos tem suporte a ambos os tipos de
quota): touch /pub/quota.user /pub/quota.group.
Por motivos de segurança, as permissões dos arquivos de controle de quota
quota.user e quota.group devem ser leitura/gravação
ao usuário root e sem permissões para grupo/outros usuários:
chmod 0600 /quota.user /quota.group.
OBS: Se deseja utilizar o quota versão 1, certifique-se que
não existem os arquivos chamados aquota.user e
aquota.group no diretório raíz de sua partição. Se eles estiverem
disponíveis, os utilitários de quota utilizarão esta versão como padrão,
atualmente o kernel 2.4 possui somente suporte a quota versão 1.
A versão 2 do quota checa corrompimento dos arquivos de dados de quota e trabalha mais rapido em partições grandes. São necessários patches da série "ac" (Alan Cox) para usar a versão 2 do quota.
Se você ativou as quotas para o sistema de arquivos / (como em
nosso exemplo) será necessário reiniciar o sistema.
/etc/fstab):
quotacheck -augv
O parâmetro -a diz para checar todas as partições com suporte a quota
no arquivo /etc/mtab, -u para checar quotas de usuários,
-g para checar grupos e -v para mostrar o progresso da
checagem da partição.
Na primeira execução é mostrado uma mensagem de erro de arquivo
quota.user/quota.group corrompido, mas isto é normal
porque o arquivo anterior tem tamanho zero. Estes nomes também servem para o
quotacheck "auto-detectar" a versão do sistema de quota
usada no sistema de arquivos.
OBS: Certamente será necessário "forçar" a
remontagem como somente leitura do sistema de arquivos / com a
opção -m para o quotacheck criar as configurações de
quota nesta partição.
/etc/mtab):
quotaon -augv
As opções possuem o mesmo significado do comando quotacheck. O
utilitário quotaoff serve para desativar quotas de usuários e usa
as mesmas opções do quotaon. Estes três utilitários somente podem
ser usados pelo usuário root. As opções de quota podem ser
especificadas independente para cada sistema de arquivos:
# Ativa o suporte a quota em /pub (somente grupos de usuários no momento).
quotaon -gv /pub
# Ativa as quotas de usuários em /pub
quotaon -uv /pub
# Desativa as quotas de grupos em /pub (deixando somente a de usuários ativa)
quotaoff -gv /pub
A atualização de quotas durante a gravação/exclusão de arquivos é feita
automaticamente. O utilitário quotacheck deverá ser executado
sempre que o sistema de quotas for desativado (por não haver atualização
automática dos dados de uso de disco) ou quando ocorrerem falhas de disco.
Na distribuição Debian o quotacheck é disparado
sempre que necessário após as situações de checagem de disco. As quotas de
todas as partições também são ativadas automaticamente pelo script
/etc/init.d/quota e /etc/init.d/quotarpc.
Em sistemas que utilizam NFS e possuem sistemas de arquivos exportados em
/etc/exports, o daemon rpc.rquotad deverá ser
carregado. Sua função é fornecer os detalhes de quota dos
sistemas de arquivos locais exportados para as máquinas clientes.
O programa edquota é usado pelo root para editar as
quotas de usuários/grupos. Por padrão, todos os usuários/grupos do sistema não
possuem quotas. Sua sintaxe é a seguinte
edquota [opções] [usuário/grupo]
As opções podem ser:
rpc.rquotad.
Quando a quota soft do usuário/grupo é estourada, a mensagem "warning: user disk quota excedeed" será exibida. Quando a quota hard é ultrapassada, a gravação atual é interrompida e a mensagem "write failed, user disk limit reatched" é mostrada ao usuário. Nenhuma nova gravação que ultrapasse a quota hard é permitida Por exemplo, para modificar a quota do usuário gleydson: edquota gleydson
Disk quotas for user gleydson (uid 1000):
Filesystem blocks soft hard inodes soft
hard
/dev/hda5 504944 500100 600000 10868 15000
20000
O editor de textos usado poderá ser modificado através da variável $EDITOR. Abaixo a explicação destes campos:
/pub.
Para desativar as restrições coloque "0" no campo soft ou
hard. Quando o limite soft é atingido, o usuário é alertado
por ter ultrapassado sua quota com a mensagem "warning: user quota
excedeed" (quota do usuário excedida). O programa setquota é
uma programa não-interativo para edição de quotas para ser usado diretamente na
linha de comando ou em shell scripts.
Após ultrapassar o limite soft, começa a contagem do tempo para que este passe a valer como limite hard (o máximo aceitável e que nunca poderá ser ultrapassado). O comando edquota -t serve para modificar estes valores na partição especificada:
Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
Filesystem Block grace period Inode grace period
/dev/hda5 2days 7days
Abaixo a explicação destes campos:
OBS1: - O comando quotacheck deverá ser executado
na partição sempre que novas restrições/limites forem editados com o
edquota. Isto atualiza os arquivos quota.user e
quota.group. Lembre-se de desativar o sistema de quotas
(quotaoff -ugv /partição) antes de executar este comando (para
liberar totalmente a partição, quotacheck remonta a partição
somente para leitura quando é executado). Por este motivo é recomendável fazer
isso em modo monousuário.
OBS2: Quando o limite soft (suave) é excedido, o sistema começará a lhe mostrar mensagens alertando a passagem do limite (para lhe dar tempo de eliminar arquivos ou não ser pego desprevenido com o bloqueio de gravação) porque o limite hard (rígido) nunca poderá ser ultrapassado.
OBS3: - O tempo de tolerância restante ao usuário/grupo quando
a quota é ultrapassada poder ser visualizada com o comando quota
(veja Verificando a quota
disponível ao usuário, Section 18.11.4).
OBS4: - Quando o usuário exclui seus arquivos e volta a ficar abaixo dos limites soft da quota, o tempo de tolerância é resetado aos valores padrões (especificados por edquota -t.
OBS5: - As quotas de espaço em disco podem ser definidas
automaticamente para os novos usuários adicionados ao sistema colocando o
espaço em disco na variável QUOTAUSER=numero do arquivo
/etc/adduser.conf. Isto será equivalente a digitar o comando
edquota -q QUOTA novo_usuário.
Editar manualmente a quota de cada usuário é uma tarefa trabalhosa quando se
está instalando quotas e possui muitos usuários, existe uma maneira mais fácil
de fazer isso usando o próprio edquota e um usuário com a quota já
definida. Por exemplo, instalamos quota em nosso sistema e queremos que todos
os 300 usuários tenham a quota de usuário de 10MB e de grupo de 15MB:
edquota (como descrito
em Editando quotas de
usuários/grupos, Section 18.11.2). Como exemplo usaremos o usuário
teste_user. Use o comando quota teste_user para
verificar se as quotas para este usuário está correta.
#!/bin/sh
cd /home
for USUARIO in *
do
edquota -u ${USUARIO} -p teste_user
done
Pronto, verifique a quota de todos os usuários com o comando repquota -a.
Execute o comando quota mostra os limites de usuários/grupos e a
tolerância restante antes do limite soft se tornar rígido. Abaixo
alguns exemplos descritivos deste comando:
quota
Disk quotas for user gleydson (uid 1234):
Filesystem blocks quota limit grace files quota limit grace
/dev/hda5 504944* 500100 600000 00:05 10868 0 0
Os campos tem o seguinte significado:
O parâmetro "none" indica que o tempo de tolerância expirou (caso existam limitações de quota que foram ultrapassadas) ou que o usuário/grupo não possui restrições. Veja se existe um "*" no campo blocks.
A quota de outros usuários/grupos podem ser visualizadas especificando as opções -u (padrão) e -g na linha de comando respectivamente. A opção -v permite visualizar quotas em sistemas de arquivos não alocados e -q mostra somente uma mensagem dizendo se o usuário está ou não dentro de sua quota:
quota -u usuario
quota -uq usuario
quota -g users
Por motivos de segurança, você não poderá visualizar as quotas de outros usuários e grupos que não pertence (exceto para o usuário root).
Quando precisamos verificar o uso de quotas de todos os usuários/grupos do
sistema o quota se torna incômodo e pouco prático. O comando
repquota lista está disponível ao administrador para facilitar
esta tarefa. Sua listagem é organizada por partições listando dados adicionais
como grace time e aceita as mesmas opções dos utilitários
quotaon e quotaoff. Primeiro são listados as
restrições de usuários e depois de grupos para a partição. (tolerância) As
opções aceitas por este utilitário tem o mesmo significado das opções do
quotaon e quotaoff:
repquota -aug
*** Report for user quotas on device /dev/hda3
Block grace time: 7days; Inode grace time: 7days
Block limits File limits
User used soft hard grace used soft hard grace
----------------------------------------------------------------------
root -- 29160 0 0 none 9970 0 0 none
daemon -- 64 0 0 22 0 0
man -- 944 0 0 65 0 0
mail -- 4960 0 0 823 0 0
news -- 4 0 0 1 0 0
gleydson -- 31032 0 0 6956 0 0
testuser -- 16 0 0 4 0 0
anotheruser -- 16 0 0 4 0 0
nobody -- 2344 0 0 2 0 0
*** Report for user quotas on device /dev/hda5
Block grace time: 2days; Inode grace time: 7days
Block limits File limits
User used soft hard grace used soft hard grace
----------------------------------------------------------------------
root -- 16052 0 0 none 6443 0 0 none
gleydson +- 4944 500100 600000 none 10868 0 0
*** Report for group quotas on device /dev/hda5
Block grace time: 7days; Inode grace time: 7days
Block limits File limits
Group used soft hard grace used soft hard grace
----------------------------------------------------------------------
root -- 20308 0 0 none 636 0 0 none
src -- 11404 0 0 660 0 0
users -- 1756 0 0 6561 0 0
gleydson -- 3452 0 0 9307 0 0
Um sinal de "+-" no segundo campo indica quota ultrapassada ou no espaço em disco, "-+' em número de arquivos e "++" em ambos. Como vimos acima, o este comando também lista o número de arquivos e bytes pertencentes a cada usuário na partição (mesmo não sendo monitorado pelas restrições de quota), isto ajuda a monitorar ações suspeitas com a excedência de espaço em disco de determinados usuários/grupos do sistema. Um exemplo é alguém que esteja fora da quota e abusando de seu usuário/grupo para uso excessivo de espaço em disco sem seu conhecimento.
OBS: Este utilitário pode ser executado por qualquer usuário no sistema e mostrar o uso de quotas de usuários/grupos que não deveria ter acesso. É recomendado deve ter permissões de leitura/gravação somente para o usuário root e sem permissões para grupo/outros usuários.
Avisos sobre quota ultrapassada podem ser enviadas automaticamente a todos os
usuários pelo utilitário warnquota. Ele poderá ser executado
periodicamente através do cron (por padrão isto é feito
diariamente na distribuição Debian pelo script
/etc/cron.daily/quota). Dados adicionais sobre o envio das
mensagens devem ser especificados no arquivo /etc/warnquota.conf
seu formato é o seguinte:
# Programa usado para enviar as mensagens
MAIL_CMD = "/usr/sbin/sendmail -t"
# Campo de origem da mensagem
FROM = "root@localhost"
# but they don't have to be:
SUBJECT = Quota excedida
CC_TO = "root@localhost"
SUPPORT = "root@localhost"
PHONE = "5555-2525"
#
O e-mail é enviado aos usuários (e usuários que pertencem a grupos com a quota excedida) com o seguinte formato:
From: root@localhost
To: gleydson@debian.gms.com.br
Cc: root@localhost
Reply-To: root@localhost
Subject: Quota Excedida
Date: Sat, 22 Sep 2001 14:27:38 -0400
Hi,
We noticed that you are in violation with the quotasystem
used on this system. We have found the following violations:
Block limits File limits
Filesystem used soft hard grace used soft hard grace
/dev/hda5 +- 504944 500100 600000 none 10868 0 0
We hope that you will cleanup before your grace period expires.
Basically, this means that the system thinks you are using more disk space
on the above partition(s) than you are allowed. If you do not delete files
and get below your quota before the grace period expires, the system will
prevent you from creating new files.
For additional assistance, please contact us at root@localhost
or via phone at 5555-2525.
Veja Shadow Passwords, Section 11.4.1.
Veja Senhas MD5, Section 11.4.2.
As restrições descritas aqui são úteis para diminuir as chances de um ataque por acesso físico ser realizado com sucesso no sistema que desejamos proteger.
Ter um sistema totalmente seguro é praticamente impossível, mas existem diversas maneiras de se dificultar as coisas.
Algumas restrições podem ser configuradas na para diminuir as chances de se obter acesso root (usando métodos conhecidos de recuperação via disquete/CD inicializável) ou simplesmente aumentar nossa confiança no sistema:
Com os dois ítens acima qualquer um ficará impedido de inicializar o sistema a partir de um disco de recuperação ou entrar no Setup para modificar a ordem de procura do sistema operacional para dar a partida via disquetes.
Como não é seguro confiar nas restrições de senha da BIOS (qualquer um com conhecimentos de hardware e acesso físico a máquina pode abrir o gabinete e dar um curto na bateria que mantém os dados na CMOS ou aterrar o pino de sinal da CMOS), a retirada da unidade de disquetes é recomendada, isso dificultará bastante as coisas.
Evite a utilização de placas de rede com recursos de boot via EPROM no servidor, um servidor dhcp/bootp/tftp poderá ser configurado sem problemas por um cracker na rede (caso a BIOS esteja com a ordem inadequada de procura de discos) e o ataque se dar com mais "sofisticação" e rapidez.
A opção passwd=senha e restricted poderão ser usadas na seção da imagem que desejamos proteger. Respectivamente pedem uma senha para a inicialização do sistema e caso argumentos como root=single sejam usados para conseguir acesso root sem fornecer senha.
E deixe somente as permissões de acesso ao usuário root (caso contrário sua senha poderá ser vista por qualquer usuário) e modifique os atributos deste arquivo para imutável para que nem mesmo o root possa modifica-lo: chattr +i /etc/lilo.conf.
O disco rígido do servidor poderá se retirado como alternativa para se ter acesso aos dados armazenados. Isto poderá ser dificultado com o uso de lacres de disco ou outras maneiras de dificultar mais esta tarefa (mais parafusos, armazenamento em partes de difícil manipulação do HD, etc) qualquer coisa que possa lhe fazer ganhar tempo e despertar suspeitas para evitar o sucesso desta alternativa (ousada).
Dados importantes ou confidenciais poderão ser armazenados em um sistema de arquivos criptografados e serem montados somente pelos administradores que possuem acesso físico ao sistema. O algoritmo Serpent é muito forte na proteção de dados além de possuir um ótimo desempenho. Patches de criptografia poderão ser aplicados no kernel para ativação deste recurso (veja Sistemas de arquivos criptográfico, Section 19.4) para detalhes.
Sensores podem ser ligados na carcaça do HD como forma de disparar um pequeno alarme embutido no gabinete do servidor, se você gosta de eletrônica poderá montar um destes facilmente para chamar a atenção alimentado por fonte/baterias em um circuito de emergência, e poderá acomodar sua caixa em uma segunda "carcaça de fonte" apenas para desviar suspeitas. Um circuito interno de câmeras também é uma boa alternativa para monitorar a movimentação.
Esquemas de segurança dependendo do porte da organização e dos dados que se desejam proteger deverão ser elaborados e postos em prática. Todos os métodos imagináveis deverão ser considerados de acordo com as possibilidades do ambiente.
Guia Foca GNU/Linux
Versão 6.10 - Sunday, 03 de November de 2002gleydson@cipsga.org.br