Sendmail – Relay

Sendmail – Relay

Os arquivos /etc/mail/access e /etc/mail/access.db do sendmail servem para definir quais hosts e redes poderão enviar emails através de nosso servidor sem a necessidade de autenticação. Abeixo segue um exemplo do arquivo /etc/mail/access permitindo que somente a rede local e o localhost enviem emails sem a necessidade de autenticação:

0.0.0.0 REJECT
192.168.0 RELAY
127.0.0.1 RELAY
localhost RELAY
localhost.localdomain RELAY

No exemplo acima definimosque somente a rede local e o localhost enviem emails, essa característica é super recomendada, principalmente pelo alto índice  de spammer que utilizam servidores mal configurados para enviar emails não autorizados. Para que as configurações tenham efeito, não basta somente editar o arquivo /etc/mail/access, é necessário enviar estas informações para o arquivo /etc/mail/access.db, este é um banco de dados com informações do arquivo /etc/mail/access com informações de regras que irão permitir ou negar relay para um domínio host ou rede, utilizaremos a linha de comandos abaixo para esta operação:

[root@host root]# makemap hash /etc/mail/access.db < /etc/mail/access

Esta operação fará com que o conteúdo do arquivo /etc/mail/access seja enviado para o arquivo /etc/mail/access.db, após as alterações, é necessário que o sendmail releia a nova configuração, isso pode ser realizado reiniciado o serviço ou recarregando o mesmo passando os parâmetros reload ou restar ao scripts de inicialização do sendmail:

[root@mail root]# /etc/init.d/sendmail reload

Ou

[root@mail root]# /etc/init.d/sendmail restart

Após este procedimento, o servidor de emails já contará com um recurso a mais em segurança, onde será evitado o envio de mensagens não autorizadas e utilização do servidor por spammers. Vale lembrar também que os usuários devem possuir senhas fortes para que as mesmas não sejam quebradas por ataques de brute-force.

Servidor Virtual

Em muitos casos, temos a necessidade de acessar determinado host ou serviço interno em nossa rede quando estamos fora da mesma, um exemplo deste caso seria acessar uma estação de trabalho ou servidor remotamente utilizando o serviço de terminal da Microsoft, abaixo temos o exemplo de como acessar o host 192.168.0.2 de outras localidades:

xwing:~#iptables -t filter -I FORWARD -s 200.201.200.201 -d 192.168.0.2 -p tcp --dport 3389 -j ACCEPT
xwing:~#iptables -t nat -I PREROUTING -p tcp --dport 3389 -i eth1 -j DNAT --to 192.168.0.2:3389

A primeira regra libera o endereço ip 200.201.200.201 para que o mesmo tenha permissão de entrada na rede através do device eth1 (device com ip válido), e 3389, a segunda regra redireciona o tráfego da porta padrão do serviço de terminal para a porta 3389 do host 192.168.0.2. Para que a conexão deja devolvida corretamente do host 192.168.0.2, é necessário que o mesmo possua o endereço da interface de rede interna como gateway, caso contrário as requisições podem ser perder pela rede. No caso da criação de redirecionamentos utilizando a tabela nat, o administrador deverá estar atento a segurança, e utilizar autenticação no host interno, pois neste caso o firewall somente redireciona a conexão.

Zero Conf

Caso o sistema seja iniciado / reiniciado, e a rota zero-conf (169.254.0.0) esteja habilitada, em sistemas baseados em Red Hat Linux a mesma pode ser desabilitada utilizando o comando route, porém existe uma forma bem mais simples e definitiva para desabilitar a rota zero-conf. Basta editar o arquivo de configurações /etc/sysconfig/network e adicionar a seguinte opção no final do arquivo:

NOZEROCONF=yes

Após este procedimento, na proxima inicializaçao do sistema a rota zero-conf não será mais carregada, para obter mais informaçoes sobre a lrota zero-conf, é recomendada uma visita em seu site http://www.zeroconf.org/.

Worm Conficker

O worm conficker (Win32/Conficker.B), pode ser identificado na rede utilizando o port scan nmap, o download do mesmo pode ser efetuado em http://nmap.org/download.html, o mesmo está disponibilizado para sistemas Windows, Unix, Linux e Apple. Após a instalação, deve ser utilizada a linha de comandos abaixo, redirecionando a saída para /var/log/nmap.log:

nmap -PN -T4 -p139,445 -n -v –script smb-check-vulns,smb-os-discovery –script-args safe=1 192.168.0.0/24 -oA /tmp/scan. Serão gerados 3 arquivos como exibido abaixo:

[root@servernet root]# ls -la /tmp/scan*
-rw-r--r--    1 root     root         8679 Nov  3 15:26 /tmp/scan.gnmap
-rw-r--r--    1 root     root        33189 Nov  3 15:26 /tmp/scan.nmap
-rw-r--r--    1 root     root        65311 Nov  3 15:26 /tmp/scan.xml

O formato de saída .nmap é o padrão a ser gerado nas saídas (output), mais opções podem ser utilizadas para serem gerados diferentes formatos de saída, abaixo temos um exemplo de um host possivelmente infectado:

Host 192.168.42.59 is up (0.00049s latency).
Interesting ports on 192.168.42.59:
PORT STATE SERVICE
139/tcp open netbios-ssn
445/tcp open microsoft-ds
MAC Address: 00:1E:C9:1F:7C:53 (Dell)

Host script results:
| smb-os-discovery: Windows XP
| LAN Manager: Windows 2000 LAN Manager
| Name: WORKGRPLOGISTICA59
|_ System time: 2009-07-29 18:20:40 UTC-3
| smb-check-vulns:
| MS08-067: Check disabled (remove 'safe=1' argument to run)
| Conficker: Likely INFECTED
|_ regsvc DoS: Check disabled (add --script-args=unsafe=1 to run)

Após a detecção, é recomendada a remoçção do host da rede até que o worm seja removido, as instruções para remoção podem ser obtidas em http://support.microsoft.com/kb/962007/pt-br.