Todavia, algumas surpresas sempre ocorrem nessas mudanças de versão. Uma delas, para quem utilizar a versão “minimal” para instalação, e a ausência do comando “iptables”:

iptables: command not found

Para resolver isso, basta instalar ele usando o dnf:

# dnf install iptables

Você pode conferir esse e outros comandos no CommandFound.com:
https://commandfound.com/post/ifconfig-command-not-found-almalinux/

The post Comando iptables no CentOS 8 appeared first on Blog do Gesiel Bernardes.

GuardianKey é um sistema que utiliza IA (Inteligência Artificial) para prover mais segurança em operações de “login”. Ele utiliza dados contextuais, dados de threat intelligence, entre outros, para verificar se o usuário é quem diz ser. Ou seja: Mesmo que o usuário tenha a senha comprometida, o sistema analisará se o perfil de quem está acessando coincide com o padrão utilizado, caso não ele pode enviar alerta para o usuário/administrador ou até bloquear o acesso.

Aqui no blog já postei sobre o plugin para Zabbix. Recentemente, eles lançaram plugin para esse tipo de análise para o serviço de SSH. Basta instalar o pacote (via yum ou apt), fazer o registro, colocar as informações de registro no arquivo de configuração (/etc/guardiankey/gk.conf), iniciar o serviço e pronto, o serviço já estará funcional.

Saiba mais nos links abaixo:

• Página do GuardianKey
• Página do Plugin SSH
• Plugin SSH do GuardianKey no Github

The post Plugin GuardianKey para SSH appeared first on Blog do Gesiel Bernardes.

Na instalação padrão do Debian, o pacote “net-tools” não vem instalado. Ao tentar executar o comando ifconfig, temos o retorno de “comando não encontrado”:

# ifconfig
-bash: ifconfig: command not found

Como Resolver – ‘ifconfig’ no Debian 9

Para utilizar este comando, é necessário instalar o pacote “net-tools”:

# apt-get update
# apt-get install net-tools

Caso precise configurar a Interface antes de instalar o pacote, você pode utilizar o comando “ip addr”:

Ver status das Interfaces:
# ip addr show

Adicionar o IP  10.0.0.10 á interface ens192;
# ip addr add 10.0.0.10/8 dev ens192

Você pode utilizar o comando “ip route” para adicionar o gateway:

# ip route add default via 10.0.0.1 dev ens192

Por fim, não se esqueça de configurar o DNS:
# echo “nameserver 8.8.8.8” >> /etc/resolv.conf

Referências

• ifconfig centos 7
• https://packages.debian.org/stretch/net-tools
• https://commandfound.com/post/ifconfig-command-not-found-debian

The post Comando ‘ifconfig’ no Debian 9 appeared first on Blog do Gesiel Bernardes.

O GuardianKey é um serviço que protege a autenticação do sistema (nesse caso o Zabbix) usando técnicas de Machine Learning, e incrementa recursos valiosos contra acessos não autorizados. Farei um post mais detalhado sobre ele futuramente. Nessa implementação irei abordar a utilização do GuardianKey Security Auth Lite, que é gratuito até 10 usuários. Mais detalhes em: https://guardiankey.io/pt-br/services/guardiankey-auth-security-lite/ .

Instalação do Plugin

Basta fazer o download do plugin, e executa-lo na pasta de arquivos frontend do Zabbix (normalmente /usr/share/zabbix):

# cd /usr/share/zabbix
# wget https://raw.githubusercontent.com/pauloangelo/guardiankey-plugin-zabbix/master/install.sh

# sh install.sh

Por fim, você deve logar no painel do GuardianKey para configurar: Envio de e-mails, notificar os usuários, etc. Você pode ter informações detalhadas do painel do GuardianKey no link:
https://guardiankey.io/pt-br/documentation/panel-documentation/

The post Integrando o Zabbix com o GuardianKey appeared first on Blog do Gesiel Bernardes.

Pré-requisitos:

# yum install httpd epel-release git wget

Instalação do ModSecurity

# yum install mod_security mod_evasive

Instalação das regras:

# cd /etc/httpd/modsecurity.d
# rm -rf activated_rules/
#  git clone https://github.com/SpiderLabs/owasp-modsecurity-crs .
# mv crs-setup.conf.example crs-setup.conf
# vi /etc/httpd/conf.d/mod_security.conf
Altere a linha 4 para:
IncludeOptional modsecurity.d/rules/*.conf

# vi /etc/httpd/modsecurity.d/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf
Comente (coloque # no inicio da linha) da linha 37 (SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/…) até a linha 64( setvar:tx.%{rule.id}…), e depois comente da linha 751 até a 779.

# vi /etc/httpd/modsecurity.d/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
Comente da linha 43 até a 68

Reinicie o Apache:
# systemctl restart httpd

Observação: A configuração padrão vem com o nível “paranoico” 1, ou seja, irá fornecer uma proteção básica porém irá gerar muito pouco ou quase nenhum falso positivo. Em minha opinião, o nível “paranoico” 2 tem uma relação custo-benefício melhor, uma vez que oferece um nível maior de proteção com uma quantidade aceitável de falso positivo. Para alterar para o nível paranoico 2, faça a seguinte alteração:

# vi /etc/httpd/modsecurity.d/crs-setup.conf
(linha 171)
SecAction \
“id:900000,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.paranoia_level=2”

Agora reinicie o serviço:
# systemctl restart httpd

The post Instalando ModSecurity no CentOS 7 (com Apache) appeared first on Blog do Gesiel Bernardes.

Instalação no CentOS 7:

# yum install wget vim perl-libwww-perl.noarch perl-Time-HiRes
# cd /usr/src/
# wget https://download.configserver.com/csf.tgz
# tar -xzf csf.tgz
# cd csf
# sh install.sh

Testando a instalação:
# cd /usr/local/csf/bin/
# perl csftest.pl
Resultado esperado:
{…}
RESULT: csf should function on this server

Configurando o CSF

# vi /etc/csf/csf.conf
TESTING = “0”

# systemctl start csf
# systemctl start lfd
# systemctl enable csf
# systemctl enable lfd

Você pode listar as regras digitando:
# csf -l

The post Instalando Config Server Firewall (CSF) no Centos 7 appeared first on Blog do Gesiel Bernardes.

1. Faça o download do agente de acordo com sua arquitetura:
   x86:  https://support.zabbix.com/secure/attachment/40104/Zabbix-3.0.1-with-OpenSSL-1.0.2c-x86.zip
   x64: https://support.zabbix.com/secure/attachment/40105/Zabbix-3.0.1-with-OpenSSL-1.0.2f-x64.zip
2. Extraia o arquivo na pasta que deseja a instalação (ex: C:\zabbix)
3. Crie o arquivo de configuração (ex: c:\zabbix\zabbix_agentd.conf), e adicione na configuração as opções relacionadas a criptografia (PSK ou Certificados). Você pode conferir neste post as configurações de criptografia do Agente, e nesta página você encontra todas as opções de configuração do Agente.
4. Instale o serviço do Zabbix. Neste exemplo, minha instalação está na pasta C:\zabbix:
   Abra o cmd (como Administrador) e digite:
   C:\zabbix\zabbix_agentd -i -c “C:\zabbix\zabbix_agentd.conf”

E pronto! A instalação com suporte a TLS está feita….

The post Configurando Criptografia do Zabbix no Windows appeared first on Blog do Gesiel Bernardes.

Um item que deve ser levado em consideração é em relação ao desempenho da comunicação, que cai bastante com o uso da criptografia. Segundo o manual do Zabbix uma consulta que em texto plano demora 200ms para ter resposta pode chegar a 1000ms com o uso da criptografia. Isso pode causar timeout em alguns itens e scripts, que devem ser ajustados para evitar problemas.

O Zabbix permite o uso de chaves pré compartilhadas (PSK) ou Certificados digitais para realizar a criptografia. Ambas possuem vantagens e desvantagens. Iremos realizar a configuração dos dois métodos:

• Criptografia no Zabbix utilizando Chaves Pré-Compartilhadas
• Criptografia no Zabbix utilizando Certificados Digitais

Para o uso da criptografia no Zabbix deve-se habilitar esse recurso ao compila-lo (ex: ./configure […] –with-gnutls). Segundo a documentação, os pacotes pré-compilados (RPM e Deb) possuem criptografia habilitada.

Criptografia no Zabbix utilizando Chaves Pré-Compartilhadas (PSK)

Vantagens:

• Implementação mais simples
• Desempenho melhor, comparado ao uso de Certificados Digitais

Desvantagem:

• As chaves são mostradas na interface web e armazenadas em texto limpo no banco de dados

Configuração:
Servidor: Não é necessária nenhuma configuração adicional

Agente:

Gerar a chave:
# openssl rand -hex 32 > /home/zabbix/zabbix-agent.psk
(abra o arquivo e copie a chave, será necessário para configurar na interface web)

Alterar os seguintes itens no zabbix_agentd.conf:

TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=PSK01 #Esse item é a identificação da chave; cada chave deve ter sua identificação.
TLSPSKFile=/home/zabbix/zabbix_agentd.psk

Configuração na Interface Web:

Na configuração do Host, vá em “Encryption”, selecione “PSK” e configure os itens de acordo com sua configuração:

Inicie o agente, se estiver tudo correto irá funcionar:

Criptografia no Zabbix utilizando Certificados Digitais

Vantagens:

• Implementação “teoricamente” mais robusta
• Autenticação do Agente/Proxy (controverso)
• Possibilidade de uso de CA para gerenciamento de Certificados Digitais

Desvantagens:

• Desempenho inferior
• Implementação mais complexa

Talvez eu esteja errado, mas me parece que a implementação da criptografia com Certificados Digitais do Zabbix foi aplicada exclusivamente para prover confidencialidade, e foi perdida a oportunidade de utilizar os Certificados para prover a Autenticidade do Host. Isso porque:

1. Você tem que especificar quem assinou o Certificado de cada Host. Isso faz com que não seja necessário que os Certificados sejam assinados por uma mesma CA (Certificate Authority). Seria melhor se você obrigatoriamente tivesse que utilizar a mesma CA que assinou o certificado do Servidor, traria uma confiabilidade maior, além tornar desnecessário o preenchimento do campo “issuer” na interface Web.
2. A verificação  do Certificado/CA é baseada apenas no “Subject” do Certificado. Nada impede de um suposto atacante de criar um outro certificado com outra chave privada e utilizar o mesmo “Subject”. Me parece que o correto seria utilizar o hash do certificado, para confirmar a autenticidade do mesmo.

Configuração:

Criando a CA e assinando certificado do Servidor:
Para esse exemplo irei criar uma CA no Servidor do Zabbix (estou utliizando CentOS 7), e irei utiliza-la para assinar o Certificado do agente.

# cd /etc/pki/CA
# openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 3650
(Ele irá pedir uma senha para criação da chave, além de atributos do certificado. Preencha todos os campos, para evitar problemas posteriormente.)
# touch /etc/pki/CA/index.txt
# echo “01” > /etc/pki/CA/serial
# mkdir /etc/zabbix/certs
# cd /etc/zabbix/certs
# openssl genrsa -out chave.key 2048
# openssl req -new -key chave.key -out requisicao.csr
(preencha os dados da requisição. O campo “common name” deve ser o nome da máquina)
# openssl ca -in requisicao.csr
(a senha que ele solicita é a senha da chave da CA)

Copie o conteúdo do certificado (começa em —–BEGIN CERTIFICATE e vai até —–END CERTIFICATE – incluindo estas linhas) e cole em /etc/zabbix/certs/server.pem.

Configurando o Zabbix Server

Edite no arquivo zabbix_server.conf:

TLSCAFile=/etc/pki/CA/cacert.pem
TLSCertFile=/etc/zabbix/certs/server.pem
TLSKeyFile=/etc/zabbix/certs/chave.key

Configurando o Agente:

Gerar o certificado:
# mkdir /etc/zabbix/certs
# cd /etc/zabbix/certs
# openssl genrsa -out chave.key 2048
# openssl req -new -key chave.key -out requisicao.csr

Copie o arquivo requisicao.csr para o servidor (por exemplo, na pasta /tmp). Em seguida, execute no servidor:
# openssl ca -in /tmp/requisicao.csr
(digite a senha da chave da CA).

Copie o conteúdo do certificado (começa em —–BEGIN CERTIFICATE e vai até —–END CERTIFICATE – incluindo estas linhas) e cole no host(agente) em /etc/zabbix/certs/agente.pem.

Configurar o agente:

Edite no zabbix_agentd.conf:
TLSConnect=cert
TLSAccept=cert
TLSCAFile=/etc/zabbix/certs/cacert.pem
TLSCertFile=/etc/zabbix/certs/agente.pem
TLSKeyFile=/etc/zabbix/certs/chave.key

Configurar a Interface Web

Na configuração do Host, vá em “Encryption”, selecione “Certificate” e configure os itens de acordo com sua configuração:

Agora vem o que considero uma bizarrice: O campo “Issuer” deve ser preenchido com a informação de “quem assinou o certificado”, e o campo “Suject” com a informação do certificado. Até aí tudo OK. O detalhe é que para o Zabbix a informação deve ser colocada exatamente contrária  a saída do openssl. Neste teste, por exemplo, a saída do openssl é a seguinte:

Issuer: C=BR, ST=SP, L=Campinas, O=Default Company Ltd, CN=ca-zabbix
Subject: C=BR, ST=SP, O=Default Company Ltd, CN=zabbix-agent.local

No entanto, a implementação do Zabbix pede a sequência contrária: CN,O,L,ST,C. A única forma de arrumar isso sem ter que copiar do erro da Interface web foi utilizando um “script” para inverter os campos:

Issuer:
# openssl x509 -inform PEM -in /etc/zabbix/certs/agente.pem -text | grep “Issuer:” | cut -d “:” -f2 | awk -F, ‘{print $5″,”$4″,”$3″,”$2″,”$1}’ | sed ‘s/ //g’

Subject:
# openssl x509 -inform PEM -in agent.pem -text | grep “Subject:” | cut -d “:” -f2 | awk -F, ‘{print $4″,”$3″,”$2″,”$1}’ | sed ‘s/ //g’

Uma observação é que, caso você tenha colocado algum espaço no preenchimento do certificado observe se o espaço foi suprimido e corrija caso necessário.

E enfim, se tudo estiver OK vai funcionar bem…

Referência

https://www.zabbix.com/documentation/3.0/manual/encryption

The post Configurando Criptografia no Zabbix appeared first on Blog do Gesiel Bernardes.

Este tutorial foi baseado na instalação com pacotes pré-compilados. Neste cenário já temos o Zabbix 2.4 instalado via yum, a partir do repositório do Zabbix.

Vale ressaltar que este tutorial só se aplica ao CentOS 7. Para o CentOS 6 não vai funcionar porque o pacote “zabbix-server” 3.0  não está disponível nos repositórios do Zabbix.

Migrando para o Zabbix 3.0

Parar o serviço

Primeiro passo é parar o serviço do Zabbix

# systemctl stop zabbix-server
# sustemctl stop zabbix-agent

Realizar o Upgrade

Basta reinstalar o pacote “zabbix-release”, instalando do Zabbix 3.0. Veja:

# yum remove zabbix-release
# yum install http://repo.zabbix.com/zabbix/3.0/rhel/7/x86_64/zabbix-release-3.0-1.el7.noarch.rpm
# yum clean all
# yum update

Neste momento ele irá atualizar todos os pacotes do Zabbix 2.x para o Zabbix 3.0.

Subir o serviço

Feito o upgrade, basta dar o “start” no serviço zabbix-server, que assim que subir ele irá realizar a atualização do banco de dados, processo esse que pode demorar (muito).

# systemctl start zabbix-server

Você pode acompanhar a migração da base olhando o arquivo de log:

# tail -f /var/log/zabbix/zabbix_server.log

12248:20160302:163735.560 current database version (mandatory/optional): 02040000/02040000
12248:20160302:163735.560 required mandatory version: 03000000
12248:20160302:163735.560 starting automatic database upgrade
12248:20160302:163735.580 completed 0% of database upgrade
12248:20160302:163735.585 completed 1% of database upgrade
12248:20160302:163735.597 completed 2% of database upgrade
12248:20160302:163735.607 completed 3% of database upgrade
12248:20160302:163735.616 completed 4% of database upgrade
12248:20160302:163735.622 completed 5% of database upgrade
12248:20160302:163735.638 completed 6% of database upgrade
12248:20160302:163735.655 completed 7% of database upgrade
12248:20160302:163735.669 completed 8% of database upgrade
12248:20160302:163735.685 completed 9% of database upgrade
12248:20160302:163735.706 completed 10% of database upgrade
12248:20160302:163735.708 completed 11% of database upgrade
12248:20160302:163735.710 completed 12% of database upgrade
…

Referência:

https://www.zabbix.com/documentation/3.0/manual/installation/upgrade

The post Migração para o Zabbix 3.0 appeared first on Blog do Gesiel Bernardes.

Introdução ao SELinux

Mesmo sendo conhecido por grande parte dos administradores de redes/sistemas, o uso mais comum consiste basicamente em “desabilitá-lo”. Por requerer um trabalho adicional, ou por não saber configurar o SELinux, ou por outros motivos, os administradores abrem mão de um importante aliado na proteção do servidor. Segundo estatísticas do CSIRT Unicamp, ao menos 70% dos problemas de Segurança em servidores web no ano de 2013 poderiam ter sido evitados se estivessem com SELinux ativo.

SELinux é a implantação do mecanismo de Segurança MAC (Mandatory Access Control) no kernel do Linux. Foi criado pela NSA (National Security Agency), e impõe regras em arquivos e processos em um sistema Linux.
A maioria dos sistemas utilizam DAC ( Discretionary Access Control) para prover segurança do sistema. De uma forma geral, DAC é um controle de acesso em que o usuário tem controle total dos arquivos que possui e executa. Uma vez definida estas permissões, não há nenhuma outra restrição para execução dos processos/arquivos. Isto pode ser um problema quando, por exemplo, o usuário (ou um processo iniciado pelo mesmo) não atribui a permissão adequada a um determinado arquivo, deixando-o exposto. Ou então quando um programa foge do seu comportamento “normal”. Vejamos um exemplo: O usuário apache está sendo utilizado para executar o software Apache. Durante sua execução, devido uma falha de programação no código da página, o processo recebe uma requisição para acessar o arquivo /etc/passwd. As permissões do arquivo são as seguintes:

# ls -l /etc/passwd
-rw-r–r– 1 root root 1760 Out 23 11:12 /etc/passwd

Segundo as permissões do arquivo /etc/passwd, todos podem ler o arquivo. Logo, o Apache poderá exibi-lo sem nenhum problema. Ainda neste exemplo, se a falha do código da página permitisse, seria possível o Apache salvar um arquivo em qualquer local que tiver permissão de escrita.
Mandatory Access Control (MAC), provido pelo SELinux, restringe o nível de controle que os usuários tem sobre os objetos que eles criam, e adiciona categorias e rótulos a todos os objetos do sistema de arquivos. Usuários e processos devem ter acesso adequado a estas categorias e rótulos para que então possam interagir com esses objetos. Quando corretamente implementado, MAC permite ao sistema defender-se adequadamente. A sua capacidade de limitar os privilégios associados a processos de execução limita o âmbito de dano potencial, que pode resultar da exploração de vulnerabilidades em aplicações e serviços do sistema.
Como aplicação do SELinux, o que se tem são rótulos contendo informações relevantes para a segurança de processos e arquivos. Essa informação é chamada de Contexto SELinux (SELinux context), e pode ser obtida utilizando a opção “-Z” no comando “ls”:

# ls -lZ /etc/passwd
-rw-r–r–. root root system_u:object_r:etc_t:s0 /etc/passwd

No arquivo acima temos o contexto do usuário (system_u), a regra (object_r), o tipo (etc_t) e o nível (s0). Estas informações são utilizadas para determinar o acesso do usuário ao arquivo. Agora, vamos voltar ao exemplo anterior, e considerar que neste sistema o SELinux está ativo. Verificaremos então o contexto do processo do Apache:

# ps axZ | grep httpd
unconfined_u:system_r:httpd_t:s0 6906 ? Ss 0:00 /usr/sbin/httpd

Logo, como o contexto do processo não coincide com o contexto do arquivo, o acesso ao mesmo será NEGADO, mesmo que nas permissões DAC o mesmo tenha permissão para tanto.

Modificando contextos

Conforme visto anteriormente, o SELinux tem seu funcionamento baseado em rótulos e em políticas de segurança. Os rótulos dos usuários, arquivos e processos definem o contexto de segurança de cada objeto. Colocando em uma aplicação prática, vejamos o exemplo a seguir:

# ls -Z /var/www/html/
-rw-r—–. root apache unconfined_u:object_r:user_home_t:s0 index.html

Em quase todos os casos, o campo do contexto que realmente importa é o terceiro campo; ele indica o tipo do objeto (neste caso, user_home_t indica que o tipo de arquivo é um arquivo de usuário “humano”). Considerando que este arquivo é uma página que será utilizada pelo Apache, conclui-se que ele não está com o contexto apropriado (que neste caso seria “httpd_sys_content_t”), logo não irá funcionar. Então, é necessário alterar o tipo de arquivo no contexto para que o mesmo funcione:

# chcon -R -t httpd_sys_content_t /var/www/html/

Assim como o chmod é utilizado para alterar permissões DAC, o chcon pode ser utilizado para alterar o contexto dos arquivos. Porém todas as alterações realizadas com o chcon são desfeitas quando o sistema é reiniciado. Para que a alteração seja permanente, deve-se utilizar o semanage:

# semanage fcontext -m -t httpd_sys_content_t /var/www/html/index.html

Alterar o contexto de arquivo por arquivo não parece ser muito produtivo. Por isso, você pode utilizar expressões regulares para alterar vários arquivos de uma vez só:

# semanage fcontext -m -t httpd_sys_content_t “/var/www/html(/.*)?”

Se o retorno que você tiver for o abaixo, basta você trocar o “-m” (modificar) pelo “-a” (adicionar) no comando:

usr/sbin/semanage: O contexto de arquivo para /var/www/html não está definido

# semanage fcontext -a -t httpd_sys_content_t “/var/www/html(/.*)?”

Após realizar as alterações com o semanage, é necessário utilizar o “restorecon” para aplicar as alterações:

# restorecon -Rv /var/www/html

Agora, o arquivo já está com o contexto que permitirá seu funcionamento:

# ls -Z /var/www/html/
-rwxr-x—. root apache unconfined_u:object_r:httpd_sys_content_t:s0 index.html

Políticas Booleanas

Além do contexto, o SELinux utiliza políticas pré-definidas para cada serviço para restringir/conceder acesso á determinadas funções. Você pode visualiza-las utilizando o comando abaixo:

# semanage boolean -l

Supondo que desejo que o home dos usuários seja acessível pelo apache (crio lá no home do usuário uma pasta public_html para o usuário acessar meusite.com/~usuario). Se não alterar nada, o SELinux irá bloquear o acesso. Então, listando as políticas, temos:

# semanage boolean -l | grep -E ‘httpd.*home’
httpd_enable_homedirs (desativado,desativado) Allow httpd to read home directories

Com isso, confirmamos que a esta opção está desativada. Vamos ativá-la então:

# setsebool -P httpd_enable_homedirs 1

Liberar Portas

O SELinux também provê controle sobre qual serviço pode acessar qual porta (para o desespero de alguns). A lista de portas/serviços liberados você pode obter com o comando abaixo:

# semanage port -l

Usando como exemplo um servidor apache, que quero que o mesmo funcione na porta 25000/TCP. Porém, nas políticas SELinux esta porta não está liberada:

# semanage port -l | grep http _port
http_port_t tcp 80, 81, 443, 488, 8008, 8009, 8443, 9000

Então, vamos adicionar a porta 25000 á regra:

# semanage port -a -t http_port_t -p tcp 25000

Resolvendo problemas

    Muitas vezes, por diversas razões, não conseguimos impedir que o SELinux interfira no funcionamento adequado de determinados softwares. Para solucionar casos deste tipo, podemos utilizar o audit2allow para entender melhor o problema ou para criar módulos de políticas para SELinux.

O primeiro passo é verificar os logs em /var/log/audit,log, que terá registros semelhantes a esse:

type=AVC msg=audit(1455199601.283:181376): avc: denied { setattr } for pid=7489 comm=”mingetty” name=”tty6″ dev=devtmpfs ino=5354 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1455199601.283:181376): arch=c000003e syscall=92 success=no exit=-13 a0=7ffdf8b4b090 a1=0 a2=0 a3=7ffdf8b4acd0 items=0 ppid=1 pid=7489 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=”mingetty” exe=”/sbin/mingetty” subj=system_u:system_r:getty_t:s0 key=(null)
type=AVC msg=audit(1455199606.148:181377): avc: denied { setattr } for pid=7490 comm=”mingetty” name=”tty2″ dev=devtmpfs ino=5350 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file

Neste exemplo, SELinux está bloqueando a função “setattr” para a aplicação “mingetty”. Iremos usar o audit2allow para criar um módulo de política SELinux para corrigir tal erros.

Para gerar um relatórios “humano” dos eventos do SELinux, você pode utilizar o comando abaixo:
# audit2allow -a

O comando acima irá analisar todos os registros contidos em /var/log/audit.log. Caso queira uma análise apenas para um erro específico, você pode usar o “grep” para filtrar os eventos:
# grep “mingetty” /var/log/audit.log | allow2audit -w

Para criar um modulo de política SELinux, utilze a opção “-M”:
# audit2allow -a -M meumodulo

Posso também utilizar o “grep”, como no exemplo anterior:
# grep “mingetty” /var/log/audit.log | allow2audit -M meumodulo

Ele irá criar um arquivo “.pp” e um .”te” no diretório corrente. Para instalar o módulo, você utilize o comando:
# semodule -i meumodulo.pp

Em seguinda, habilite o módulo:
# semodule -e meumodulo

Referências:

https://www.security.unicamp.br/54-selinux-um-importante-aliado-na-seguranca-de-servidores-linux-parte-1.html

https://www.security.unicamp.br/86-selinux-um-importante-aliado-na-seguranca-de-servidores-linux-parte-2.html

https://www.security.unicamp.br/103-selinux-um-importante-aliado-na-seguranca-de-servidores-linux-parte-3.html

The post Configurar e trabalhar com SELinux (CentOS) appeared first on Blog do Gesiel Bernardes.