SSH ataques brute force

O servidor estava a ser bombardeado com pedidos a tentar explorar uma falha existente no SSH. O log do SSH mostrava mensagens deste tipo:

Feb 28 21:53:55 ccems-web2 sshd[5488]: Bad protocol version identification 'GET http://cashinlink.com/6ydbw58 HTTP/1.1' from UNKNOWN
Feb 28 21:54:20 ccems-web2 sshd[5491]: Bad protocol version identification 'GET http://50a574f0.linkbucks.com/ HTTP/1.1' from UNKNOWN
Feb 28 21:54:27 ccems-web2 sshd[5494]: Connection closed by 127.0.0.1
Feb 28 21:54:29 ccems-web2 sshd[5496]: Bad protocol version identification 'GET http://e8de474e.linkbucks.com/ HTTP/1.1' from UNKNOWN
Feb 28 21:54:41 ccems-web2 sshd[5497]: Bad protocol version identification 'POST http://proxy.traficer.net/test.php HTTP/1.1' from UNKNOWN

Como o SSHD não é capaz de determinar a fonte do ataque é necessário utilizar o Strace para descobrir qual o IP.

Strace – Tracks and displays system calls associated with a running process

strace -f -e getpeername -p sshd-pid

Os resultados mostraram isto:

--- SIGCHLD (Child exited) @ 0 (0) ---
Process 5504 attached (waiting for parent)
Process 5504 resumed (parent 16532 ready)
[pid  5504] getpeername(3, {sa_family=AF_INET, sin_port=htons(3856), sin_addr=inet_addr("85.140.128.165")}, [1157143637847441424]) = 0
[pid  5504] getpeername(3, {sa_family=AF_INET, sin_port=htons(3856), sin_addr=inet_addr("85.140.128.165")}, [7217096605625745424]) = 0
[pid  5504] getpeername(3, {sa_family=AF_INET, sin_port=htons(3856), sin_addr=inet_addr("85.140.128.165")}, [16]) = 0
[pid  5504] getpeername(3, 0x7fff272839f0, [2821568938222026880]) = -1 EBADF (Bad file descriptor)
Process 5504 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
--- SIGCHLD (Child exited) @ 0 (0) ---
Process 5630 attached (waiting for parent)
Process 5630 resumed (parent 16532 ready)
[pid  5630] getpeername(3, {sa_family=AF_INET, sin_port=htons(35372), sin_addr=inet_addr("218.6.19.3")}, [3209377693044834320]) = 0
[pid  5630] getpeername(3, {sa_family=AF_INET, sin_port=htons(35372), sin_addr=inet_addr("218.6.19.3")}, [7217878495832047632]) = 0
[pid  5630] getpeername(3, {sa_family=AF_INET, sin_port=htons(35372), sin_addr=inet_addr("218.6.19.3")}, [16]) = 0
[pid  5630] getpeername(3, 0x7fff9f2b0110, [11469262112979681408]) = -1 ENOTCONN (Transport endpoint is not connected)
Process 5630 detached
--- SIGCHLD (Child exited) @ 0 (0) ---

Basta bloquear na firewall os IPs e o problema fica resolvido.

iptables -A INPUT -s 85.140.128.165 -j DROP
iptables -A INPUT -s 218.6.19.3 -j DROP

 

Como eu utilizo o Fail2ban nos servidores para bloquear os vários tipos de ataques vou explicar as alterações na configuração que são necessários para se bloquear automaticamente este ataques.

Edita-se o ficheiro /etc/fail2ban/filter.d/sshd.conf e adiciona-se na directiva failregex estas linhas:

^%(__prefix_line)sBad protocol version identification '.*?' from <HOST>
^%(__prefix_line)sDid not receive identification string from <HOST>

Blocking IPs in Linux

null route block:

route add -host XXX.XXX.XXX.XXX reject

Mais informação: http://www.cyberciti.biz/tips/how-do-i-drop-or-block-attackers-ip-with-null-routes.html

 

IPTables block:

iptables -I INPUT -s XXX.XXX.XXX.XXX -j DROP
iptables -I RH-Firewall-1-INPUT -s XXX.XXX.XXX.XXX -j DROP (CentOS)

(a opção -I adiciona a regra no topo da chain. a opção -A adiciona no final.)

WordPress + ModSecurity2 = slow load

Pelos vistos o wordpress não funciona com o modsecurity2. A solução passa por desactivar o modsecurity2 para o site através do .htaccess

<IfModule mod_env.c> SetEnv MODSEC_ENABLE Off PassEnv MODSEC_ENABLE </IfModule>

httpd não inicia

-bash-3.2# service httpd start
A iniciar o httpd: (98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs

-bash-3.2# lsof -i :80
COMMAND   PID   USER   FD   TYPE   DEVICE SIZE NODE NAME
perl    24082 apache    4u  IPv6 77043797       TCP *:http (LISTEN)
[init]  24093 apache    4u  IPv6 77043797       TCP *:http (LISTEN)
-bash-3.2# kill -9 24082
-bash-3.2# kill -9 24093
-bash-3.2# service httpd start
A iniciar o httpd:                                         [  OK  ]

Quando este tipo de situação ocorre normalmente significa que o servidor foi comprometido. Neste exemplo é possível verificar que existe um processo a correr na porta 80 iniciado como utilizador apache pelo perl. Estava a correr uma aplicação (trojan) para realizar scans a outros servidores.

Instalar mod_security no CentOS 5.4

UPDATE:

Actualizações das regras aqui: http://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/

O mod_security é útil para proteger o Apache contra diversos tipos de ataques a aplicações web, agindo como uma camada de protecção.

Para realizar a instalação do mod_security no CentOS existem duas formas, compilar o código-fonte ou instalar o pacote binário do repositório EPEL (Extra Packages for Enterprise Linux). Neste guia vamos instalar o pacote binário.

Caso não possua o repositório EPEL activado no seu sistema, instale-o com o comando abaixo:

Versão 32 bits

# rpm −Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel−release−5−4.noarch.rpm

Versão 64 bits

# rpm −Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel−release−5−4.noarch.rpm

Antes de instalar o pacote do mod_security no meu ambiente (CentOS 5.4 64 bits) foi necessário instalar o pacote lua, portanto, caso encontre erros de dependência da biblioteca liblua-5.1.so durante a instalação execute o comando abaixo:

# rpm −ivh http://mirrors.kernel.org/fedora−epel/5Server/x86_64/lua−5.1.2−1.el5.x86_64.rpm

Instale o pacote do mod_security com o comando abaixo:

# yum install mod_security

O arquivo de configuração principal do mod_security encontra-se em /etc/httpd/conf.d/mod_security.conf, no directório /etc/httpd/modsecurity.d/ encontram-se todos os outros arquivos de configuração do mod_security incluindo o arquivo /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf que deve ser ajustado de acordo com as suas necessidades.

Os arquivos de log encontram-se em /var/log/httpd/modsec_debug.log e em /var/log/httpd/modsec_audit.log.

Após a instalação verifique no arquivo /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf se a opção SecRuleEngine está On:

# vim /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf SecRuleEngine On

Agora basta reiniciar o serviço com o comando abaixo:

# service httpd restart

Nos logs do Apache pode ser verificado se o módulo foi devidamente carregado:

# tail -f /var/log/httpd/error_log [Tue Dec 15 20:34:35 2009] [notice] caught SIGTERM, shutting down [Tue Dec 15 20:34:44 2009] [notice] SELinux policy enabled; httpd running as context root:system_r:httpd_t [Tue Dec 15 20:34:45 2009] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Dec 15 20:34:46 2009] [notice] ModSecurity for Apache/2.5.9 (http://www.modsecurity.org/) configured. [Tue Dec 15 20:34:46 2009] [notice] Original server signature: Apache/2.2.3 (CentOS) [Tue Dec 15 20:34:46 2009] [notice] Digest: generating secret for digest authentication ... [Tue Dec 15 20:34:46 2009] [notice] Digest: done [Tue Dec 15 20:34:47 2009] [notice] Apache/2.2.0 (Fedora) configured -- resuming normal operations

E após algumas tentativas segue um exemplo do mod_security em ação:

# tail -f /var/log/httpd/error_log [Tue Dec 15 18:29:21 2009] [error] [client XX.XX.XX.XX] ModSecurity: Warning. Match of "rx ModSecurity" against "WEBSERVER_ERROR_LOG" required. [ile "/etc/httpd/modsecurity.d/modsecurity_crs_21_protocol_anomalies.conf"] [line "65"] [id "960913"] [msg "Invalid request"] [severity "CRITICAL"] [hostname "meu.site.com"] 

Depois foi necessário definir o SecDataDir na configuração. Isto não estava definido inicialmente e surgiam erros nos logs.

ModSecurity: Unable to retrieve collection (name "", key ""). Use SecDataDir to define data directory first.

Este erro foi corrigido adicionando a directiva SecDataDir e criando um directório para este propósito, dando permissões ao apache para escrita.

# vim /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf
( Added SecDataDir /usr/local/apache/modsec_data )
mkdir /usr/local/apache
mkdir /usr/local/apache/modsec_data
chown apache:apache /usr/local/apache/modsec_data
chown apache:apache /usr/local/apache

Depois de reiniciar o serviço o modsecurity começou a aplicar as regras, mas em vez de bloquear os pedidos, simplesmente registava os avisos. Alterei a SecDefaultAction em

# vim /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf
SecDefaultAction "phase:2,pass"

para

SecDefaultAction "phase:2,deny,log,status:403"

Fonte: http://www.cyberciti.biz/faq/rhel-fedora-centos-httpd-mod_security-configuration/

Fonte: http://devinvenable.blogspot.com/2010/04/modsecurity-setup-on-centos-54.html

Pesquisas no linux

Ex: Pesquisar ficheiros com mais de 100MB

find . -type f -size +100000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'

Percorre todas as subpastas do /home/teste/moodledata e move todos ficheiros com o nome backup.zip para a pasta /backupdisc/backupdata/teste

find /home/teste/moodledata -iname '*backup-*.zip' -exec /bin/mv '{}' /backupdisc/backupdata/teste \;
find /home/escola-m/moodledata -iname 'backup-*.zip' -exec /bin/mv '{}' /home/escola-m/backupdata \;

This gives you a list of the 25 largest directories

du -xk | sort -n | tail -25 du -dk | sort -n | tail -25

Lista o tamanho de todas as pastas dentro do moodledata

du -h --max-depth=1 /home/site/moodledata

Lista o tamanho de todas as pastas dentro do moodledata ordenadas por tamanho

du -h --max-depth=1 /home/site/moodledata | sort -n -r

Pesquisa útil para encontrar ficheiros corrompidos pela actualização CVS

find /home/xxx/moodle/ -iname '.#*.php*'

Contar o nº de ficheiros num diretório

ls -1 targetdir | wc -l

Pesquisar ficheiros do utilizador apache com a extensão .php

find /home/user/public_html/ -user apache -name "*.php"

Lista todos os ficheiros do diretório atual que tiverem mais de 200MB

find . -type f -size +200M -exec ls -lh {} \;

Testar configuração Apache

Depois de se fazerem alterações às configurações do Apache (httpd.conf) é boa prática testar a configuração antes de a implementar.

Para testar erros no ficheiro de configuração do Apache:

apachectl configtest

Se o ficheiro de configuração estiver correcto este comando irá responder com Syntax Ok. Caso contrário, responderá com informação detalhada sobre o erro encontrado.

chmod recursivo só a pastas

Para se modificar as permissões de pastas e subpastas de um directório faz-se dentro do directório:

find . -type d -exec chmod 770 {} \;

Modificar as pastas para rwxrwxr-x:

find . -type d -exec chmod 775 {} \;

Modificar os ficheiros para rw-rw-r–:

find . -type f -exec chmod 664 {} \;

Modificar as pastas para rwxr-xr-x:

find . -type d -exec chmod 755 {} \;

Modificar os ficheiros para rw-r–r–:

find . -type f -exec chmod 644 {} \;