Apache – calcular o tamanho de cada processo
To check the size for each apache process you can run:
# ps -ylC httpd --sort rss
To check the size for each apache process you can run:
# ps -ylC httpd --sort rss
To test your configs, check your apache-badbots.conf and find the failregex.
Code:
failregex = ^<HOST> -.*"(GET|POST).*HTTP.*"(?:%(badbots)s|%(badbotscustom)s)"$
Chose one entry from “badbots” and run fail2ban-regex with a test-string against your apache-badbots.conf:
Code:
fail2ban-regex '1.2.3.4 - - [12/Feb/2013:10:53:59 +0100] "GET / HTTP/1.1 200" 39460 "-" "autoemailspider"' /etc/fail2ban/filter.d/apache-badbots.conf
You should get something like “Success, the total number of match is 1”
Code:
#Joomla com_jce exploit SecRule HTTP_User-Agent "BOT for JCE" "deny,status:500,id:5000218,msg:'Joomla com_jce code exec'" #Joomla com_jce exploit SecRule REQUEST_URI "/images/stories/.+\.php" "deny,status:500,id:5000219,msg:'Joomla com_jce code exec'"
The first blocks the user agent. That exploit puts PHP files into site.com/images/stories/something.php if it is successful, so the 2nd rule blocks access to those in case they change user agent.
Even with the .htaccess or this first rule, you should still use the 2nd rule. Changing user agents is very simple.
Outra sugestão:
https://github.com/bluedragonz/bad-bot-blocker
# yum install httpd-devel
# yum install mod_evasive
* É necessário ativar o repositório EPEL
Reinicia-se o Apache para ativar o módulo
# /etc/init.d/httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ]
Verificar que o módulo está ativo
# php -r 'phpinfo();' | grep -i evasive ^ Loaded Modules | core prefork http_core mod_so mod_auth_basic mod_auth_digest mod_authn_file mod_authn_alias mod_authn_anon mod_authn_dbm mod_authn_default mod_authz_host mod_authz_user mod_authz_owner mod_authz_groupfile mod_authz_dbm mod_authz_default util_ldap mod_authnz_ldap mod_include mod_log_config mod_logio mod_env mod_ext_filter mod_mime_magic mod_expires mod_deflate mod_headers mod_usertrack mod_setenvif mod_mime mod_dav mod_status mod_autoindex mod_info mod_dav_fs mod_vhost_alias mod_negotiation mod_dir mod_actions mod_speling mod_userdir mod_alias mod_rewrite mod_proxy mod_proxy_balancer mod_proxy_ftp mod_proxy_http mod_proxy_connect mod_cache mod_suexec mod_disk_cache mod_file_cache mod_mem_cache mod_cgi mod_version mod_evasive20 mod_perl mod_php5 mod_proxy_ajp mod_python mod_ssl |
Agora vamos configurar o módulo. Esta é a configuração que estou a testar de momento, parece funcionar bem mesmo num servidor partilhado com muitos acessos.
Editar o ficheiro /etc/httpd/conf.d/mod_evasive.conf:
<IfModule mod_evasive20.c> DOSHashTableSize 3097 DOSPageCount 6 DOSSiteCount 100 DOSPageInterval 2 DOSSiteInterval 2 DOSBlockingPeriod 600 </IfModule>
Reinicia-se novamente o Apache para recarregar as configurações:
# /etc/init.d/httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ]
Não é possível desactivar o mod_security2 através de um ficheiro .htaccess. É necessário desactivá-lo no virtual host no ficheiro de configuração httpd.conf adicionando as seguintes directivas:
<IfModule mod_security2.c> SecRuleEngine Off </IfModule>
h5ai – http://larsjung.de/h5ai/
O h5ai personaliza o aspecto da listagem de directórios/ficheiros de forma mais agradável.
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>-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.
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
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.