Servidor de Counter-Strike 1.6

 Apache2, Clusterweb, Jogos, Leitura Recomendada, Linux, Ubuntu  Comentários desativados em Servidor de Counter-Strike 1.6
jul 112014
 

Bom pra você que quer um servidor de Counter-Strike 1.6 em seu servidor dedicado ou servidor VPS, aprenda agora a montar seu próprio servidor.

 – Você deve se logar no SSH, após, digite:

Código:
mkdir /usr/games/cs
cd /usr/games/cs

 

 – Baixe os pacotes do HLDS (Half Life Dedicated Server):
wget Download

 – Aplique as permissões de execução no arquivos:

Código:
chmod +x hldsupdatetool.bin

 

 – Execute o programa:

Código:
./hldsupdatetool.bin


OBS: Se apresentar o erro “sh: line 1: uncompress: command not found“, digite o seguinte:
Continue reading »

SELinux – Segurança em Servidores GNU/Linux

 Firewall, Redes, Segurança  Comentários desativados em SELinux – Segurança em Servidores GNU/Linux
maio 302013
 
O SELinux

O Security-Enhanced LinuxSELinux – foi desenvolvido pela Agência Nacional de Segurança dos EUA (NSA). Logo no início, seu objetivo principal era tornar-se um sistema operacional capaz de fornecer controles avançados de acesso para os órgãos militares dos Estados Unidos.

Porém, com o passar do tempo, a NSA identificou que seria mais lógico aprimorar um sistema de controle de acesso obrigatório, e adicioná-los a um sistema operacional já existente.

A opção pelo GNU/Linux surgiu devida à facilidade e flexibilidade de incorporar tal framework ao Kernel do sistema. Logo depois, sistemas que traziam a plataforma Unix, também usufruíram desta tão poderosa ferramenta.

Altamente implementado e refinado em cima da arquitetura MAC (Mandatory Access Control), provendo maior segurança a arquivos, diretórios, processos, sistema de arquivos, entre outros objetos, através de regras providas pelo SELinux.

Vale ressaltar, que este nível de segurança vai além da arquitetura DAC (Discretionary Access Control) que está associada à permissão de arquivos e ACLs (Access Control List’s) do GNU/Linux, como exemplo, as permissões MAC podem ser aplicadas até ao usuário root, limitando ações do mesmo.

Em um conceito prático, imaginemos que a conta de sistema associada ao serviço HTTP foi comprometida, o SELinux através de regras pré estabelecidas, limita este comprometimento apenas ao serviço HTTP, impossibilitando o comprometimento de outros serviços, ou até mesmo, do próprio sistema operacional.

Depois deste breve conceito, vamos à prática.

Lembrando que mais informações do SELinux, podem ser obtidas na Wiki do Projeto:

Ou, na página oficial da NSA:

Modo de operação do SELinux (conceito e prática)

Basicamente, o SELinux pode operar em três tipos diferentes, que são:

  • Enforcing – As regras do SELinux estão aplicadas, e está sendo gerado Logs de todas as operações do mesmo;
  • Permissive – As regras do SELinux estão desativadas, porém, está gerando Logs de todas as operações do mesmo (útil para Troubleshoot de aplicações);
  • Disabled – As regras e os Logs do SELinux estão completamente desativados.

Obs.: Para nossos testes, estou utilizando o CentOS 6.3.

Visualizando o status do SELinux:

# sestatus

Saída do comando:

SELinux status:            enabled
SELinux mount:            /selinux
Current mode:             enforcing
Mode from config file:   enforcing
Policy version:              24
Policy from config file:   targeted

Caso se queira visualizar apenas o Current mode do SELinux, utilize o comando:

# getenforce

Saída do comando:

Enforcing

Perceba que este comando traz apenas o modo de operação do SELinux.

Para alterarmos o modo de operação temporário do SELinux (apenas Enforcing e Permissive), utilizaremos o seguinte comando:

# setenforce MODO_DE_OPERAÇÂO

Ex.:

# setenforce permissive

Logo, visualize o status do SELinux:

# sestatus

SELinux status:            enabled
SELinux mount:            /selinux
Current mode:             permissive
Mode from config file:   enforcing
Policy version:              24
Policy from config file:   targeted

Obs.: Para desabilitar, ou alterar, o ‘current mode’ do SELinux por completo, é necessário editar o arquivo de configuração do SELinux (/etc/selinux/config) e alterar a variável:

‘SELINUX=’.

* Apenas como fonte de informação:

  • Em alguns casos com o SELinux habilitado, podemos nos deparar com serviços que, por algum motivo, não estão funcionando.
  • Alguns administradores, simplesmente desativam o SELinux por completo (Modo Disabled), para resolver o “problema”.
  • Porém, para um Troubleshoot eficaz, não é necessário desativar o SELinux por completo comprometendo a segurança do sistema, e sim, deixá-lo em modo “Permissive”; com isso, as regras serão desativadas, porém, todo registro das atividades (logs) continuarão sendo armazenadas.
Contextos de segurança

Em uma explicação básica, um contexto é um valor de dado assumido pelos objetos de uma classe.

Nome, Idade e Peso, são exemplos de contextos do objeto “Pessoa”. Cor, Categoria e Modelo, são possíveis contextos do objeto “Carro”. No caso, os contextos da arquitetura DAC são: Tipo, Dono, Grupo e Outros.

Ex.:

# ls –ld /etc

Saída do comando:

drwxr-xr-x

Onde:

  • d = Diretório (Tipo)
  • rwx = Permissão para o dono do arquivo (Dono)
  • r-x = Permissão para o grupo do do arquivo (Grupo)
  • r-x = Permissão para os outros objetos do sistema (Outros)

No caso da arquitetura MAC, os contextos mudam de características, conforme: Usuário, Papel, Tipo e Nível.

Onde:

  • Usuário (user_u) – O campo usuário, indica o nome do usuário do SELinux, por exemplo, o usuário “system_u”, indica processos, arquivos de configuração e daemons do sistema.
  • Papel (role_r) – O campo papel, é uma forma de agrupar diferentes permissões a um determinado usuário (uma espécie de grupo).
  • Tipo (type_t) – O campo tipo (também conhecido como domínio), indica qual é permissão primária de determinado objeto do SELinux, essa é a primeira etapa de verificação de permissão do sistema MAC.
  • Nível (s*:c*) – O campo nível, indica em qual categoria determinado objeto se encontra, com relação à segurança. O mesmo utiliza a politica MCS/MLS (Multi-Category Security/ Multi-Level Security).

    Por exemplo, o nível s0:c0 indica um objeto Confidencial para todos os que possuírem o mesmo nível.

Na prática, com o mesmo diretório /etc:

# ls –Zd

Saída do comando:

System_u:object_r:etc_t:s0

Onde:

  • system_u =Usuário SELinux dono do objeto
  • object_r = Papel (ou papel) do SELinux
  • etc_t = Domínio (ou tipo) do SELinux
  • s0 = Nível de segurança do SELinux

Visualizando contextos MAC nos objetos do sistema

Para visualizar todos os processos que estão rodando no sistema, juntamente com os contextos do SELinux, vamos utilizar o comando abaixo:

# ps auxZ

Perceba que apenas adicionando a opção “Z” no comando ps, já é suficiente para visualizarmos os contextos de todos os processos do SELinux. Isto vale para outros comandos também, como por exemplo, o comando ls.

Vamos visualizar o contexto de um arquivo ou diretório qualquer do sistema:

# ls –Z /boot

Saída do comando:

system_u:object_r:boot_t:s0

Isso vale também para o comando id, que nos traz informações de um determinado usuário:

Ex.:

# id –Z

Saída do comando:

unconfined_u: unconfined_r: unconfined_t:s0-s0:c0.c1023ls

Perceba que neste caso, todo o contexto está definido como: unconfined_*

…Isto indica que o SELinux não terá influência alguma no objeto correspondente.

O comando Semanage

Para um bom entendimento do SELinux, é necessário explorar o mesmo por completo, o comando semanage traz uma série de opções para que isso aconteça.

Primeiro, devemos instalar o conjunto de pacotes, que traz (além de vários outros) o comando Semanage:

# yum install policycoreutils-python

Com o Semanage instalado em nossa máquina, vamos listar todos os usuários, nível de MLS/MCS e papéis (roles) do SELinux:

# semanage user –l

Onde: -l = list

Saída do comando:

    Labeling   MLS/       MLS/                         
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
git_shell_u     user       s0         s0                             git_shell_r
guest_u         user       s0         s0                             guest_r
root            user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r unconfined_r
unconfined_u    user       s0         s0-s0:c0.c1023                 system_r unconfined_r
user_u          user       s0         s0                             user_r
xguest_u        user       s0         s0                             xguest_r

Pergunta: “ual a função de cada usuário? Permissão? Acessos e etc…?

Vamos a um overview rápido e objetivo de cada um:

  • guest_u: Este perfil é usado para usuários que precisam ser rigorosamente controlados. O guest_u só pode fazer login usando o terminal. O mesmo não tem acesso a recursos de rede, programas setuid, setgid, su, sudo e interface gráfica.
  • xguest_u: Este perfil é idêntico à do ‘guest_u’. A exceção é que ‘xguest_u’, os usuários só conseguem fazer login na interface gráfica.
  • user_u: Assemelha a um usuário comum sem privilégios administrativos. Este usuário pode fazer login usando interface gráfica e terminal, tem acesso aos recursos da rede, mas não pode usar programas setuid e setgid.
  • staff_u: Este usuário é idêntico ao ‘user_u’, exceto que o ‘staff_u’ pode acessar os programas setuid e setgid. O ‘staff_u’ também pode fazer STAT em todos os processos do sistema, entre outros pequenos privilégios extras, em comparação com ‘user_u’.
  • sysadm_u: Este usuário é projetado para realizar login como root. Muito utilizado em ambientes multi nível de segurança, onde não há o objeto ‘unconfined_u’.
  • unconfined_u: O ‘unconfined_u’ é, em muitas vezes, isentos de regras do SELinux.

    Usuários reais do GNU/Linux, exceto o usuário root, não devem ser mapeados para o grupo de usuários ‘unconfined_u’. Em muitos cenários com que os usuários não são confinados, o mesmos criam um buraco na segurança do sistema operacional.

  • system_u: Este perfil de usuário do SELinux está reservado para o sistema. Os usuários do GNU/Linux não devem ser mapeado para o usuário SELinux ‘system_u’, geralmente este usuário esta atrelado a processos, configurações e daemons.

Agora que já sabemos as reais permissões dos usuários do SELiux, vamos listar todos os usuários do sistema que estão atrelados aos usuários e permissões do SELinux:

# semanage login –l

Saída do comando:

Login Name                SELinux User              MLS/MCS Range           
__default__               unconfined_u              s0-s0:c0.c1023          
root                      unconfined_u              s0-s0:c0.c1023          
system_u                  system_u                  s0-s0:c0.c1023

Apenas como fonte de conhecimento, vamos criar um usuário chamado “teste”, e referenciá-lo ao usuário “guest_u” do SELinux:

# useradd –c “Usuário Teste” –d /home/teste –m –k /etc/skel –s /bin/bash teste
# passwd teste
# semanage login –a –s guest_u teste

Onde:

  • -a = add
  • -s = selinux user

Logo, liste os logins novamente:

# semanage login –l

Login Name                SELinux User              MLS/MCS Range           
__default__               unconfined_u             s0-s0:c0.c1023          
root                      unconfined_u                 s0-s0:c0.c1023          
system_u                  system_u                  s0-s0:c0.c1023         
teste                       guest_u                      s0

Perceba que agora, o usuário “teste”, está atrelado ao usuário do SELinux “guest_u”, obtendo automaticamente as mesmas permissões do mesmo.

Tente logar na área gráfica com o usuário “teste”. Depois tente logar com o mesmo usuário, em algum terminal.

Perceba que as permissões do usuário “guest_u” do SELinux, não permitem o login na área gráfica, somente no terminal.

Agora, experimente atrelar o usuário “teste” ao usuário “xguest_u”. Neste momento, o usuário “teste” tem as devidas permissões para acessar a área gráfica.

Para remover o usuário “teste” das diretivas do SELinux, basta executar o comando:

# semanage login -d teste

Onde: -d = delete

Continuando com o comando semanage, vamos listar todos os contextos aplicados no sistema:

# semanage fcontext –l

Assim, fica muito mais fácil saber se determinado objeto ou serviço, está atrelado às politicas MAC do SELinux.

Mais informações sobre o comando semanage:

# semanage – -help

Os comandos Chcon e Restorecon

Diversas vezes, nos deparamos com problemas de permissão de contextos no SELinux, isto acontece frequentemente, ainda mais em serviços que têm uma alta rotatividade de objetos, como File Servers e FTP.

Para resolver este problema, utilizaremos o comando chcon, sua função nada mais é do que alterar contextos em objetos.

Para os nossos testes com o chcon, vamos criar um arquivo denominado “teste.txt” dentro do diretório /etc:

# touch /etc/teste.txt

Verifique os contextos deste arquivo:

# ls -Z /etc/teste.txt

Saída do comando:

-rw-r–r–. root root unconfined_u:object_r:etc_t:s0 /etc/teste.txt

Perceba que o usuário está definido como “unconfined_u”. Imagine agora, que precisamos alterar (por algum motivo qualquer) para o usuário “user_u”. Vamos utilizar o seguinte comando:

# chcon -u user_u /etc/teste.txt

Onde: -u = user

# ls -Z /etc/teste.txt

Saída do comando:

-rw-r–r–. root root user_u:object_r:etc_t:s0 /etc/teste.txt

Perceba que, agora o arquivo está com o contexto de usuário definido para “user_u”.

Caso precisamos (por algum motivo qualquer) alterar o domínio (type) deste objeto, para “tmp_t”:

# chcon -t tmp_t /etc/teste.txt

Onde: -t = type

# ls -Z /etc/teste.txt

Saída do comando:

-rw-r–r–. root root user_u:object_r:tmp_t:s0 /etc/teste.txt

Pronto, o arquivo está com seu domínio alterado, assim, todos os objetos que tem acesso ao domínio “tmp_t”, terão acesso ao arquivo /etc/teste.txt.

Em um último teste do comando chcon, imaginamos que você queira clonar o contexto de outro objeto?! O chcon também faz isso:

# chcon –reference /var /etc/teste.txt
# ls -Z /etc/teste.txt

Saída do comando:

-rw-r–r–. root root system_u:object_r:var_t:s0 /etc/teste.txt

Obs.: Caso você queira aplicar contextos recursivamente, basta inserir a opção “-R” no comando chcon.

Em muitos casos, queremos deixar o objeto de acordo com as regras do domínio (type) no qual o mesmo está armazenado. Poderíamos utilizar o chcon e copiar todos os contextos, ou utilizar um comando que faz exatamente isso. Este comando é o restorecon, vamos vê-lo em detalhes:

# restorecon -F /etc/teste.txt

Com este comando, o arquivo “teste.txt” herdará todos os contextos do diretório /etc (local onde o mesmo está armazenado). Útil, não?! =)

Os comandos chcon e restorecon, são extremamente úteis e complexos, para um maior detalhamento dos mesmos, leia a Man Page oficial:

# man chcon
# man restorecon

Variáveis booleanas

As variáveis booleanas nada mais são, do que ligar(1) ou desligar(0) determinada ação (seja temporário ou não).

Um exemplo seria, imaginamos que determinada aplicação necessita de acesso a gravação no sistema, caso não existisse as variáveis booleanas, teríamos que reescrever o código do SELinux para permitir tal ação!

As mesmas são extremamente úteis para qualquer um que queira administrar o SELinux.

Para uma prática eficiente com as variáveis booleanas, é só lembrar dos termos 0 e 1, ou para ficar mais fácil: nã0 e s1m. =)

Vamos à mais um case!

Vamos instalar um serviço de FTP (apenas de exemplo), e gerenciar as variáveis booleanas:

# yum install vsftpd

E, adicionar aos níveis de execução:

# chkconfig –level 2345 vsftpd on

Agora, vamos reiniciar o serviço:

# service vsftpd restart

Agora que já temos o serviço devidamente instalado, vamos gerenciar as variáveis booleanas.

Primeiro, vamos listá-las:

# getsebool -a

Onde: -a = all

– Pergunta: Apenas com o nome das variáveis, fica difícil saber para que cada uma serve?
– Resposta: Para um maior detalhamento, vamos utilizar o semanage novamente:

# semanage boolean -l

Onde: -l = list

Perceba que agora, temos os nomes das variáveis, e também uma breve descrição de cada uma delas.

Vamos filtrar as variáveis para tudo que atrela-se ao serviço FTP:

# semanage boolean -l | grep ftp

Saída do comando:

ftp_home_dir                   (off  ,  off)  Allow ftp to read and write files in the user home directories
tftp_anon_write                (off  ,  off)  Allow tftp to modify public files used for public file transfer services.
allow_ftpd_full_access         (off  ,  off)  Allow ftp servers to login to local users and read/write all files on the system, governed by DAC.
allow_ftpd_use_cifs            (off  ,  off)  Allow ftp servers to use cifs used for public file transfer services.
allow_ftpd_use_nfs             (off  ,  off)  Allow ftp servers to use nfs used for public file transfer services.
allow_ftpd_anon_write          (off  ,  off)  Allow ftp servers to upload files,  used for public file transfer services. Directories must be labeled public_content_rw_t.
ftpd_use_passive_mode          (off  ,  off)  Allow ftp servers to use bind to all unreserved ports for passive mode
ftpd_connect_db                (off  ,  off)  Allow ftp servers to use connect to mysql database
httpd_enable_ftp_server        (off  ,  off)  Allow httpd to act as a FTP server by listening on the ftp port.

Por padrão, o serviço VSFTPD não permite o total gerenciamento de arquivos para o usuário anonymous, isso devido às restrições do SELinux!

Caso você queira dar tal permissão para o usuário anonymous (ou outros usuários), basta setar a variável: allow_ftpd_full_access

Com ela é possível dar controle total a qualquer usuário que conecte no FTP (lembrando que esse é apenas mais um teste).

– Pergunta: E como fazer isso?
– Resposta: Simples, utilizaremos o comando setsebool.

# setsebool -P allow_ftpd_full_access 1

Onde:

  • -P = Indica que será aplicada á alteração permanente, sem a opção ‘-P’ no próximo reboot, tudo será restaurado para o seu padrão!
  • 1 = Ativa a variável (lembre-se: s1m e nã0)

Pronto! Seu servidor FTP está dando controle total para qualquer usuário. Feliz agora?!

Bom, eu não ficaria, pois estamos abrindo um furo na segurança do sistema. Portanto, vamos desativar a variável booleana correspondente:

# setsebool -P allow_ftpd_full_access 0

Onde: 0 = Desativar a variável.

Lembre-se: As variáveis booleanas são extremamente importantes para a boa administração do SELinux, liste e teste cada uma delas, assim tudo ficara mais fácil. 😉

O comando Semodule

Assim, como o próprio sistema GNU/Linux, o SELinux opera em formato modular, ou seja, caso precise adicionar exceções, ou aprimoramento, de regras no SELinux para determinadas aplicações, como por exemplo um MTA, ou um servidor Web, não será necessária a recompilação do próprio sistema SELinux.

E sim, adicionar um código externo (módulo) que indique tal ação. Este módulo pode ser fornecido tanto pela equipe que administra a aplicação, quanto construída pelo próprio administrador do SELinux.

Obs.: Não confunda os módulos do SELinux com as variáveis booleanas. Os módulos são funções acrescentadas nas regras de determinada aplicação, já as variáveis booleanas, são permissões referentes à comunicação entre aplicação e objetos do sistema.

O comando que gerencia tais módulos no SELinux, é o Semodule, e sua utilização é muito simples.

Para listar os módulos do SELinux:

# semodule -l

Onde: -l = list

Saída do comando (resumida):

abrt    1.2.0
accountsd       1.0.0
ada     1.4.0
afs     1.5.3
aiccu   1.0.0
aide    1.5.0
aisexec 1.0.0
amanda  1.12.0
amavis  1.10.3
amtu    1.2.0
apache  2.1.2
apcupsd 1.6.1
arpwatch        1.8.1
asterisk        1.7.1
audioentropy    1.6.0
automount       1.12.

Caso precisemos desabilitar determinado módulo, como por exemplo, o módulo do Asterisk, utilizaremos a seguinte sintaxe do comando semodule:

# semodule -d asterisk

Onde: -d = disable

Agora, vamos listar os módulos, filtrando apenas o módulo do Asterisk:

# semodule -l | grep asterisk

Saída do comando:

asterisk       1.7.1   Disabled

Perceba que este módulo está presente, porém sem qualquer funcionalidade.

Para remover o módulo por completo, utilize o comando:

# semodule -r asterisk

Onde: -r = remove

# semodule -l

Listando novamente os módulos, perceba que o mesmo não se encontra mais na listagem.

– Pergunta: E se eu precisar do módulo do Asterisk novamente, o que eu faço?
– Resposta: Por padrão, os arquivos de módulo do SELinux terminam com extensão “.pp” (Package Policy), portanto, para instalar um módulo no sistema SELinux, é necessário ter tal arquivo em mãos.

Simples, não?! Agora basta achar tal arquivo “.pp” do Asterisk.

Por padrão, o diretório /usr/share/selinux/targeted/ contém diversos arquivos de pacotes de políticas (*.pp).

Estes arquivos estão inclusos no pacote “selinux-policy”, e são utilizados para construir o arquivo de política.

Em diversas distribuições, como o CentOS e Red Hat, tais arquivos podem estar compactados, porém, a descompactação não se faz necessária para instalação.

Como estamos trabalhando com módulos defaults, o arquivo “.pp” do Asterisk está armazenado neste diretório, portanto, vamos reativá-lo:

# cd /usr/share/selinux/targeted/ # semodule -i asterisk.pp.bz2

Onde: -i = Install

# semodule -l | grep asterisk

Perceba que não precisamos habilitar o módulo novamente, apenas com a instalação do mesmo, ele já fica em modo enable.

Caso o módulo não fique em modo enable, basta executar o comando semodule com a opção “-e”, seguida do nome do módulo, no nosso caso, seria o “asterisk”.

Para mais opções do comando semodule, basta executar:

# man semodule

Auditoria e logs

Com relação à auditoria e depuração de Logs, o SELinux lida muito bem com isso, a começar pelo pacote Setroubleshoot, a junção de diversos aplicativos é uma “Mãe” para qualquer administrador SELinux. A ferramenta demonstra os alertas de AVC do SELinux, e ainda diz qual comando pode corrigir o mesmo.

Falando em AVC, sigla para Access Vector Cache (e não para Acidente Vascular Cerebral), que nada mais é do que alertas de acessos bloqueados sejam elas de aplicação ou usuários do sistema.

Primeiramente, vamos instalar o pacote “Setroubleshoot”.

Obs.: Caso tenha interface gráfica no servidor, o mesmo irá instalar um pequeno utilitário, que alerta toda vez que um AVC acontecer.

# yum install setroubleshoot

Antes de qualquer coisa, vamos gerar o nosso próprio AVC.

– Pergunta: Mas como assim, o nosso próprio AVC?
– Resposta: Bom, esta é uma tarefa fácil, uma simples alteração de porta padrão de um determinado serviço, como o HTTP, por exemplo, deve gerar um Alerta de Access Denied.

Vamos aos testes:

Instale o serviço HTTP no Servidor:

# yum install –y httpd

Abra o arquivo de configuração:

# vim /etc/httpd/conf/httpd.conf Altere a seguinte linha do arquivo: Listen 80

Para:

Listen 8888

Logo, reinicie o serviço HTTP:

# service httpd restart

Pronto, nosso AVC foi gerado com êxito. =)

O primeiro comando para verificação de AVC’s, é o ausearch:

# ausearch –m avc | grep httpd

Onde: -m = message

Saída do comando (resumida):

type=AVC msg=audit(1344678620.633:26191): avc: denied { name_bind } for pid=9429 comm=”httpd” src=8888 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0
tclass=tcp_socket

Perceba que a saída do comando demonstra claramente, o motivo dele ter alarmado tal AVC.

– Pergunta: (Bruno, beleza!) Eu “já sei” o que aconteceu pela saída do log, mas agora eu quero que a porta 8888 seja padrão do serviço HTTP, irá continuar gerando AVC’s?
– Resposta: Não, não, porém para que isso aconteça, é necessário informar ao SELinux, que a porta padrão do serviço HTTP mudou.

Existem duas maneiras de se fazer isso, uma é utilizar o comando semanage com a opção “port”, a outra é o que iremos ver abaixo.

Primeiro, vamos utilizar o comando selatert para analisar os logs:

# sealert –a /var/log/audit/audit.log | grep httpd

Onde:

  • -a = Analyze File
  • /var/log/audit/audit.log = O arquivo que será analisado

Saída do comando (resumida):

SELinux is preventing /usr/sbin/httpd from name_bind access on the tcp_socket.
If you want to allow /usr/sbin/httpd to bind to network port 8888
where PORT_TYPE is one of the following: ntop_port_t, http_cache_port_t, http_port_t, puppet_port_t, jboss_messaging_port_t, jboss_management_port_t.
If you believe that httpd should be allowed name_bind access on the tcp_socket by default.
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol

Analisando a saída, perceba que além de detalhar a possível causa do AVC, ele sugere (caso você realmente queira), indicar a alteração de porta padrão do serviço HTTPD para 8888 ao SELinux.

Vamos utilizar o comando que ele sugeriu:

# grep httpd /var/log/audit/audit.log | audit2allow -M mypol

Onde:

  • grep httpd /var/log/audit/audit.log = Indica que iremos filtrar a palavra httpd, mediante o arquivo de logs.
  • audit2allow = Utilizado para Gerar políticas do SELinux para permitir regras, a partir de logs negados.
  • -M = Cria um arquivo de Módulo, com a saída do audit2allow
  • mypol = Nome do arquivo de Módulo, podendo ter qualquer nome.

Saída do comando:

******************** IMPORTANT ***********************
To make this policy package active, execute:
semodule -i mypol.pp

Perceba que a saída do comando deixa bem claro que, caso você queira tornar tal módulo ativo, é necessário que você o instale via semodule.

Porém, caso você liste o diretório corrente, irá perceber que existem 2 arquivos mypol:

# ls

Saída do comando:

mypol.te mypol.pp

O arquivo “mypol.te” indica um tipo de arquivo de execução (Type Enforcement), ou seja, ele tem toda instrução do que será executado/alterado no sistema através do arquivo “mypol.pp”.

Já o arquivo “mypol.pp”, nada mais é o que o pacote de politicas (Package Policy), ou o módulo propriamente dito.

Agora que sabemos qual arquivo instalar, vamos utilizar o semodule para isso:

# semodule -i mypol.pp

Depois de alguns segundos, o arquivo foi instalado com êxito. Será?

Liste os módulos, e veja você mesmo:

# semodule –l | grep ^m

Saída do comando:

mailman 1.7.2
matahari    1.0.0
mediawiki   1.0.0
memcached   1.1.2
milter  1.1.1
modemmanager    1.0.1
mono    1.6.1
mozilla 2.1.1
mpd 1.0.0
mplayer 2.1.0
mrtg    1.8.0
munin   1.7.0
mypol   1.0
mysql   1.11.3

Olha só, o nosso modulo “mypol” instalado e habilitado no sistema. Ou seja, funcionou! =D

Vale reforçar que, a criação de módulos com o “audit2allow”, só é aconselhada caso você saiba realmente o que esteja fazendo, utilizar o “audit2allow” apenas para resolver os alertas de AVC do SELinux, estará causando um grande furo de segurança ao sistema.

Bom galera, é isso.

O artigo foi básico, em relação à complexidade do SELinux, porém, espero que tenha sido útil para aqueles que estão começando com esta tão poderosa ferramenta.

Meu muito obrigado, e até a próxima! =D

Metasploit – Instalação e utilização em ambiente GNU/Linux

 Clusterweb, Firewall, Linux, Redes  Comentários desativados em Metasploit – Instalação e utilização em ambiente GNU/Linux
mar 082013
 
Instalando

1. Visite a seguinte página e baixe a versão de instalação para GNU/Linux 32 ou 64 bits:

Salve o arquivo de instalação em uma pasta qualquer. Nesse tutorial será a pasta “Documentos”.

2. Abra o terminal como administrador.

3. Utilize o comando chmod +x para dar poder de execução ao arquivo baixado. Exemplo:

# chmod +x /home/pedro/Documentos/metasploit-latest-linux-installer.run

4. Execute o arquivo com:

# ./metasploit-lateset-linux-installer.run

5. Clique em “Avançar” para começar a instalação.

6. Marque: “I accept the agreement” → Clique em: “Avançar”.

7. Caso queira mudar a pasta de instalação ou clique em: “Avançar”.

8. Nesta etapa pode-se escolher registrar ou não no serviço. Neste caso escolheremos: “Yes”.

9. Deixe a porta default. Clique em: “Avançar”.

10. Escolha um nome para o servidor e clique em: “Avançar”.

11. Clique em “Avançar” para instalar.

12. Marque: “Access Metasploit Web UI” → Clique: “Finish”.

13. Aguarde cerca de 5 minutos e aparecerá essa tela para criação de login.

14. Após criado o login, clique em “GET PRODUCT KEY”, para obter a chave do Metasploit.

15. Selecione: “GET COMUNITY EDITION”.

16. Preencha o formulário e clique em: “Submit”.

17. A chave será mandada para o e-mail cadastrado, copie e cole ela, depois clique em: “ACTIVATE LICENSE”.

18. Pronto, o Metasploit está instalado e ativado.

19. Esta interface WEB é uma das interfaces que o Metasploit fornece para o usuário. Porém, utilizaremos o console do Metasploit chamado Msfconsole.

Para executar, digite no terminal: msfconsole

É aconselhável utilizar o Msfconsole em modo root.

Definições / Metasploitable / Msfconsole

Definições básicas

Antes de utilizarmos o Metasploit é importante conhecermos alguns conceitos:

  • Vulnerabilidade: falha de segurança em um software, hardware ou sistema operacional que fornece uma fonte potencial de ataque para um sistema;
  • Exploit: módulo especializado em tirar vantagem de uma vulnerabilidade específica de um sistema e prover acesso ao mesmo;
  • Payload: módulo que possibilita executar ações em um sistema após o mesmo ter sido acessado por um exploit. Podemos imaginar um exploit como um intruso que carrega um payload em sua mochila. Após invadir o sistema, o exploit libera o payload para este realizar sua tarefa.

Metasploitable

A equipe do Metasploit fornece uma máquina virtual Ubuntu para testes, chamada Metasploitable e que, intencionalmente, possui diversas vulnerabilidades.

Faça o download da Metasploitable e execute-a em algum software de virtualização, tal como VirtualBox ou VMware.

Msfconsole

É possível utilizar o Metasploit através de várias interfaces, como a interface WEB utilizada na instalação ou através de linhas de comando.

Neste tutorial, estaremos utilizando o Msfconsole, que fornece um interface com o framework do Metasploit baseada em console. O Msfconsole oferece recursos que tornam mais fácil o seu uso, tais como a auto-complementação de comandos (utilizando TAB) e a possibilidade de se usar comandos externos (nmap, por exemplo).

Para utilizar o Msfconsole, basta digitar o comando no terminal:

# msfconsole

Linux: Metasploit - Instalação e utilização em ambiente GNU/Linux

No Metasploit temos a ideia de módulos. Um módulo no Msfconsole é acessado por seu caminho completo em uma árvore de diretórios. Os módulos estão agrupados de acordo com suas características, como por exemplo, o seu tipo (exploit, payload, auxiliary, encoder, nop), sistema operacional, software vulnerável, etc.

Por exemplo, um caminho para um exploit na maioria dos casos segue este padrão:

exploit/sistema_operacional/tipo_do_serviço/ nome_do_módulo

Esse tipo de organização adicionada do sistema de auto-complementação facilita muito a pesquisa por um módulo.

Comandos

A seguir estão alguns comandos básicos do Msfconsole:

use < módulo >

Este comando é utilizado sempre que queremos executar um módulo.

back

Usado para “sair” de um módulo.

search < valor >

Comando utilizado para pesquisar um módulo. É possível utilizar filtros de pesquisa, especificando o filtro como parâmetro e o valor procurado.

Por exemplo, digitando:

search plataform:windows

Serão mostrados apenas módulos aplicáveis à plataforma Windows.

show < valor >

Mostra uma lista de módulos de acordo com o valor passado. Utilizado frequentemente dentro de um módulo (após o comando use), pois exibe somente os módulos “compatíveis” com o módulo utilizado no momento (principalmente no caso de estar se usando um exploit e procurando por um payload).

Dentro de um módulo é possível também listar outras coisas além de módulos, como a configuração do módulo em questão ou os sistemas alvo disponíveis.

set < parâmetro > < Valor >

Utilizado para configurar os parâmetros de execução de um módulo.

*info < módulo >

Utilizado para exibir os detalhes de um módulo. Estando dentro de um módulo (após o comando use) não há a necessidade do parâmetro “< módulo >” para exibir as suas informações.

Existem diversos outros comandos disponíveis que podem ser visualizados com o comando help. Para saber mais sobre o uso de um comando específico, basta digitar:

< comando > -h

Explorando sistemas vulneráveis

Para explorar as vulnerabilidades de um sistema, precisamos descobrir as portas que nele estão abertas e as aplicações que as utilizam. Podemos fazer isso de duas formas: utilizando o comando nmap ou módulos do próprio Metasploit.

Utilizando o nmap, digite no console:

nmap -sV -O < ip_alvo >

Os parâmetros “-sV -O” são utilizados para recuperar a versão do serviço que está utilizando uma porta e o sistema operacional alvo, respectivamente.

Utilizando módulos do Metasploit, devemos pesquisar por algum que realiza a verificação de portas abertas. Digite no console:

search scanner/portscan

Após escolher o tipo de scanner, basta utilizar o comando use passando o caminho do módulo como parâmetro. Exemplo:

use auxiliary/scanner/portscan/tcp

Os parâmetros que um módulo utiliza são configuráveis, e alguns obrigatórios para a sua execução. Para verificar os parâmetros do módulo digite:

show options

Para configurar uma parâmetro, devemos digitar:

set < nome_do_paramentro > < valor >

Na coluna “Required”, observamos os parâmetros que o módulo necessita que estejam configurados para executar. Neste caso, por exemplo, devemos atribuir o endereço IP do sistema alvo ao parâmetro RHOSTS. Por exemplo:

set rhosts 192.168.0.1

Uma vez configurado o módulo, digite o seguinte para executá-lo:

run

Como visto, ambas as abordagens exibem uma lista com as portas abertas no sistema alvo. A vantagem de se utilizar o nmap é que podemos obter informações mais detalhadas sobre as portas e sobre o sistema alvo, assim como configurar o modo sobre como a varredura será feita.

A lista das portas encontradas é o que devemos utilizar como guia para os próximos passos. Uma vez descoberto um serviço, a porta que ele utiliza e o sistema operacional do alvo, é hora de utilizar os comandos do Msfconsole para pesquisar exploits e payloads, que estão relacionados com aquele serviço e sistema operacional.

O primeiro passo: pesquisar um exploit. Como sabemos o serviço que utiliza determinada porta, podemos utilizar essa informação para refinar a nossa busca.

Por exemplo, podemos utilizar o comando search com a seguinte configuração:

search type:exploit name:mysql

Neste caso, serão retornados somente exploits que estão relacionados com o MySQL.

* Lembrando que o comando: info < módulo > pode ser utilizado para ver os detalhes de um módulo.

Uma vez escolhido o exploit, é hora de configurá-lo. Com o comando show options, será exibida uma lista contendo informações sobre os parâmetros utilizados pelo exploit.

Aqueles parâmetros que na coluna Required possuírem o valor “yes”, devem obrigatoriamente possuir um valor na coluna “Current Setting” para que o módulo seja executado.

Para configurar um parâmetro, utilize o comando:

set < parametro > < valor >

Como dito anteriormente, o exploit faz o trabalho de invasão do sistema através de uma aplicação com vulnerabilidades. E após a invasão ele executa o payload para realizar alguma ação naquele sistema.

Para configurar um payload para o exploit, digite o comando:

show payloads

Como estamos dentro de um exploit, será retornada uma lista contendo apenas os payloads compatíveis com o exploit em questão.

Para utilizar um payload, digite o comando:

set payload < payload >

É preciso verificar novamente com o comando show options se os parâmetros do payload estão corretamente configurados.

Caso nenhum payload seja configurado, após a invasão do exploit, o console funcionará como um terminal no sistema invadido.

Após terminada a configuração, basta digitar o comando exploit para executar o exploit:

Explorando uma vulnerabilidade no Android

Iremos agora explorar uma vulnerabilidade no sistema Android. Nesse teste estamos utilizando um aparelho com a versão 2.3 do sistema.

O primeiro passo é pesquisar um exploit para o Android:

search android

Se executarmos o comando:

info auxiliary/gather/android_htmlfileprovider

Veremos que, com esse exploit, é possível extrair arquivos do dispositivo a partir de uma conexão do browser do aparelho com a nossa máquina. O browser deve acessar um link no seguinte formato:

http://ip_da_maquina_local  (No meu caso: http://192.168.0.102/)

Ao acessar o link o browser fará o download de um arquivo enviado pelo exploit e, quando o arquivo for aberto, será exibido no console o conteúdo dos arquivos que extraímos do dispositivo.

Vamos então usá-lo:

use auxiliary/gather/android_htmlfileprovider

Se digitarmos:

show options

Veremos as configurações do exploit. Os seguintes parâmetros devem ser configurados (set < parametros > < valor >):

  • SRVHOST :: IP da máquina local
  • SRVPORT :: 80
  • FILES :: Já estão pré-configurados alguns arquivos que serão extraídos, mas nada impede que configuremos outros arquivos.

Agora basta executar o exploit com o comando:

exploit

Ao acessar o link no dispositivo Android, faremos o download de um arquivo HTML enviado pelo exploit. No Msfconsole veremos então o conteúdo dos arquivos que foram extraídos do dispositivo:

Conclusão

Com o Metasploit, podemos explorar vulnerabilidades em vários tipos de sistemas. Independente do tipo a sequência de passos, na maioria das vezes, obedece um padrão.

Quando não se tem ideia da configuração ou da existência de uma máquina alvo em uma rede, deve-se fazer a varredura de uma faixa de IPs utilizando comandos do GNU/Linux ou módulos do próprio Metasploit.

Quando se conhece o IP do sistema alvo e suas respectivas portas e serviços associados a estas, basta utilizar o comando search do Metasploit para encontrar módulos específicos para aquele sistema e serviço.

Módulos novos surgem constantemente no Metaspoit, logo, é aconselhável atualizar a ferramenta periodicamente (digite msfupdate em um terminal).

É possível também, desenvolver nossos próprios módulos. Procuraremos abordar esta parte de desenvolvimento de módulos em artigos futuros.

Para maiores informações a respeito do Metasploit, acessem o site:

E a comunidade oficial: