O primeiro requisito é ter um servidor OpenSSH pelo menos na versão 4.9p1. Tanto meu Ubuntu 8.10 quanto meu OpenSuSE 11.1 vieram com pacotes superiores a essa versão, mas infelizmente o Red Hat Enterprise 5.3 não.

No seu arquivo de configuração do ssh (normalmente /etc/ssh/sshd_config) edite a seguinte linha:

Subsystem       sftp    /usr/libexec/openssh/sftp-server

E substitua por:

Subsystem     sftp   internal-sftp

E também adicione as seguintes linhas no final do arquivo:

Match Group restrito
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

A primeira linha indica que se o usuário pertencer ao grupo “restrito” ele está sujeito às regras que vem a seguir e é logo na próxima linha que determinamos a restrição do usuário ao seu home directory indicado pelo “%h”

Agora basta configurar o usuário adequadamente. Reparem que esta parte é mandatória. Tentei configurar o servidor sem configurar o usuário sem sucesso:

Mar  5 09:08:10 server sshd[12760]: fatal: bad ownership or modes for chroot directory "/home/linuxman"

Então configure o usuário e seu diretório de acordo:

# usermod -G restrito linuxman
# usermod -s /bin/false linuxman
# chown root:root /home/linuxman
# chmod 0755 /home/linuxman

Pronto. Agora seus usuários estão restritos e seguros.

Tenho na minha caixa Solaris o HD do sistema operacional – IDE 8GB -, dois HDs IDE de 2GB e dois HDs SCSI também de 2GB, identificados através do comando format:

root@nexenta:/# format
Searching for disks...done

AVAILABLE DISK SELECTIONS:
0. c0d0 <DEFAULT cyl 4092 alt 2 hd 128 sec 32>
/pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0
1. c0d1 <VMware V-0000000000000000-0001-2.00GB>
/pci@0,0/pci-ide@7,1/ide@0/cmdk@1,0
2. c1d1 <VMware V-0000000000000000-0001-2.00GB>
/pci@0,0/pci-ide@7,1/ide@1/cmdk@1,0
3. c2t0d0 <VMware,-VMware Virtual S-1.0-2.00GB>
/pci@0,0/pci1000,30@10/sd@0,0
4. c2t1d0 <VMware,-VMware Virtual S-1.0-2.00GB>
/pci@0,0/pci1000,30@10/sd@1,0
Specify disk (enter its number): ^C

Vou ignorar o primeiro disco, pois o mesmo já está alocado para o pool padrão do sistema operacional, chamado syspool.

Aqui entra o primeiro conceito sobre ZFS: O sistema de arquivos não vai ser escrito diretamente no disco (block device). Ao invés disso ele será escrito em “pools”, que nada mais são do que devices virtuais que contém discos. Algo parecido com utilizar ext3 em cima de LVM ao invés do disco.

Para listar os pools existentes:

root@nexenta:/# zpool list
NAME      SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
syspool  7.44G  1.81G  5.63G    24%  ONLINE  -

Vamos agora brincar um pouco com as possibilidades que ZFS nos dá.

Cenário 1 – Todos os discos como um único filesystem.

root@nexenta:/# zpool create linuxman c0d1 c1d1 c2t0d0 c2t1d0
root@nexenta:/# zpool list
NAME       SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
linuxman  7.94G    97K  7.94G     0%  ONLINE  -
syspool   7.44G  1.81G  5.63G    24%  ONLINE  -
root@nexenta:/# zfs list
NAME                             USED  AVAIL  REFER  MOUNTPOINT
linuxman                         110K  7.81G    18K  /linuxman
syspool                         1.81G  5.51G    23K  legacy
syspool/rootfs-nmu-000          1.81G  5.51G  1.55G  legacy
syspool/rootfs-nmu-000@initial   271M      -   780M  -
root@nexenta:/linuxman# df -h linuxman
Filesystem             size   used  avail capacity  Mounted on
linuxman               7.8G    18K   7.8G     1%    /linuxman

Perceba que não precisei montar o filesystem, nem editar fstab. Apenas o comando “zpool create” foi o suficiente para criar o pool, formatar os discos, criar uma entrada no zfs e montar o filesystem.
Mas vamos apagar isso e continuar brincando:

root@nexenta:/# zpool destroy linuxman
root@nexenta:/# zpool list
NAME      SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
syspool  7.44G  1.81G  5.63G    24%  ONLINE  -

Cenário 2 – Espelhos

Vou criar agora um novo pool, mas desta vez espelhando os dois discos SCSI:

root@nexenta:/# zpool create linuxman mirror  c2t0d0 c2t1d0
root@nexenta:/# zpool list
NAME       SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
linuxman  1.98G    94K  1.98G     0%  ONLINE  -
syspool   7.44G  1.81G  5.63G    24%  ONLINE  -
root@nexenta:/# df -h linuxman
Filesystem             size   used  avail capacity  Mounted on
linuxman               2.0G     1K   2.0G     1%    /linuxman

Cenário 3 – Adicionando discos ao pool

Esse pool de 2GB não dá para nada? Precisa adicionar mais discos para criar espaço no seu filesystem? No hay problema:

root@nexenta:/# zpool add linuxman mirror  c0d1 c1d1
root@nexenta:/# zpool list
NAME       SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
linuxman  3.97G   114K  3.97G     0%  ONLINE  -
syspool   7.44G  1.81G  5.63G    24%  ONLINE  -
root@nexenta:/# df -h linuxman
Filesystem             size   used  avail capacity  Mounted on
linuxman               3.9G    18K   3.9G     1%    /linuxman

Perceba o detalhe importante: Se você criou o pool como mirror, não dá pra acrescentar somente um disco a mais. Pelo menos dois são necessários.

Mas vamos limpar isso.

root@nexenta:/# zpool destroy linuxman
root@nexenta:/# zpool list
NAME      SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
syspool  7.44G  1.81G  5.63G    24%  ONLINE  -

Cenário 3 – Exportando ZFS via iSCSI

Foi aqui que eu comecei, na verdade. Estou trabalhando num projeto piloto que, quando em produção, vai utilizar SAN. Infelizmente não tenho uma SAN para laboratório, então decidi usar iSCSI para simular o comportamento da SAN.

Começamos criando o pool:

root@nexenta:/# zpool create linuxman c2t0d0 c2t1d0

Mas para podermos exportar é necessário também criar um volume. Um volume é uma fatia do pool, falando simplificadamente.

root@nexenta:/# zfs create  -V 1G linuxman/iscsi
root@nexenta:/# zfs list linuxman/iscsi
NAME             USED  AVAIL  REFER  MOUNTPOINT
linuxman/iscsi     1G  3.91G    16K  -

Este volume pode ser exportado via iSCSI e a própria hierarquia do ZFS vai se encarregar de criar as LUNs:

root@nexenta:/# zfs set shareiscsi=on linuxman/iscsi

É bem provável que o iscsi não esteja rodando no seu Solaris por padrão, então habilite-o:

root@nexenta:/# svcadm enable iscsitgt

E agora seu volume já deve estar disponível:

root@nexenta:/# iscsitadm list target
Target: linuxman/iscsi
iSCSI Name: iqn.1986-03.com.sun:02:1a01588d-af11-4163-a4c7-bdf19d1550a2
Connections: 0

Vamos até o Linux ali do lado para ver se conseguimos utilizar este volume:

[root@cluster1 ~]# iscsiadm -m discovery -t sendtargets -p 172.16.66.128
172.16.66.128:3260,1 iqn.1986-03.com.sun:02:1a01588d-af11-4163-a4c7-bdf19d1550a2

UIA! Vamos usar então:

[root@cluster1 ~]# /etc/init.d/iscsi restart
Stopping iSCSI daemon: /etc/init.d/iscsi: line 33:  5656 Killed                  /etc/init.d/iscsid stop
iscsid dead but pid file exists                            [  OK  ]
Turning off network shutdown. Starting iSCSI daemon:       [  OK  ]
[  OK  ]
Setting up iSCSI targets: Logging in to [iface: default, target: iqn.1986-03.com.sun:02:1a01588d-af11-4163-a4c7-bdf19d1550a2, portal: 172.16.66.128,3260]
Login to [iface: default, target: iqn.1986-03.com.sun:02:1a01588d-af11-4163-a4c7-bdf19d1550a2, portal: 172.16.66.128,3260]: successful
[  OK  ]
[root@cluster1 ~]# fdisk -l|grep part
Disk /dev/sdc doesn't contain a valid partition table
[root@cluster1 ~]# echo -e "n\n p\n 1\n \n \n w\n"|fdisk /dev/sdc
[root@cluster1 ~]# mkfs.ext3 -q /dev/sdc1 -L /linuxman
[root@cluster1 ~]# mkdir /linuxman
[root@cluster1 ~]# mount LABEL=/linuxman /linuxman
[root@cluster1 ~]# df -h /linuxman
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdc1            1008M   18M  940M   2% /linuxman

Divertido, né? Temos agora ext3 encapsulado em ZFS exportado via iSCSI. Isso pode ser útil em cenários como o abaixo.

Cenário 4 – Fazendo backup.

Então esse meu diretório /linuxman contém dados do meu projeto. Mas como ainda é laboratório, vira e mexe eu estrago alguma coisa.
Vou facilitar minha vida com o ZFS então.

No Linux:

[root@cluster1 linuxman]# cd /linuxman
[root@cluster1 linuxman]# for i in $(seq 1 10); do dd if=/dev/zero of=file$i.dat count=1 bs=100M; done 2>/dev/null
[root@cluster1 linuxman]# ls
file10.dat  file1.dat  file2.dat  file3.dat  file4.dat  file5.dat  file6.dat  file7.dat  file8.dat  file9.dat  lost+found

No Solaris:

root@nexenta:/# zfs snapshot linuxman/iscsi@antes-do-teste-1
root@nexenta:/# zfs list
NAME                              USED  AVAIL  REFER  MOUNTPOINT
linuxman                         2.00G  1.91G    18K  /linuxman
linuxman/iscsi                   2.00G  2.91G  1.00G  -
linuxman/iscsi@antes-do-teste-1      0      -  1.00G  -

Volto no Linux e estrago meu árduou trabalho:

[root@cluster1 linuxman]# rm -rf file1*
[root@cluster1 linuxman]# ls
file2.dat  file3.dat  file4.dat  file5.dat  file6.dat  file7.dat  file8.dat  file9.dat  lost+found

Mas para recuperar é fácil:

No Linux:

[root@cluster1 linuxman]# cd /
[root@cluster1 /]# umount /linuxman/

No Solaris:

root@nexenta:/# zfs set shareiscsi=off linuxman/iscsi
root@nexenta:/# zfs rollback linuxman/iscsi@antes-do-teste-1
root@nexenta:/# zfs set shareiscsi=on linuxman/iscsi

E finalmente, no Linux:

[root@cluster1 /]# mount LABEL=/linuxman /linuxman
[root@cluster1 /]# cd /linuxman/
[root@cluster1 linuxman]# ls
file10.dat  file1.dat  file2.dat  file3.dat  file4.dat  file5.dat  file6.dat  file7.dat  file8.dat  file9.dat  lost+found

E ai estão todos os arquivos de volta.

OBSERVAÇÃO: Aparentemente a formatação no blog perdeu algumas partes dos textos pré-formatados, mas nada significativo. Viva com isso. Olhe pelo feed que está legal.

A rede mundial de computadores tem mais de 10 botnets. Todas dominadas por crackers armados até os dentes. É só nego de nmap, nessus, tcpdump e por ai vai.
No resto do mundo são softwares de auditoria. Na internet, são as armas do crime.

Um 0-day attack atravessa um firewall como se fosse papel. É burrice pensar que numa rede assim os daemons, mesmo atualizados, não vão ser crackeados apenas para fazer valer a lei.
E Linux também tem bug amigo, Linux também tem falha de segurança.

É por isso que nessa rede todo administrador tem que escolher: Ou se corrompe, ou se omite, ou vai pra guerra.

Aviso

Se você é um profissional decente, não tenho dúvidas que vai decidir partir para guerra e nesse tutorial vamos ver os passos básicos para tornar seu servidor mais resistente a invasões.

Mas não se iluda. Nada é 100% seguro e seguir as boas práticas de segurança uma vez na vida não vai te ajudar muito. Mantenha-se atualizado, mantenha sua infra-estrutura atualizada (não apenas seus servidores) e seja humilde. Aprenda com seus erros e com os erros dos outros.

Outro ponto que vale ressaltar aqui: Esse tutorial é dirigido ao Ubuntu Server 8.04 (Hardy). Muita coisa pode ser aplicada para desktop e para outras distribuições, mas não é sobre isso que vou falar aqui.

Fique com o básico

Quanto menos pacotes instalados no seu Ubuntu, melhor. Mais pacotes significam mais potenciais pontos de falha, mais opções para um invasor tentar escalar privilégios e mais recursos para ele utilizar sua máquina como ponte para outros ataques em caso de uma invasão bem sucedida.

Durante a instalação do seu Ubuntu Server, quando apresentado às opções, não escolha nenhum pacote. Você pode manualmente instalar openssh, LAMP, DNS e etc mais tarde, num momento mais conveniente.

Num primeiro momento fique apenas com o sistema mais enxuto possível para facilitar as implementações de segurança antes de começar a abrir as portas.

Application Specific

Ter um servidor para cada serviço que você precisa não é mais exclusividade de grandes empresas, com um gordo orçamento. Utilize máquinas virtuais baseadas no seu hypervisor preferido e crie uma máquina virtual para cada tipo de serviço que for utilizar.

Utilize de bom-senso. Não coloque banco de dados da intranet na mesma partição virtual que está seu banco de dados da DMZ.

Algo como um servidor de banco de dados para todos os serviços da DMZ e um servidor HTTP para todos os bancos de dados da DMZ parece mais coerente.

Servidores em redes muito hostis (como um servidor do lado de fora dos firewalls da DMZ) ficam melhor se forem self-contained, ou seja, com todos os serviços rodando numa mesma partição virtual.

Tenha certeza de que tem uma placa de rede exclusiva para administração do seu hypervisor e proteja-a muito bem.

No Ubuntu o Xen é uma excelente opção.

Guardando seus logs

Numa situação ideal sua rede vai dispor de um servidor de syslog onde todos os hosts enviam seus eventos, mas se não for o caso, durante a instalação crie uma partição /var/log com filesystem ext3.

Isso vai permitir que você utilize o chattr para restrigir seus arquivo ao modo append only.

# cd /var/log
# chattr +a messages syslog auth.log daemon.log

Caso esteja utilizando rotacionamento de log, lembre-se de editar as políticas para evitar erros.

Ter logs é essencial para previnir invasões, mas pode ser seu passe livre de problemas em caso de invasão concretizada ou investigação judicial.

Se possível utilize sempre um servidor de syslog numa máquina física à parte. Seja bem paranóico na configuração da segurança dessa máquina.

Utilize firewall local

Mesmo que sua rede disponha de firewall de borda, existe sempre a possibilidade de alguém conseguir acesso à sua rede local. Um visitante numa sala de reunião, um esperto num wireless rogue, etc.

No Hardy nem mesmo com sintaxe do iptables você precisa se preocupar. Basta utilizar o ufw.

Ele já vem com uma lista de regras pré-configuradas com um nível de segurança bem aceitável. Falando em bom iptablês, as policies são DROP e você aplica suas excessões.

Exemplificando um servidor LAMP na sua DMZ:

# ufw allow proto tcp from 192.168.5.0/24 to 192.168.100.2 port 22
# ufw allow proto tcp from any to any port 80
# ufw enable

Onde:

192.168.5.0/24 é sua rede interna.

192.168.100.2 é o IP interno do seu LAMP server

Ou um servidor de DNS apenas com ip válido:

# ufw allow proto tcp from 200.200.200.201 to 200.200.200.10 port 22
# ufw allow proto udp from any to 200.200.200.10 port 53
# ufw allow proto tcp from 200.1.1.200 to 200.200.200.10 port 53
# ufw enable

Onde:

200.200.200.201 é o IP nateado da sua rede

200.200.200.10 é o IP do seu servidor de DNS

200.1.1.200 é o seu DNS Slave

Colocando uma armadura

A Novell desenvolveu um excelente framework de segurança chamado AppArmor e disponibilizou como open source.

Consiste basicamente em um patch no kernel e uma série de ferramentas de gerenciamento.

O conceito é: Uma determinada aplicação, independentemente de estar sendo executada pelo zezinho ou pelo root deve conseguir acessar somente determinados diretórios e arquivos, executar somente determinados comandos e utilizar somente determinadas bibliotecas.

O grande trunfo do AppArmor é que ele proteje seus servidor mesmo contra 0-day attacks. Se você preparar o perfil da sua aplicação muito bem são grandes as chances de seu servidor sair ileso mesmo num ataque a um daemon bugado.

Para isso você gera um arquivo com o “perfil” da aplicação e fala pro AppArmor: Amigão, esse binário só pode fazer isso aqui ó…

O Hardy já vem com o kernel patcheado e com as ferramentas de gerenciamento instaladas. Basta baixar os profiles e sair usando.

# apt-get install apparmor-profiles

Mas lembre-se do seguinte: Os profiles que você instalou levam em conta que você está utilizando os serviços conforme a configuração padrão do Ubuntu. Eu inclusive recomendo que você realmente faça isso sempre que possível, mas caso esteja utilizando alguma coisa diferente do padrão, um pouco de tweak pode ser necessário.

Pessoalmente senti falta de um profile para o Apache, mas depois de criar o meu eu entendi o motivo: Depende muito do que você vai rodar no seu webserver.

Talvez mais para frente eu escreva um artigo sobre o AppArmor, mas por enquanto, fique com este link da Wiki do Ubuntu.

UPDATE (29/08/2008 08:27): Meu amigo Mezzanotti, que é especialista em IT Security, mandou um link bem interessante que eu não conhecia: Center for Internet Security. Muitos tutoriais de hardening lá. Vale uma passada.

E não sem motivo, já que é um produto excelente e integra facilmente com diversas aplicações e produtos de terceiros.

Mas se você já precisou autenticar com Linux contra um AD sabe que isso é um parto. É preciso instalar suporte a kerberos, samba, winbind e configurar um bocado de arquivos manualmente. Não é missão impossível, mas é fonte de dor de cabeça, frustração e até motivo para empresas desistirem de investir mais a fundo no Linux.

Felizmente uma empresa chamada Likewise Software parece estar resolvendo este problema. Seu produto principal – o LikeWise – tem duas versões: Open e Enterprise.

Melhor ainda, o Ubuntu Hardy Heron (8.04) já vem com o pacote open no seu repositório e a instalação e configuração não poderiam ser mais simples:

Instalando:

Nosso velho e conhecido apt:

sudo apt-get update

sudo apt-get install likewise-open

-> Neste ponto você pode ter que responder algumas perguntas sobre seus domain controlers.

Depois basta dar join no domínio:

sudo domainjoin-cli join dominio.com.br Administrator

Onde:

- dominio.com.br é o FQDN do seu domínio.

- Administrator é um usuário com poderes de dar join de máquinas no domínio

Problemas conhecidos:

Eu me deparei com problemas de autenticação devido à sincronia dos relógios do Linux e dos domain controlers. O kerberos é muito sensível quanto ao sincronismo dos tickets, por isso eu acrescentei uma tarefa na crontab para manter os relógios sincronizados:

$ sudo crontab -l

*/5 * * * * ntpdate domain-controler.dominio.com.br > /dev/null

Onde:

domain-controler.dominio.com.br pode ser o controlador do domínio ou o time server da sua rede ou de sua preferência.

Utilizando

Depois de tudo instalado e configurado, dê logout e dê login com seu usuário no formato DOMINIO\usuario .

Referências

HOWTO: Active Directory authentication in Ubuntu 8.04

Likewise Software