Hardening – SSH

Para o hardening de ssh devemos:

Permitir acesso usando o protocolo SSHv2 somente, isto é feito editando o arquivo /etc/ssh/sshd_config e trocando a linha:

#PROTOCOL 1,2

para:

PROTOCOL 2

Criar um grupo para usuários que podem acessar o servidor remoto, e desabilitar o login do root no SSH:

vi /etc/ssh/sshd_config

#AllowUsers root

or

PermitRootLogin no

AllowGroups sshallow

No exemplo acima o grupo criado foi sshallow, para criar o grupo em S.O.s Linux basta digitar o comando:

#groupadd sshallow

Podemos ainda restringir os hosts/IPs que acessam o servidor remotamente. Para isto precisamos somente editar o arquivo /etc/hosts.allow e adicionar os ips : a palavra allow para os ips que queremos liberar e na última linha digitamos ALL : deny para negar qualquer outro ip que não tenha sido setado como allow ( liberado ).

sshd : 127.0.0.1 : allow

sshd : 192.168. : allow

sshd : 10. : allow

sshd : x.x.x.x : allow

sshd : x.x.x.x : allow

sshd : ALL :deny

A última linha vai restringir o acesso ao SSH de qualquer ip, liberando apenas os IPS listados acima desta linha.

Outro recurso muito interessante é o uso de chaves criptográficas para autenticação via ssh, irei escrever sobre isto posteriormente pois pretendo explicar o que são as chaves como funciona o algoritmo que as gera e ai sim, como configuramos o ssh para usa-las.

Serviços desnecessários ( Desabilite-os )

Serviços desnecessários normalmente são isntalados por padrão no seu S.O. linux, caso você já tenha seus servidores instalados remova-os e caso vá instalar algum desmarque os pacotes a seguir, pois eles provavelmente não serão utilizados e são considerados pacotes inseguros:

– rshd:

É um shell que pode ser executado remotamente quando este serviço está “startado”em seu sistema, o grande problema deste serviço é que ele não provê medidas de segurança para as execuções.

– rlogind

É um serviço que possibilita logins remotos, támbem é um serviço que não provê segurança nos acessos feitos através deste deamon.

– rwhod

Servidor de status do sistema

: Rwhod é um servidor que mantem a base de dados usada pelos programas rwho e ruptime. Essa operação esta relacionada com a habilidade de enviar mensagens ao broadcast da rede.

– telnetd

Telnetd é um servidor telnet e Telnet é um protocolo cliente-servidor usado para permitir a comunicação entre computadores ligados numa rede (exemplos: rede local / LAN, Internet), baseado em TCP.

Telnet é um protocolo de login remoto.

Antes de existirem os chats em IRC o Telnet já permitia este gênero de funções.

O protocolo Telnet também permite obter um acesso remoto a um computador.

Este protocolo vem sendo gradualmente substituído pelo SSH, cujo conteúdo é criptografado antes de ser enviado. O uso do protocolo Telnet tem sido desaconselhado, a medida que os administradores de sistemas vão tendo maiores preocupações de segurança. Com o Telnet todas as comunicações entre o cliente e o servidor podem ser vistas, inclusive senhas, já que são somente texto plano, permitindo assim que com o uso de “port-stealing” intercepte a conexão e seus pacotes, fazendo hijacking.

-ftpd

FTP significa File Transfer Protocol (Protocolo de Transferência de Arquivos), e é uma forma bastante rápida e versátil de transferir arquivos (também conhecidos como ficheiros), sendo uma das mais usadas na internet.

Pode referir-se tanto ao protocolo quanto ao programa que implementa este protocolo (Servidor FTP, neste caso, tradicionalmente aparece em letras minúsculas, por influência do programa de transferência de arquivos do Unix).

A transferência de dados em redes de computadores envolve normalmente transferência de arquivos e acesso a sistemas de arquivos remotos (com a mesma interface usada nos arquivos locais). O FTP (RFC 959

) é baseado no TCP, mas é anterior à pilha de protocolos TCP/IP, sendo posteriormente adaptado para o TCP/IP. É o padrão da pilha TCP/IP para transferir arquivos, é um protocolo genérico independente de hardware e do sistema operacional e transfere arquivos por livre arbítrio, tendo em conta restrições de acesso e propriedades dos mesmos.

– sendmail

Sendmail é um agente de transferência de correio (MTA na sigla em inglês) de código aberto: um programa para o roteamento e a entrega de correio eletrônico.

-inetd

O inetd atua como um servidor gerenciador para outros daemons. Quando uma conexão é recebida pelo inetd, ele determina para qual daemon a conexão é destinada e executa o daemon correspondente e a ele delega o socket. Executar uma instância do inetd reduz a carga no sistema de forma geral, comparado a se executar cada daemon individualmente.

Primariamente, o inetd é usado para executar outros daemons, mas diversos protocolos simples são tratados diretamente, como chargen, auth e daytime.

Swap com criptografia

É interessante e simples manter o swap criptografado, para ativar:

# sysctl vm.swapencrypt.enable

vm.swapencrypt.enable=0

# sysctl vm.swapencrypt.enable=1

vm.swapencrypt.enable: 0 -> 1

No exemplo acima, no próximo boot a configuração será perdida. Para manter a configuração edite o arquivo /etc/sysctl.conf.

# vi /etc/sysctl.conf

Modifique a linha:

#vm.swapencrypt.enable=0

Para:

vm.swapencrypt.enable=1

Kernel Flags – Hardening

Essas flags são permissões adicionais no sistema de arquivos, fugindo das permissões padrões de usuário, grupo e outros. O conceito é parecido com os atributos estendidos do Linux, pois você pode definir um arquivo como imutável, como modificável apenas por um daemon, arquivo que pode ser editado, mas não removido etc.

Existem quatro tipos de flags, elas são: sappnd, schg, uappnd e uchg.

* sappnd

Essa flag só pode ser definida ou removida pelo root. Arquivos definidos com essa flag só podem receber dados (append), mas não podem ser editados. O uso é adequado para logs do sistema. Essa flag não pode ser removido com o secure level 1 ou superior.

* schg

Essa flag só pode ser definida ou removida pelo root. Arquivos com essa flag se tornam imutáveis, não podendo ser modificados ou substituídos. Essa flag não pode ser removida no o secure level 1 ou superior.

* uappnd

O dono do arquivo ou o root podem definir essa flag. Com ela arquivos podem ser modificados, mas não removidos por outros usuários. O dono do arquivo ou o root podem remover essa flag em qualquer secure level.

* uchg

O dono do arquivo ou o root podem definir essa flag. Da mesma forma como o schg, essa flag torna o arquivo imutável, mas com a diferença que a flag pode removida em qualquer secure level pelo dono do arquivo ou root.

Uso das flags

Exemplo de um arquivo sem as flags:

# ls -lo /bsd

-rw-r–r– 1 root wheel – 6861562 Dec 16 18:15 /bsd

Definindo uma flag para o arquivo /bsd (kernel)

# chflags schg /bsd

Verificando novamente:

# ls -lo /bsd

-rw-r–r– 1 root wheel schg 6861562 Dec 16 18:15 /bsd

Removendo a flag:

# chflags noschg /bsd

# ls -lo /bsd

-rw-r–r– 1 root wheel – 6861562 Dec 16 18:15 /bsd

Lembrando que as flags schg e sappnd não podem ser removidas com o secure level 1 e 2. Para poder removê-las desses dois secure levels é preciso rebootar o sistema e entrar em modo mono-usuário (boot -s).

Arquivos interessantes do sistema para utilizar a flag schg (imutáveis).

# chflags schg /bsd

# chflags schg /etc/changelist

# chflags schg /etc/daily

# chflags schg /etc/inetd.conf

# chflags schg /etc/netstart

# chflags schg /etc/pf.conf

# chflags schg /etc/rc

# chflags schg /etc/rc.conf

# chflags schg /etc/rc.local

# chflags schg /etc/rc.securelevel

# chflags schg /etc/rc.shutdown

# chflags schg /etc/security

# chflags schg /etc/mtree/special

Pastas:

# chflags -R schg /bin

# chflags -R schg /sbin

# chflags -R schg /usr/bin

# chflags -R schg /usr/libexec

# chflags -R schg /usr/sbin

Linux ( Kernel ) – Secure Levels OpenBSD

Os Secure Levels dizem como o kernel irá lidar com a segurança do ambiente. Existem quatro níveis de segurança, são eles -1, 0, 1 e 2, e pode ser configurado no arquivo /etc/rc.securelevel.

Nível -1: Podemos dizer que o nível -1 é o nível Windows, pois não há nenhuma “feature” de segurança configurada para o kernel. Os desenvolvedores do OpenBSD não recomendam utilizar esse nível. Apenas utilize em casos de necessidade.

Nível 0: Quando o OpenBSD é iniciado pela primeira vez o securelevel 0 é usado. Esse nível também não possui segurança adicional.

Nível 1: É o padrão do OpenBSD. Nesse nível o kernel não permite a escrita direta a memória através dos devices /dev/mem e /dev/kmem. A escrita nos “Raw Disk” também é proibida e as flags schg e sappnd não podem ser removidas dos arquivos.

Nível 2: É o nível mais paranóico do sistema. Nesse nível o firewall (PF) não pode ser alterado e as configurações até mesmo do relógio do sistema são limitadas. Esse nível também inclui as características do nível 1.

O secure level pode ser definido através do comando sysctl (se estiver nos níveis -1 e 0), ou através do arquivo /etc/rc.securelevel (será preciso reiniciar o sistema).

# sysctl kern.securelevel
kern.securelevel=-1
# sysctl kern.securelevel=2
kern.securelevel: -1 -> 2

Att.

Leonardo Gomes Duarte

Hardening de servidores Linux

Bom dia caro leitores,

Na sub-categoria hardening, irei postar dicas, experiências e o que aprendi na minha pós em gestão de segurança da informação sobre hardening de servidores ( para ser mais específico – servidores Linux ).

A definição de hardening segundo o site Wikipedia é:
“Hardening é um processo de mapeamento das ameaças, mitigação dos riscos e execução das atividades corretivas – com foco na infra-estrutura e objetivo principal de torná-la preparada para enfrentar tentativas de ataque. “

Este conceito, pelo que é visto, é muito amplo e genérico nos possibilitando o ingresso em diversas áreas da tecnologia. Ao meu ver para se ter um hardening efetivo devemos sempre ter especialistas em cada assunto que é abordado por um servidor específico, como por exemplo um servidor de aplicação web. Neste tipo de servidor temos diversas ferramentas envolvidas desde o sistema operacional até bancos de dados, etc.

No ambiente Linux podemos citar por exemplo um S.O. Suse Linux Enterprise ou RedHat Enterprise, para este item é necessário um especialista para fazer o hardening bem feito, porém “rodando” sobre ele temos ainda, no caso de um servidor de aplicação web um apache, tomcat ou jboss e um software de banco de dados como por exemplo um mysql, um Oracle, um postgres, e para cada software deste recomendo, por experiência própria, um especialista para realizar o hardening devido a diversos pontos de muita especificidade de cada software citado.

Atualmente é muito difícil e caro achar um profissional que tenha especialidade em todos os ramos e softwares envolvidos em um ambiente tecnológico, isto se não podemos dizer que é impossível. Este fato nos remete a achar que os hardenings efetuados nas empresas atualmente são ineficientes, porém isto não é verdade, todo e qualquer hardening, por mais superficial que seja é de grande valia. Vemos muitas empresas que ainda nem começaram o processo e utilizam usuários padrões sem senha, acessos sshs com configuração padrão, sistemas operacionais com serviços desnecessários escutando em portas padrões, nestes casos é fundamental que ao menos um hardening básico e superficial seja efetuado e este pode ser realizado por um profissional com conhecimentos relativamente básicos sobre o ambiente da empresa.

Abordarei aqui hardenings básicos e avançados para S.O. Linux. Acompanhem!

Att.

Leonardo Gomes Duarte

Problemas com o Kerberos antigo

Olá pessoal,

bom dia,

hoje resolvi deixar aqui uma experiência que tive a algum tempo com o servidor kerberos. Estava revirando minhas anotações para ver se achava alguma coisa interessante e vi este problema que demorei pra descubrir o que era e até hoje me lembro o quanto sofri..rs

Bom, pra você que não tem o costume de atualizar as versões dos softwares do seu S.O. Linux de produção fica a dica que todo mundo dá mas 90% dos profissionais não segue, sempre mantenha o seu ambiente de produção atualizado!!! É claro que antes de atualizar softwares críticos você deve executar testes em um ambiente de homologação para ver se tudo vai continuar como era antes, para que caso ocorro algum problema você possa resolve-lo com mais calma antes de fazer uma cagada no ambiente de produção e ficar sob pressão para resolver. 🙂

Bom, a questão é… Na época que tive o problema, minha rede inteira parou de autenticar, e o que eu via nos arquivos de log era apenas a seguinte mensagem:

“LDAP connection is lost, it might due to slow network or overtaxed direcotry server, please check LDAP settings and the integrity of LDAP server. If LDAP setting is already disabled, you shouldnt use User/group name via proxy authorization for User Identification. From now on, daemon will keep running and default back to IP identification until LDAP server is back to live”

Depois de muita análise do problema e suor descobri que o kerberos na versão krb5-server-1.4.3-19.10.3 tem um problema com o tamanho do arquivo de log (kdc.log).. Quando este tamanho excede 2Gb o kerberos para e você fica doido.
Bom a saída então foi apenas limpar o arquivo de log com o comando echo > /var/log/kdc.log e pronto. Simples né?! Porém para chegar até esta solução foi um caos…rs Acredito que a última coisa que qualquer profissional iria pensar em uma situação destas era que o arquivo de log estava muito grande.rs

Bom é isto.

Um grande abraço a todos!

Att.

Leonardo Gomes Duarte.