Index:
- 0x00000001 – O que é.
- 0x00000002 – Instalação.
- 0x00000003 – Arquivos e Diretórios Importantes.
- 0x00000004 – Implementando Regras.
- 0x00000005 – LogRotate.
- 0x00000006 – Issues.
- 0x00000007 – Conclusão.
- 0x00000008 – Fontes.
0x00000001 – O que é
Existem muitos tipos de firewalls hoje em dia, um deles é um firewall de aplicações web, não é um firewall de layer3 propriamente dito, é um firewall de layer 7. É também conhecido pelo termo WAF(Web Application Firewall).
Então, o Mod_Security2 é um módulo do apache2(httpd) que tem como propósito funcionar como um WAF, ele basicamente analisa as requisições, confere com as regras que você habilita, e então toma uma ação. Ele também tem capacidade de analisar a resposta do servidor, o que é muito interessante e poderia evitar dataleaks.
Eu infelizmente não estou com tempo para realizar umas POC’s como eu costumo fazer, porém, dizem que o Mod_security não fica para trás de soluções próprietárias, ele tem a sua versão proprietária também porém a open funciona muito bem segundo as fontes.
Existem duas formas básicas de implementar esse cara, a primeira delas é dentro do servidor web, junto do website, isso é um problema quando se fala em desempenho já que o módulo utiliza recursos do servidor,buffer, e isso vai direto em memória ram, isso é um problema se seu hardware é limitado porém se o seu hardware é limitado você provavelmente não vai encontrar outra forma de fazer isso. A segunda forma é implementar o WAF em um proxy reverso, um Nginx por exemplo na frente fazendo o proxy reverso disparando para um servidor web logo atrás, você estaria isolando o WAF do seu servidor web logo teria mais recursos pro mesmo operar e realizar buscas mais a fundo nas requisições.
Eu vou falar rápidamente sobre esse cara, não irei explicar muito a fundo pois eu estou puta atolado de coisas e esse paper é mais pra eu documentar meus procedimentos do que pra outra coisa, por isso fica uma merda, porém é isso, você sabe como funciona.
0x00000002 – Instalação
Homologação
O servidor qual estou implementando é um PRETTY_NAME=”SUSE Linux Enterprise Server 12 SP2″ e o apache2 é o tradicional dos repositórios atual.
GO!
A instalação é simples, você vai precisar de dois módulos basicamente para fazer esse cara entrar em operação:
- security2
- unique_id
É provavel que apenas o módulo unique_id esteja presente. Contudo o security2 pode ser encontrado nos repositórios:
SuperAlfa:/# zypper search security2
S | Name | Summary | Type
---+-----------------------------------+-----------------------------------------------------+-----------
| apache2-mod_security2 | ModSecurity Open Source Web Application Firewall | srcpackage
i+ | apache2-mod_security2 | ModSecurity Open Source Web Application Firewall | package
| apache2-mod_security2-debuginfo | Debug information for package apache2-mod_security2 | package
| apache2-mod_security2-debugsource | Debug sources for package apache2-mod_security2 | package
Então vamos instalar:
SuperAlfa:/# zypper install apache2-mod_security2 Posteriormente, vamos mandar subir os módulos:
SuperAlfa:/# a2enmod security2 SuperAlfa:/# a2enmod unique_id Agora vamos verificar se está ok:
SuperAlfa:/# apachectl -M E verifique se os módulos security2_module e unique_id_module estão presentes.
Se estiverem presentes, estamos OK para continuar.
Vamos reiniciar o HTTPD:
linux:/# systemctl restart apache2 Se nenhum problema for encontrado, estamos ok.
Por default, na instalação do Mod_Security, ele já inicializa uma regra de firewall por default, se você analisar no mod_security2.conf vai ver um include lá para um .conf, mas vamos falar dele mais a frente. Então, até esse ponto, já temos um WAF rodando com uma configuração básica.
0x00000003 – Arquivos e Diretórios Importantes
Sobre os arquivos de configuração, o arquivo principal de configuração do WAF é esse: /etc/apache2/conf.d/mod_security2.conf. É esse cara onde vamos ter todas as métricas de configuração, inclusive de virar o WAF somente para detecção ou prevenção, o foco não é explicar o arquivo em si, porém, lá em “Fontes” eu deixei um link contendo uma explicação muito boa sobre.
As regras, todas elas, não são inicializadas aqui, estão para utilização, ficam no diretório: /usr/share/apache2-mod_security2/rules/
O diretório qual você irá adicionar as novas regras para serem carregadas é esse: /etc/apache2/mod_security2.d/*.conf
Logs -> /var/log/apache2/modsec_audit.log
0x00000004 – Implementando Regras
Nós vamos fazer o seguinte aqui, todas as regras vão ficar aonde estão e nós simplesmente iremos linkar elas em um diretório qual o mod_security vai carregar as regras.
As regras, todas elas, ficam no diretório: /usr/share/apache2-mod_security2/rules/
O diretório qual o o WAF vai carregar as regrás é o seguinte: /etc/apache2/mod_security2.d/*.conf
Então, basicamente nós precisamos linkar tudo nesse diretório, vamos dar uma olhada básica e irei demonstrar como implementar uma regra simples, a BAD_ROBOTS
Dando uma olhada no arquivo dessa regra: /usr/share/apache2-mod_security2/rules/base_rules/modsecurity_crs_35_bad_robots.conf , podemos ver uma nota:
# NOTE Bad robots detection is based on checking elements easily
# controlled by the client. As such a determined attacked can bypass
# those checks. Therefore bad robots detection should not be viewed as
# a security mechanism against targeted attacks but rather as a nuisanc
# reduction, eliminating most of the random attacks against your web
# site.
Essa nota já diz tudo, então não seja aqueles caras que acham que uma regra vai resolver todos os problemas, porque não vai.
Dando uma olhada melhor nesse mesmo arquivo, podemos ver que ele utiliza outros dois arquivos que provavelmente devem conter valores que ele utiliza como métrica da regra, segue abaixo:
SecRule REQUEST_HEADERS:User-Agent "@pmFromFile modsecurity_35_scanners.data"
"phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,t:lowercase,block,msg:'Request Indicates a Security Scanner Scann
ed the Site',logdata:'%{matched_var}',id:'990002',tag:'OWASP_CRS/AUTOMATION/SECURITY_SCANNER',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI
/6.5.10',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/AUTOMATION
/SECURITY_SCANNER-%{matched_var_name}=%{matched_var}"
SecRule REQUEST_HEADERS:User-Agent "@pmFromFile modsecurity_35_bad_robots.data"
"chain,phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,block,msg:'Rogue web site crawler',id:'990012',tag:'OWASP_C
RS/AUTOMATION/MALICIOUS',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',severity:'4',capture,logdata:'%{TX.0}'"Acima em negrito está marcado o modsecurity_35_scanners.data no primeiro bloco de código e no segundo: modsecurity_35_bad_robots.data, isso é um arquivo que contém uma lista, dá para ver que ele não possui um diretório, logo está no diretório local que a regra se encontra, o problema está que a regra não vai estar nesse diretório, o link vai estar no /etc/apache2/blablalba/blaba, então será necessário criar links simbolicos para esse .data também, se você esquecer de linkar, você encontrará o seguinte erro:
Nov 18 16:04:55 ip-172-31-27-152 start_apache2[2752]: AH00526: Syntax error on line 20 of /etc/apache2/mod_security2.d/modsecurity_crs_35_bad_robots.conf:
Nov 18 16:04:55 ip-172-31-27-152 start_apache2[2752]: Error creating rule: Could not open phrase file "/etc/apache2/mod_security2.d/modsecurity_35_scanners.data": No such file or directory
Bom, é simples, é só linkar e recarregar o HTTPD(apache2)
root@Freedom:/# ln -s /usr/share/apache2-mod_security2/rules/base_rules/modsecurity_crs_35_bad_robots.conf /etc/apache2/mod_security2.d/modsecurity_crs_35_bad_robots.conf
root@Freedom:/# ln -s /usr/share/apache2-mod_security2/rules/base_rules/modsecurity_35_scanners.data /etc/apache2/mod_security2.d/modsecurity_35_scanners.data
root@Freedom:/# ln -s /usr/share/apache2-mod_security2/rules/base_rules/modsecurity_35_bad_robots.data /etc/apache2/mod_security2.d/modsecurity_35_bad_robots.data
root@Freedom:/# systemctl reload apache2
And Fuckya, estamos agora com a regra default que é aquela inicializada dentro do arquivo de configuração do modSecurity /etc/apache2/conf.d/mod_security2.conf pelo include:
Include /usr/share/apache2-mod_security2/rules/modsecurity_crs_10_setup.conf
E a regra no diretório /etc/apache2/mod_security2.d que acabamos de subir.
Eu particularmente removi o include no arquivo do mod_security2.conf e linkei a regra no diretório /etc/apache2/mod_security2.d/ porque eu quis, simplesmente, nós vivemos no mundo opensource, podemos implementar a mesma coisa de 1922100 formas, então fica a seu critério.
0x00000005 – LogRotate
Rapidamente, LogRotate é o responsável por rotacionar os logs do sistema, isso é importante por alguns motivos, o que eu mais vejo rolar é os sysadmin esquecerem de implementar esse cara e o servidor operar normalmente por alguns meses/anos e então ele crasha sem nenhum motivo aparente, ai vai ver o espaço em disco encheu, crashou a maioria dos daemons que não tem espaço no disco pra utilizar e já era, se resolve fácil, porém é algo que não precisa acontecer né.
Eis o seguinte, a configuração é relativamente simples, o ideal é que você tenha uma estrutura de logs descentralizados(ou pseudo descentralizado), onde todos os seus servers vão descentralizar o log deles mesmos e centralizar em um servidor especifico pra isso. Porém esse não é o caso aqui já que eu sou pobre e não tenho um datacenter.
Os arquivos de configuração ficam aqui /etc/logrotate.d. Acredito que ele já vem instalado na maioria das distros que se respeitem.
Os logs do apache2, já estão definidos devido, provavelmente é o arquivo /etc/logrotate.d/apache2. Nesse arquivo você vai ver os logs default do access e error. Legal, porém temos mais um cara nesse cenário agora, o modsec_audit.log. A configuração é bem simples, basicamente você precisa adicionar essas próximas linhas no arquivo de configuração e estaremos prontos:
/var/log/apache2/modsec_audit.log {
compress
dateext
maxage 365
rotate 99
size=+1024k
notifempty
missingok
create 644 root root
sharedscripts
postrotate
systemctl reload apache2.service
sleep 60
endscript
}
Não pretendo explicar todas as opções nem nada, use o google, apesar delas basicamente serem auto-explicativas.
0x00000006 – Issues.
ISSUE:00001
O unico problema que eu tive foi o seguinte:
Nov 18 14:30:31 SameHistory start_apache2[17178]: AH00526: Syntax error on line 94 of /etc/apache2/conf.d/mod_security2.conf:
Nov 18 14:30:31 SameHistory start_apache2[17178]: ModSecurity: Found another rule with the same id
Essa caralha basicamente ocorreu porque por algum motivo alienigena o httpd.conf está chamando o default-server.conf, e esses dois caras tem um include do diretório /etc/apache2/conf.d/*.conf e dada das circustancias esse cara carrega a caralha do arquivo /etc/apache2/conf.d/mod_security2.conf duas fucking vezes, o problema está dentro do mod_security2.conf onde ele inicializa as regras default:
Include /usr/share/apache2-mod_security2/rules/modsecurity_crs_10_setup.conf
Basicamente eu removi o include do arquivo default-server.conf e boas.
0x00000007 – Conclusão.
Concluindo, o ModSecurity é um WAF, não é complicado de ser instalado e pode proporcionar um novo patamar de segurança nas suas aplicações, não é tão complexo de aprender a manipular ele ou até mesmo criar as próprias regras.
É isso.
0x00000008 – Fontes.
Explicação Aprofundada: https://www.vivaolinux.com.br/artigo/Introducao-ao-ModSecurity>
https://www.vivaolinux.com.br/artigo/Arquivo-de-configuracao-do-mod-security
https://www.vivaolinux.com.br/artigo/Integrando-ModSecurity-ao-NGINX-e-Apache
Computer Addicted 