Eu largo todo o tráfego nas portas, exceto na 80 para o meu servidor web.

Eu tenho algumas regras como esta no iptables:

iptables -A INPUT -p tcp -m tcp --dport 80 -m string --string "cgi" --algo bm --to 1000 -j DROP

Alguém que tem mais pode compartilhar? Eu sei sempre que os hackers ruins ainda estão atualizando, mas alguns sempre começam com o mesmo código. Preciso interromper a conexão com base em alguns critérios. Aqui estão alguns logs do Apache (eu removo ips, mas cada ataque vem do mesmo):

Ataque 1: Isso eu não sei o que está tentando fazer, mas faça 50 vezes do mesmo ip

GET / HTTP/1.1  301 224 -   Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22
GET / HTTP/1.1  302 3387    -   Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22

Ataque 2: esta tentativa de obter informações apenas sobre o servidor.

GET / HTTP/1.1  301 224 http://myip:80/ Go-http-client/1.1
GET / HTTP/1.1  302 3228    http mywebsite  Go-http-client/1.1
GET /es/ HTTP/1.1   200 40947   https mywebsite Go-http-client/1.1

Ataque 3: eles tentam obter acesso a uma vulnerabilidade da página de login

GET /userlogin/login.aspx HTTP/1.1  302 186 -   -

Ataque 4: esta tentativa de acessar um cgi na primeira solicitação (veja minha primeira regra do iptables para largar isso)

GET /hndUnblock.cgi HTTP/1.0    302 186 -   Wget(linux)
GET /tmUnblock.cgi HTTP/1.0 302 186 -   Wget(linux)

Eu sou muito novo com o servidor, esses 4 ataques são apenas das últimas 12 horas ... Tem milhares por semana.

Atualização: a resposta atual é completamente atualizada.

De acordo com esta discussão , criei um repositório do GitHub chamado WWW Security Assistant . Existe um ramo chamado ask_ubuntudedicado a esta resposta. Todas as referências, anteriormente disponíveis aqui , são removidas devido ao limite de caracteres - elas estão disponíveis no GitHub.

A seguir, são exibidas algumas maneiras, envolvidas em um mecanismo completo, de como aumentar a segurança do Apache2 no Ubuntu 16.04.

Tabela de conteúdo:

• Script do Assistente de Segurança da WWW (WSAS) ► Iptables
• Iptables - Configuração básica - Salvar e restaurar
• ModEvasive for Apache2
• ModEvasive ► WSAS ► Iptables
• ModSecurity 2.9 para Apache2
• Conjunto de regras principais do ModSecurity OWASP 3.x
• Lista de permissões de regras do ModSecurity
• Regras do ModSecurity ► WSAS ► Iptables
• Arquivos de log ModSecurity e Apache
• Arquivos de log do ModSecurity ► Fail2Ban ► Iptables
• ModSecurity GuardianLog ► HTTPD Guardian ► WSAS ► Iptables
• ModSecurity GuardianLog ► HTTPD Custom Analyze ► WSAS ► Iptables

Além disso, digamos que é sempre bom usar HTTPS:

• Leia HTTPS e dicas comuns de segurança do Apache

Script do Assistente de Segurança da WWW ► Iptables

Aqui é apresentado o script www-security-assistant.bash. Isso pode ajudá-lo no manuseio de endereços IP maliciosos. O script tem dois modos.

Modo automático

Quando um programa externo, como o Apache mod_security, fornece um $IPendereço malicioso . Nesse caso, a sintaxe que chama o script deve ser:

www-security-assistant.bash <ip-address> Guardian
www-security-assistant.bash <ip-address> ModSecurity
www-security-assistant.bash <ip-address> ModEvasive
www-security-assistant.bash <ip-address> a2Analyst

Nesse modo, o script fornece dois estágios de ação e, para cada ação, envia um email ao (s) administrador (es).

• Primeira etapa: nas primeiras 'transgressões', a fonte $IPserá banida por um período igual ao valor de $BAN_TIME. Este modo usa o comando at.

• Segunda etapa: quando o número de transgressões de certas $IPse tornar igual ao valor de $LIMIT, esse $IPendereço será banido permanentemente através do Iptables e será adicionado ao $BAN_LIST.

Modo manual

Este modo aceita as seguintes opções:

• www-security-assistant.bash <ip-address> --DROP "log notes"

  Cria uma entrada no arquivo /var/www-security-assistant/iptables-DROP.liste gera uma regra como:

  iptables -A GUARDIAN -s $IP -j DROP
  

• www-security-assistant.bash <ip-address> --DROP-CLEAR "log notes"

  Cria uma entrada no arquivo /var/www-security-assistant/iptables-DROP-CLEAR.list, remove a regra de Iptables, remove $IPo histórico e $BAN_LIST:

  iptables -D GUARDIAN -s $IP -j DROP
  

• www-security-assistant.bash <ip-address> --ACCEPT "log notes"

  Cria apenas uma entrada no arquivo /var/www-security-assistant/iptables-ACCEPT.list.

• www-security-assistant.bash <ip-address> --ACCEPT-CHAIN "log notes"

  Cria uma entrada no arquivo /var/www-security-assistant/iptables-ACCEPT.liste gera uma regra como:

  iptables -A GUARDIAN -s $IP -j ACCEPT
  

Dependências

O script usa iptables-save.she a iptablescadeia GUARDIAN, explicada na próxima seção. Ele criará e manterá alguns arquivos dentro do $WORK_DIR:

• www-security-assistant.history - contém os dados para as transgressões do IP anterior.
• www-security-assistant.mail - o conteúdo do último email enviado pelo script.
• iptables-ACCEPT.list; iptables-DROP.liste iptables-DROP-CLEAR.list.

O script precisa de uma configuração mínima para enviar emails:

sudo apt install s-nail mutt mailutils postfix
sudo dpkg-reconfigure postfix  # For General type: Internet Site
echo 'Test passed.' | mail -s Test-Email email@example.com

Se houver algum serviço HTTPS configurado, seu certificado TLS poderá ser usado no serviço Postfix.

Além disso, o script usa at: sudo apt install at.

Instalação

• Crie um diretório de trabalho, vamos chamá-lo /var/www-security-assistant. Faça o download www-security-assistant.bashe torne-o executável:

  sudo mkdir /var/www-security-assistant
  sudo wget https://raw.githubusercontent.com/pa4080/www-security-assistant/ask_ubuntu/www-security-assistant.bash -O /var/www-security-assistant/www-security-assistant.bash
  sudo chmod +x /var/www-security-assistant/www-security-assistant.bash

• Disponibilize www-security-assistant.bashcomo comando personalizado:

  sudo ln -s /var/www-security-assistant/www-security-assistant.bash /usr/local/bin/

• Conceda permissão para www-dataexecutar www-security-assistant.bashsem senha via sudo. Use o seguinte comando para criar e editar com segurança um novo arquivo com uma sudoersregra adicional ' ':

  sudo visudo -f /etc/sudoers.d/www-security-assistant

  Adicione a seguinte linha dentro do arquivo - salve o arquivo e saia:

  www-data ALL=(ALL) NOPASSWD: /var/www-security-assistant/www-security-assistant.bash

• Tweak www-security-assistant.bash. Mude pelo menos o valor da variável $EMAIL_TO.

Checar

• Represente-se $AGENTe verifique se o MODO Automático funciona corretamente:

  www-security-assistant.bash 192.168.1.177 Guardian

  Em seguida, verifique seu e-mail, digite iptables -L GUARDIAN -n, revise os arquivos www-security-assistant.historye www-security-assistant.mail. Execute o comando acima 5 vezes e revise os arquivos iptables-DROP.liste iptables-CURRENT.conf.

• Verifique se o MODO Manual funciona corretamente - adicione seu host local à Lista Branca:

  www-security-assistant.bash 127.0.0.1 --ACCEPT "Server's localhost IP"

  Em seguida, verifique o arquivo iptables-ACCEPT.list.

A parte restante deste tutorial é como se integrar www-security-assistantao seu sistema.

Iptables - Configuração básica - Salvar e restaurar

Configuração básica

Por favor, leia este manual antes de adicionar as seguintes regras.

sudo iptables -F

sudo iptables -I INPUT 1 -i lo -j ACCEPT
sudo iptables -I INPUT 2 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# This rule may lock you out of the system!
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT ACCEPT

Antes de executar as próximas ações, abra uma nova conexão SSH e tente fazer login no seu sistema para verificar se tudo está funcionando bem!

Salvar e restaurar

Isso pode ser conseguido por meio de scripts personalizados, que salvarão e restaurarão o iptablescone durante o processo de parada-partida (ou reinicialização) do sistema. (Se usarmos o UFW para configurar as regras do Iptables, essa etapa não será necessária.)

printf '#!/bin/sh\n/sbin/iptables-save > /var/www-security-assistant/iptables-CURRENT.conf\nexit 0\n' | sudo tee /var/www-security-assistant/iptables-save.sh
printf '#!/bin/sh\n/sbin/iptables-restore < /var/www-security-assistant/iptables-CURRENT.conf\nexit 0\n' | sudo tee /var/www-security-assistant/iptables-restore.sh
sudo chmod +x /var/www-security-assistant/iptables-restore.sh /var/www-security-assistant/iptables-save.sh

sudo ln -s /var/www-security-assistant/iptables-save.sh /etc/network/if-post-down.d/iptables-save
sudo ln -s /var/www-security-assistant/iptables-restore.sh /etc/network/if-pre-up.d/iptables-restore

Criar nova cadeia

Crie uma nova cadeia, chamada GUARDIANe insira-a como número 3 na INPUTcadeia:

sudo iptables -N GUARDIAN
sudo iptables -I INPUT 3 -j GUARDIAN

Checar

Reinicie o sistema e verifique a configuração. Por favor, use sudo systemctl reboot(não use a opção forçar reboot -f). Quando o sistema está on-line novamente, podemos verificar se a cadeia recém-criada existe:

sudo iptables -L GUARDIAN -n

ModEvasive for Apache2

O ModEvasive é um módulo de manobras evasivas para o Apache fornecer ação evasiva no caso de um ataque HTTP DoS ou DDoS ou ataque de força bruta. Consulte Mais informação...

Instalação

• Instale e ative o módulo:

  sudo apt install libapache2-mod-evasive
  sudo a2enmod evasive

• Crie o Diretório de Log e torne-o acessível para www-data:

  sudo mkdir -p /var/log/apache2_mod_evasive
  sudo chown www-data /var/log/apache2_mod_evasive

• Ajuste a configuração básica - remova o comentário e edite determinadas diretivas no arquivo de configuração:

  /etc/apache2/mods-enabled/evasive.conf

• Reinicie o Apache: sudo systemctl restart apache2.service.

Checar

• Abra uma página da Web a partir do servidor e atualize a janela do navegador algumas vezes intensivamente (pressione F5) - você deve receber a mensagem de erro 403 Proibida . No diretório de log, será gerado um novo arquivo de bloqueio. Este arquivo deve ser excluído para detecção adicional de transgressões deste endereço IP.

ModEvasive ► WSAS ► Iptables

Aqui vamos configurar mod_evasivepara conversar iptablesatravés do www-security-assistant.bash, criado na seção acima.

• Edite /etc/apache2/mods-available/evasive.confdesta maneira:

  <IfModule mod_evasive20.c>
      DOSHashTableSize    3097
      DOSPageCount        9
      DOSSiteCount        70
      DOSPageInterval     2
      DOSSiteInterval     2
      DOSBlockingPeriod   10
  
      #DOSEmailNotify     your@email.foo
      DOSLogDir           "/var/log/apache2_mod_evasive"
      DOSSystemCommand    "sudo /var/www-security-assistant/www-security-assistant.bash %s 'ModEvasive' 'AutoMode' >> /var/www-security-assistant/www-security-assistant.execlog 2>&1"
  </IfModule>

• Crie um arquivo de log e reinicie o Apache:

  sudo touch /var/www-security-assistant/www-security-assistant.execlog && sudo chown www-data /var/www-security-assistant/www-security-assistant.execlog

Para testar esta configuração podemos simular ataque DDOS através do F5método, acima referido, ou se pode usar um comandos como ab, hping3etc.

Atenção: Tenha cuidado porque a iptablesregra, usada no WSAS, derrubará todas as novas conexões da fonte $IP, incluindo as conexões SSH. É bom ter uma maneira de backup para conectar-se ao servidor durante os testes. Você pode alterar esta regra para funcionar apenas com as portas HTTP / HTTPS.

ModSecurity 2.9 para Apache2

O ModSecurity é um mecanismo de firewall de aplicativos da web que fornece muito pouca proteção por si só. Para se tornar útil, o ModSecurity deve ser configurado com regras. Para permitir que os usuários aproveitem ao máximo o ModSecurity imediatamente, o Spider Labs da Trustwave está fornecendo um conjunto de regras certificado e gratuito ... Leia mais ...

Instalação

• Instale e ative o módulo:

  sudo apt install libapache2-mod-security2
  sudo a2enmod security2

• Crie um arquivo de configuração:

  sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

  Leia e edite com /etc/modsecurity/modsecurity.confcuidado! Adicione ou altere pelo menos as seguintes diretivas:

  # -- Rule engine initialization ----------------------------------------------
  SecRuleEngine On
  
  # -- Debug log configuration -------------------------------------------------
  SecDebugLogLevel 2
  SecDebugLog "/var/log/apache2_mod_security/modsec_debug.log"
  
  # -- Audit log configuration -------------------------------------------------
  SecAuditLog "/var/log/apache2_mod_security/modsec_audit.log"
  
  # -- Guardian log configuration -------------------------------------------------
  SecGuardianLog /var/log/apache2_mod_security/modsec_guardian.log

• O arquivo /etc/apache2/mods-enabled/security2.confenvolve /etc/modsecurity/modsecurity.confa configuração do Apache. Nesta fase, security2.confdeve ter a seguinte aparência:

  <IfModule security2_module>
      SecDataDir /var/cache/modsecurity
      IncludeOptional /etc/modsecurity/*.conf
  </IfModule>

• Criar diretório de log:

  sudo mkdir -p /var/log/apache2_mod_security

• Configurar rotação do log. Primeiro crie o arquivo de configuração:

  sudo cp /etc/logrotate.d/apache2 /etc/logrotate.d/apache2-modsec

  Em seguida, edite o novo arquivo desta maneira:

  /var/log/apache2_mod_security/*.log { … }

• Reinicie o Apache.

Checar

• Crie um arquivo de configuração adicional /etc/modsecurity, chame-o, por exemplo z-customrules.conf, e adicione a seguinte regra como conteúdo:

  # Directory traversal attacks
  SecRule REQUEST_URI "../" "t:urlDecodeUni, deny, log, id:109"

  Reinicie o servidor: sudo systemctl restart apache2.service. Abra seu navegador e digite https://example.com/?abc=../. O resultado será: 403 Proibido . Verifique os arquivos de log /var/log/apache2_mod_securitypara obter mais detalhes.

• Para tornar as coisas mais divertidas, coloque o script issues.phpem um local apropriado dentro do seu DocumentRoot(aqui estou assumindo que este lugar seja /var/www/html):

  sudo wget https://raw.githubusercontent.com/pa4080/www-security-assistant/ask_ubuntu/appendix/var/www/html/issues.php -O /var/www/html/issues.php

  Modifique a regra acima da seguinte maneira:

  # Directory traversal attacks with redirection (or use URL instead of URI: redirect:'https://example.com/issues.php')
  SecRule REQUEST_URI "../" "t:urlDecodeUni, deny, log, id:109, redirect:'/issues.php'"

  Reinicie o Apache, abra o navegador e digite https://example.com/?abc=../;-) A idéia é emprestada do script do SE BotLovin.cs.

• Edite /etc/modsecurity/z-customrules.confmais uma vez e comente (desative) a regra - este foi apenas um exemplo de teste e é coberto pelo OWASP CRS, descrito na próxima seção.

• Aqui está outro exemplo em que redirecionaremos todas as wp-adminsolicitações de página, mas exceto essas de determinados endereços IP (observe o chain):

  # Block wp-admin access
  SecRule REQUEST_URI "^/wp-admin" "id:108, log, deny, status:403, t:lowercase, chain, redirect:'/issues.php'"
      SecRule REMOTE_ADDR "!@ipMatch 192.168.1.11,99.77.66.12"

  Aqui temos duas ações disruptivas: (1) deny, status:403e (2) redirect:'/issues.php'. Na verdade, não precisamos da denyação, porque ela será substituída pela redirectação.

Conjunto de regras principais do ModSecurity OWASP 3.x

No Ubuntu 16.04 você pode instalar 2.x CSR: apt install modsecurity-crs. Aqui instalaremos o CSR 3.x , são fornecidas instruções detalhadas no manual de instalação ( gité necessário).

Instalação

• Clone o CSR na pasta /usr/share/modsecurity-crs.3:

  sudo git clone https://github.com/SpiderLabs/owasp-modsecurity-crs /usr/share/modsecurity-crs.3

• Atualize e renove automaticamente o banco de dados GeoIP. (O banco de dados do GeoIP não está mais incluído no CRS. Em vez disso, é recomendável fazer o download regularmente.) O script util/upgrade.pytraz essa funcionalidade. Você pode usá-lo da seguinte maneira no cron - sudo crontab -e:

  0 2 * * * /usr/share/modsecurity-crs.3/util/upgrade.py --geoip --crs --cron >> /var/log/apache2_mod_security/owasp-crs-upgrade.log 2>&1

• Crie arquivos de configuração:

  sudo cp /usr/share/modsecurity-crs.3/crs-setup.conf{.example,}
  sudo cp /usr/share/modsecurity-crs.3/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf{.example,}
  sudo cp /usr/share/modsecurity-crs.3/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf{.example,}

  Leia e edite esses arquivos com cuidado! Remova o comentário pelo menos SecGeoLookupDBdiretiva:

  SecGeoLookupDB util/geo-location/GeoIP.dat

• Aplique a configuração do Apache. Edite /etc/apache2/mods-available/security2.confdesta maneira:

  <IfModule security2_module>
      SecDataDir /var/cache/modsecurity
      IncludeOptional /etc/modsecurity/*.conf
      IncludeOptional /usr/share/modsecurity-crs.3/crs-setup.conf
      IncludeOptional /usr/share/modsecurity-crs.3/rules/*.conf
  </IfModule>

  Salve o arquivo e reinicie o Apache.

Lista de permissões de regras do ModSecurity

A lista de permissões das regras do ModSecurity pode ser feita através das seguintes diretivas do ModSec, que podem ser usadas em todo o sistema ou na configuração do host virtual, também globalmente, para diretórios específicos ou correspondências de local:

SecRuleRemoveById
SecRuleRemoveByMsg
SecRuleRemoveByTag
SecRuleUpdateTargetById
SecRuleUpdateTargetByMsg
SecRuleUpdateTargetByTag
SecRuleUpdateActionById

Desative mod_security2para PhpMyAdmin. Mude /etc/phpmyadmin/apache.confdesta maneira:

<Directory /usr/share/phpmyadmin>
    <IfModule security2_module>
        SecRuleEngine Off
    </IfModule>
</Directory>

Desative regras específicas para determinado diretório:

<Directory /var/www/html>
    <IfModule security2_module>
        SecRuleRemoveById 973301
    </IfModule>
</Directory>

Desative regras globalmente. Para esse fim, precisamos adicionar nossas diretivas em algum lugar nos arquivos de configuração do Apache: /etc/modsecurity/z-customrules.confé um bom lugar.

• Desative regras dentro de toda a configuração do Apache:

  SecRuleRemoveById 973301 950907

• Coloque um endereço IP na lista de permissões para que ele possa passar pelo ModSecurity:

  SecRule REMOTE_ADDR "@ipMatch 192.168.110.1" "phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off"

• Desabilite as regras na correspondência do Diretório:

  <Directory /var/www/mediawiki/core>
      SecRuleRemoveById 973301 950907
  </Directory>

• Atualize a ação da regra pelo seu ID na correspondência Local:

  <LocationMatch "/index.php.*">
      SecRuleUpdateActionById 973301 "pass"
      SecRuleUpdateActionById 950907 "pass"
  </LocationMatch>

Nos exemplos acima, assumimos que 973301e 950907são IDs de regra que obstruem o trabalho normal de nossos aplicativos da web. Podemos encontrar regras como essas analisando modsec_audit.log.

Regras do ModSecurity ► WSAS ► Iptables

Aqui estão mais alguns exemplos de como criar SecRules personalizados, e também como podemos chamar o WSAS (Security Assistant Script) através deles.

Configuração inicial

Precisamos de um script de inicialização adicional - modsecurity-assistant.sh. A razão é que, a execação do ModSecurity tem sintaxe muito simples e limitada.

sudo wget https://raw.githubusercontent.com/pa4080/www-security-assistant/ask_ubuntu/modsecurity-assistant.sh -O /var/www-security-assistant/modsecurity-assistant.sh
sudo chmod +x /var/www-security-assistant/modsecurity-assistant.sh

Se você olhar dentro do script, verá algumas variáveis ​​exportadas pelo ModSecurity. Estes são: $REQUEST_URI, $ARGS, $SERVER_NAME, $REMOTE_ADDR, $REMOTE_HOSTe $UNIQUE_ID. As outras variáveis ​​são explicadas dentro do script.

Crie uma regra personalizada e chame nossos scripts por ela

Primeiro, vamos criar uma regra que será executada modsecurity-assistant.sh(e chamada www-security-assistant.bash) quando o URI da solicitação contiver uma palavra incluída em nossa lista negra. Abra /etc/modsecurity/z-customrules.confe adicione as seguintes linhas na parte inferior:

# REQUEST_URI words blacklist
#
SecRule REQUEST_URI "@pmFromFile /var/www-security-assistant/modsecurity-uri-black.list" \
    "id:150, log, t:lowercase, chain, \
    drop, deny, status:403, redirect:'/issues.php'"
    SecRule REMOTE_ADDR "!@ipMatchFromFile /var/www-security-assistant/modsecurity-ip-white.list" \
        "setenv:REMOTE_HOST=%{REMOTE_HOST}, \
         setenv:ARGS=%{ARGS}, \
         exec:/var/www-security-assistant/modsecurity-assistant.sh"

• REQUEST_URI- essa variável contém o URI completo da solicitação atual. A regra é mais ampla:SecRule REQUEST_URI|ARGS|REQUEST_BODY ...

• @pmFromFilelerá o arquivo modsecurity-uri-black.listque contém a lista de frases, onde cada frase ou palavra específica é colocada em uma nova linha. Você pode coletar palavras e frases interessantes dos arquivos de log. Se houver uma correspondência específica entre REQUEST_URIe nossa lista de padrões, a regra será aplicada. O arquivo pode estar vazio, mas você deve criá- touchlo ( ).

• A logação criará entradas de log nos arquivos de log para esta regra com id:150.

• drop, deny(with status) e redirectações pertencem ao grupo disruptivo de ações, elas devem estar no início da regra chain(se houver uma cadeia). A segunda ação substituirá a primeira e a terceira substituirá a segunda; portanto, você deve escolher qual deseja executar e pode excluir as outras.

• chainação chamará a próxima regra da cadeia, observe que a segunda regra não possui id.

• REMOTE_ADDR contém o endereço IP da solicitação.

• @ipMatchFromFileirá o arquivo modsecurity-ip-white.listque contém uma lista branca de endereços IP, separados em novas linhas. As entradas do CIDR também são aceitáveis. Como a ação disruptiva está sempre localizada na regra principal da cadeia, ela será aplicada, mas quando determinado IP estiver nessa lista branca, a execação não será aplicada. O arquivo pode estar vazio, mas você deve criá- touchlo ( ).

• execação chamará nosso script externo. Essa ação não é perturbadora e será executada quando a regra atual retornar verdadeira. Quando essa ação é aplicada, o IP remoto será processado por meio de nossos scripts.

• setenvEssa ação exportará determinadas variáveis ​​internas =%{...} como envvars; os nomes exportados podem ser diferentes dos internos. Algumas variáveis ​​devem ser exportadas manualmente, outras são exportadas automaticamente - provavelmente é um pequeno erro (em alguns casos, a exportação manual com os mesmos nomes, por exemplo setenv:REQUEST_URI=%{REQUEST_URI}, causará um valor em branco da variável exportada).

Checar

Vamos supor que você não tenha o Joomla no seu servidor, edite o arquivo modsecurity-uri-black.liste adicione uma linha com o conteúdo /joomla. Em seguida, digite seu navegador https://exemple.com/joomla. Você deve ser redirecionado e bloqueado através de Iptables. Limpe os registros sudo www-security-assistant.bash <your-ip> --DROP-CLEAR 'some note', adicione seu IP modsecurity-ip-white.liste faça o exercício novamente. Agora você deve ser redirecionado, mas não bloqueado.

Conecte nossos scripts ao OWASP Core Rule Set 3.x

Para isso, atualizaremos a ação padrão das Regras do modo de anomalia (949110 e 959100). Para esse fim, edite o arquivo /usr/share/modsecurity-crs.3/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.confe adicione as próximas linhas na parte inferior:

# -- Anomaly Mode - Update actions by ID -----
#

SecRuleUpdateActionById 949110 "t:none, drop, deny, status:403, redirect:'/issues.php', \
     setenv:REMOTE_HOST=%{REMOTE_HOST}, setenv:ARGS=%{ARGS}, \
     exec:/var/www-security-assistant/modsecurity-assistant.sh"

SecRuleUpdateActionById 959100 "t:none, drop, deny, status:403, redirect:'/issues.php', \
     setenv:REMOTE_HOST=%{REMOTE_HOST}, setenv:ARGS=%{ARGS}, \
     exec:/var/www-security-assistant/modsecurity-assistant.sh"

# -- Anomaly Mode - Whitelist some URI and IP addresses -----
#

SecRule REQUEST_URI "^/wp-admin/admin-ajax.php*|^/index\.php\?title=.*&action=(submit|raw&ctype=text/javascript|raw&ctype=text/css)$" \
    "id:'999010', t:none, phase:1, pass, \
     ctl:ruleRemoveById=949110, \
     ctl:ruleRemoveById=959100"

SecRule REMOTE_ADDR "@ipMatchFromFile /var/www-security-assistant/modsecurity-ip-white.list" \
    "id:'999020', t:none, phase:1, pass, \
     ctl:ruleRemoveById=949110, \
     ctl:ruleRemoveById=959100"

Checar

Não se esqueça de reiniciar (ou recarregar) o Apache para aplicar as alterações na configuração. Não se esqueça de limpar os registros periodicamente durante os testes, caso contrário, você poderá ser bloqueado permanentemente :-)

Simule o ataque de travessia de diretório:

https://example.com/?abc=../../../                         # This should be redirected and blocked
https://example.com/wp-admin/admin-ajax.php?abc=../../../  # This should pass because of the whitelist rule

Simule o ataque de injeção SQL:

https://example.com/?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20'1
https://example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/*&password=foo

Arquivos de log ModSecurity e Apache

O servidor da web Apache pode ser configurado para fornecer ao administrador do servidor informações importantes sobre como ele está funcionando ... A principal via para fornecer feedback ao administrador é através do uso de arquivos de log. Consulte Mais informação...

O ModSecurity possui um poderoso mecanismo de registro. Pela diretiva, SecGuardianLogele fornece um feed de log especialmente projetado para funcionar com scripts externos.

Atualmente, a única ferramenta conhecida para trabalhar com o registro de guardião é httpd-guardian, que faz parte do projeto de ferramentas httpd do Apache . A httpd-guardianferramenta foi projetada para se defender contra ataques de negação de serviço. Ele usa o blacklist toolpara interagir com um firewall ... baseado em iptables, na lista negra dinâmica dos endereços IP incorretos. Consulte Mais informação...

Arquivos de log do ModSecurity ► Fail2Ban ► Iptables

É possível configurar o Fail2Ban para análise de dados dos arquivos de log do Apache. modsec_audit.logé provavelmente a melhor escolha, mas veja também as seções sobre as quais falamos SecGuardianLog.

Tome cuidado para que SecAuditLogRelevantStatusno /etc/modsecurity/modsecurity.confé comentado. Caso contrário, todos que receberem uma página de erro 404 serão bloqueados pelo fail2ban.

SecAuditEngine RelevantOnly
#SecAuditLogRelevantStatus "^(?:5|4(?!04))"

Atualmente, o Fail2Ban não é implementado de forma alguma neste projeto.

ModSecGuardianLog ► HTTPD-Guardian ► WSAS ► Iptables

httpd-guardian- detectar ataques de DoS monitorando solicitações Apache Security, Copyright (C) 2005 Ivan Ristic - foi projetado para monitorar todas as solicitações de servidor da web por meio do mecanismo de registro em cache. Ele monitora o número de solicitações enviadas de cada endereço IP ... O httpd-guardian pode emitir um aviso ou executar um script para bloquear o endereço IP ...

Este script pode ser usado com o mecanismo de registro Apache2 ou com ModSecurity (melhor).

Instalação e configuração dentro das circunstâncias atuais

Faça o download httpd-guardiane torne-o executável:

sudo wget https://raw.githubusercontent.com/pa4080/www-security-assistant/ask_ubuntu/httpd-guardian.pl -O /var/www-security-assistant/httpd-guardian.pl
sudo chmod +x /var/www-security-assistant/httpd-guardian.pl

Leia as linhas 98-119para ver como o script está conectado ao nosso script WSAS.

Aplique a seguinte alteração na configuração do Apache ( /etc/modsecurity/modsecurity.conf) e reinicie-a:

#SecGuardianLog /var/log/apache2_mod_security/modsec_guardian.log
SecGuardianLog "|/var/www-security-assistant/httpd-guardian.pl"

Checar

Para testar o script, desative o ModEvasive ( sudo a2dismod evasivenão esqueça de habilitá-lo mais tarde) e reinicie o Apache. Em seguida, tailo log de exec:

tail -F /var/www-security-assistant/www-security-assistant.execlog

E a partir de outra instância, execute um ataque de DoS, por exemplo, use abdesta maneira:

for i in {1..20}; do (ab -n 200 -c 10 https://example.com/ &); done

ModSecGuardianLog ► Análise personalizada ► WSAS ► Iptables

Aqui é apresentado um script simples, chamado httpd-custom-analyze.bash, que não é algo especial, mas pode ser um bom exemplo. Seus recursos são descritos no corpo do script.

Instalação e Configuração

Faça o download httpd-custom-analyze.bashe torne-o executável:

sudo wget https://raw.githubusercontent.com/pa4080/www-security-assistant/ask_ubuntu/httpd-custom-analyze.bash -O /var/www-security-assistant/httpd-custom-analyze.bash
sudo chmod +x /var/www-security-assistant/httpd-custom-analyze.bash

Aplique a seguinte alteração na configuração do Apache ( /etc/modsecurity/modsecurity.conf) e reinicie-a:

#SecGuardianLog /var/log/apache2_mod_security/modsec_guardian.log
#SecGuardianLog "|/var/www-security-assistant/httpd-guardian.pl"
SecGuardianLog "|/var/www-security-assistant/httpd-custom-analyze.bash"

• O script chamará o WSAS quando o limite for atingido - leia a linha 86e 35.

• Para que os dois httpd-scripts funcionem simultaneamente, edite modsecurity.confe direcione SecGuardianLogpara ambos.

• Para executar um teste, siga as dicas da seção acima.

Percebo que o pa4080 deu uma resposta detalhada e provavelmente muito útil para cuidar disso tudo sozinho. Embora cuidar de problemas por conta própria possa se sentir bem, isso também pode levar muito tempo .

1. Familiarize-se com o Cloudflare, pois eles oferecem proteção DDoS gratuita.
2. Se você atualmente usa apenas o Apache, considere aprender como o NGINX funciona para equilibrar sua carga. O NGINX é ótimo para balancear a carga do Apache, como mostrado aqui e aqui .
3. Consulte as dicas de segurança do Apache em seus documentos .