Eu participei neste último final de semana do WordCamp São Paulo, evento focado para galera que trabalha e ama o WordPress, o CMS mais utilizado do mundo.

Só assisti duas palestras, uma sobre performance e outra sobre segurança para aplicações Web. Usei o resto do tempo para bater papo com a galera.. 🙂

Duas coisas ficaram evidentes para mim:

  1. o pessoal que trabalha com wordpress se preocupa com segurança, mas não entende muito sobre o assunto
  2. muitos ainda acham que a performance de seus blogs/sites/portais pode ser melhorada adicionando um simples plugin de cache, ledo engano.
Por isso que resolvi escrever este pequenino artigo :), dando algumas dicas e ideias do que podemos fazer para assegurar e performar ambientes que suportaram o WordPress. Coisa importante, eu não sou nenhum especialista em WordPress ou segurança. O meu blog já foi ownado e acabei aprendendo algumas coisas com isso. Por este motivo que eu resolvi compartilhar algumas dicas com vocês. 🙂
Seguiremos os ensinamentos de Jack, o estripador. Antes de mais nada, você deverá escolher o melhor serviço de hospedagem para o seu projeto. Este serviço terá que possuir os seguintes pré-requisitos:

Estabilidade – Mais de 99% no ar, seja quanto ao link ou servidores

Suporte – Uma linha telefônica para contato no momento do problema, um sistema de abertura de chamados, um faq com as perguntas e respostas para os problemas mais comuns e um time de suporte que entende o que está fazendo e que saiba lhe auxiliar (duas coisas totalmente destintas e importantes)

Usabilidade – Um painel de gerenciamento de fácil utilização, acesso e seguro. As atualizações deste painel deverão ser feitas de forma gratuita ao cliente — importante.

Acesso – Que você possa acessar o gerenciamento do seu serviço via painel, sftp ou ssh.

Tendo encontrado um provedor de serviços com estes 4 pontos, nós passaremos para a segunda parte, performance. Isso porque todos que começam um projeto para Internet desejam o mesmo, muuuuitos acessos, mas o seu ambiente, sua infraestrutura, deverá estar preparada para isso.

Utilizar imagens em baixa qualidade, não utilizar uma porrada de plugins e otimizar o seu código e o seu banco ajudam, fato. Mas não resolvem quando você possui mais de 2000 acessos simultâneos, e isso, meus amigos, é coisa para blog mediano nos dias de hoje.. 🙂

Começaremos pela infra mais indicada e utilizada pelo pessoal que tem uma pancada de acessos. Estou falando de mais de 5000 conexões simultâneas:

1 servidor para o seu WordPress (Nginx + PHP) e um outro para o MySql.

Há centenas de tutorias que nos ensinam a instalar o Nginx + PHP + Mysql, mas poucos explicam que você precisa turnar o sistema operacional que suportará este ambiente. Sabemos que parte da responsabilidade é do seu provedor de serviço, mas aí vem a pergunta: E quando você contrata uma hospedagem by cloud computing ou vps, onde a responsabilidade pela administração do servidor como instalação e configuração de produtos passa a ser sua ?

Mas um momento, qual sistema operacional devemos utilizar para suportar este ambiente, Ubuntu, CentOS, Fedora, FreeBSD ?????

Well, isso dependerá do seguinte fator: Você sabe administrar um servidor Linux ? Não importa se ele será Ubuntu ou CentOS, mas sim se você saberá instalar, compilar e analisar o seu ambiente para resolver o primeiro problema que aparecer ?

Caso a resposta seja sim, você pode contratar uma vps ou serviço de infra provido by Cloud, o conhecido IaaS, escolher o seu S.O – aconselho utilizar o Ubuntu ou o CentOS – e mandar bala.

Caso você não tenha esse conhecimento, arrange o quanto antes um amigo que mange do assunto. Alguns provedores, como a KingHost, possuem profissionais capacitados e que ajudam e muito nesta hora. O pessoal da netrevenda.com também manda muito bem.

Vamos para aquisição da Infra

Eu recomendo que cada servidor, quando o assunto é VPS, possua os seguintes requisitos mínimos:

  • 1.1Ghz de processador
  • 2GB de RAM — Se o seu blog crescer e começar a suportar 200 conexões simultâneas, vc precisará de memória ram, a não ser que vc utilize um sistema de cache, coisa que iremos discutir mais abaixo. Caso você passe a utilizar um cache, este valor pode mudar, reduzir, para 768MB.
  • 100GB de disco
  • 1 endereço ip dedicado

Este tutorial é muito legal para quem está começando a configurar um ambiente com VARNISH+NGINX+PHP+MYSQL para WordPress. Ele é uma receita de bolo, e por isso eu tenho algumas ressalvas, mas calma, isso não invalida a sua usabilidade. 🙂

Ainda falando sobre performance, nós precisamos configurar o kernel do seu sistema operacional para duas coisas importantes:

  1. Suportar uma grande quantidade de conexões simultâneas, ao ponto de chegar ao velho e conhecido c10k, quero dizer, suportar o c10k.. 🙂
  2. E assegurar, pelo menos o mínimo, quanto alguns ataques (Syn flood, por exemplo) – exemplos de configurações poderão ser conferidas no seguinte link, falaremos mais sobre o assunto nos próximos tópicos

Pouca gente que administra blogs ou portais com wordpress lembram destes dois pontos.. 🙁

Servidores escolhidos, instalados e configurados, passaremos para algumas dicas 🙂

Performance

Sistema Operacional

Too many open files – o erro do pessoal que trabalha com muitos acessos simultâneos

Este é um erro bem conhecido para quem trabalha suportando ambientes com um volume grande de acesso, e a sua solução é relativamente simples. É claro que ela será apresentada para o mundo Linux.

Você tem que fazer o seguinte:

1. no arquivo /etc/security/limits.conf, adicionar as seguintes linhas e depois salva-lo
* soft nofile 1024
* hard nofile 65535
2. E por último, adicionar a seguinte linha no /etc/sysctl.conf e depois salve o arquivo. Por último, vc terá que executar o comando sysctl -p, para que as configurações sejam carregadas.
fs.file-max=65535

Feito isso, acesse novamente o seu Linux (logar de novo com o usuário), execute o comando ulimit -aH e verifique se já está tudo ok. Feito isso, reinicie os serviços para que eles possam adquirir os novos valores.

Feito isso, você já pode tirar uma preocupação da cabeça, que o seu sistema/servidor conseguirá suportar muitos conexões simultâneamente. Eu estou me referindo aos servidores de frontend, o Varnish e o seu Nginx. O banco de dados tem que ter poucas consultas/conexões. Se ele tem muitas é porque você tem algum problema no seu wordpress, seja código ou configuração, e isso precisa ser verificado e resolvido o quanto antes.

O banco de dados MySQL faz o bind na porta TCP 3306 e o mesmo só tem um objetivo, servir de base de dados para o seu ambiente. Sendo assim, nós devemos ter uma regra de firewall configurada onde o banco só converse com o wordpress, nada mais.

Varnish

Varnish é uma aplicação que tem como função a aceleração do conteúdo estático, servindo também como um cache. Até o presente momento, o Varnish é considerado uma das soluções mais estáveis e performáticas do mercado, além de ser essencial quando o assunto é melhora de performance Web. Ele trabalha com um conjunto de regras e é ideal para cachear objetos “estáticos”(imagens, textos e alguns tipos de scripts).

Uma série de estudos e benchmarks comprovam que o Varnish, como frontend de um ambiente Web, consegue diminuir em mais de 90% do tráfego, já que ele funciona como cache reverso, e mitigar ataques DoS, como o Slowloris.

Algumas considerações importantes quanto a implementação do Varnish como servidor de cache reverso e frontend:

  • Você precisa dedicar um servidor para ele. Utilizar o varnish fazendo cache em memória e isso, infelizmente, torna o servidor um pouco mais caro. Comece alocando uma máquina com 8GB, deixando para o Varnish 6GB. O Varnish-top, além dos comandos comandos do próprio produto, é uma excelente solução para você monitorar a performance do seu cache.
  • O interessante é que há um conjunto de regras para ele que trabalham como um waf – web applicatin firewall – ponto que iremos discutir mais a frente. Essas regras são conhecidas como Varnish Security e podem ser baixadas a partir do seguinte link, mas tomem cuidado com a sua implementação. 🙂
  • O Varnish convive e muito bem com o wordpress. Há uma série de regras disponíveis como exemplo na Web que facilitam a sua configuração para este CMS, mas devemos tomar cuidado com o processo de purge dele, principalmente para os blogs que sofrem atualizações constantes. Isso pode ser resolvido configurando regras no próprio Varnish ou utilizando plugins no wordpress, como este.
  • Eu não vejo a necessidade de implementar o PHP-FPM e o APC tendo o Varnish como frontend, hora bolas, ele que passará a responder a todas as requisições HTTP. Porém muitos administradores o fazem. Este link trás um tutorial bem interessante de como implementar estes carinhas.

Dica rápida de segurança para S.O – Kernel

Aproveitando que estamos mexendo no kernel do S.O, que tal realizarmos um tuning nele, adicionando algumas regras e configurações para melhorar a sua performance e a segurança ?

Para isso há dezenas de receitas de bolo, quero dizer, exemplos de sysctl.conf, mas cada parâmetro ou configuração deverá ser analisado e testado, tudo para atender as suas principais necessidades – performance e segurança. As receitas que coloquei no link logo no início deste parágrafo poderão ser utilizadas, mas um aviso: -não quer dizer que tudo que está ali deverá ser copiado e colado sem ser analisado previamente, e é claro, testado.

Por exemplo, para alguns ambientes, eu gosto de utilizar as seguintes parametrizações:

# The following is suitable for dedicated web server, mail, ftp server etc.
# —————————————
# BOOLEAN Values:
# a) 0 (zero) – disabled / no / false
# b) Non zero – enabled / yes / true
# ————————————–
# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename
# Useful for debugging multi-threaded applications
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
#net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2

########## IPv4 networking start ##############
# Send redirects, if router, but this is just server
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Accept packets with SRR option? No
net.ipv4.conf.all.accept_source_route = 0

# Accept Redirects? No, this is not router
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0

# Log packets with impossible addresses to kernel log? yes
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 0

# Ignore all ICMP ECHO and TIMESTAMP requests sent to it via broadcast/multicast
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Prevent against the common ‘syn flood attack’
net.ipv4.tcp_syncookies = 1

# Enable source validation by reversed path, as specified in RFC1812
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

########## IPv6 networking start ##############
# Number of Router Solicitations to send until assuming no routers are present.
# This is host and not router
net.ipv6.conf.default.router_solicitations = 0

# Accept Router Preference in RA?
net.ipv6.conf.default.accept_ra_rtr_pref = 0

# Learn Prefix Information in Router Advertisement
net.ipv6.conf.default.accept_ra_pinfo = 0

# Setting controls whether the system will accept Hop Limit settings from a router advertisement
net.ipv6.conf.default.accept_ra_defrtr = 0

#router advertisements can cause the system to assign a global unicast address to an interface
net.ipv6.conf.default.autoconf = 0

#how many neighbor solicitations to send out per address?
net.ipv6.conf.default.dad_transmits = 0

# How many global unicast IPv6 addresses can be assigned to each interface?
net.ipv6.conf.default.max_addresses = 1

########## IPv6 networking ends ##############

#Enable ExecShield protection
kernel.exec-shield = 1
kernel.randomize_va_space = 1

# TCP and memory optimization
# increase TCP max buffer size setable using setsockopt()
#net.ipv4.tcp_rmem = 4096 87380 8388608
#net.ipv4.tcp_wmem = 4096 87380 8388608

# increase Linux auto tuning TCP buffer limits
#net.core.rmem_max = 8388608
#net.core.wmem_max = 8388608
#net.core.netdev_max_backlog = 5000
#net.ipv4.tcp_window_scaling = 1

# increase system file descriptor limit
fs.file-max = 65535

#Allow for more PIDs
kernel.pid_max = 65536

#Increase system IP port limits
net.ipv4.ip_local_port_range = 2000 65000

Já outros ambientes sofrem uma série de alterações quando o assunto é buffer, tcp e memória – huge pages, por exemplo. Estou falando de servidores que trabalham com JAVA ou bancos de dados Oracle.

A instalação de pacotes como o htop, iftop e logstalgia, iotop lhe auxiliarão e muito na hora que forem analisar a performance do seu S.O, antes e depois da configuração de um dos parâmetros apresentados acima.

Segurança

Segurança/Hardening do Sistema operacional

Conhecimentos intermediários quanto a administração de servidores Linux facilitam e muito a vida de quem deseja assegurar  o seu ambiente.

Abaixo segue os principais pontos que devemos levar em conta quando vamos assegurar um servidor  Linux (hardening):

  • Atualização dos pacotes – yum update (CentOS) / apt-get update / apt-get upgrade (Ubuntu)
  • Tuning do Kernel — Já abordado em alguns parágrafos acima.
  • Controle de usuários, quotas e deamons – Cada macaco, quero dizer, cada usuário no seu devido espaço
  • Chroot – Uma abordagem interessante, mas que foi substituida pelo SELinux, o problema é que ele é pouco conhecido e implementado, estou falando do SELinux.
  • Firewall / OSSEC / IDS — Este post é uma bela introdução para quem deseja aprender mais sobre o SELinux e tem muito, mas muita coisa que poderíamos falar sobre o OSSEC — isso vale um post. 🙂
  • Permissão de arquivos e diretórios -755 para diretórios e 644 para arquivos, onde o wp-config.php deverá possuir 600.
*** estou vendo que terei que transformar este post em uma série, ele está ficando grande ***

Segurança no PHP

Quando trabalhamos com servidores Web que provêem suporte ao WordPress, nós devemos saber que o PHP, linguagem utilizada por este CMS, é vulnerável a uma série de ataques, por isso que é importante a implementação de boas práticas de segurança.

Eu acabei reunindo algumas destas práticas que devem ser seguidas quanto ao php, quer dizer, mais uma daquelas receitas de bola, mas vou logo avisando, elas deverão ser testadas e avaliadas antes de entrarem em produção.

As configurações abaixo devem ser aplicadas no arquivo php.ini, ele fica no seu servidor Nginx/web. (A instalação do PHP e seus componentes são pré-requisitos para que o seu ambiente WordPress funcione, onde estes pacotes e os passos para sua instalação poderão ser verificados no seguinte link)

São elas:

# Disallow dangerous functions

disable_functions = phpinfo, system, mail, exec ## Try to limit resources ##

# Maximum execution time of each script, in seconds

max_execution_time = 30

# Maximum amount of time each script may spend parsing request data

max_input_time = 60

# Maximum amount of memory a script may consume (8MB)

memory_limit = 8M

# Maximum size of POST data that PHP will accept.

post_max_size = 8M

# Whether to allow HTTP file uploads.

file_uploads = Off

# Maximum allowed size for uploaded files.

upload_max_filesize = 2M

# Do not expose PHP error messages to external users

display_errors = Off

# Turn on safe mode

safe_mode = On

# Only allow access to executables in isolated directory

safe_mode_exec_dir = php-required-executables-path

# Limit external access to PHP environment

safe_mode_allowed_env_vars = PHP_

# Restrict PHP information leakage

expose_php = Off

# Log all errors

log_errors = On

# Do not register globals for input data

register_globals = Off

# Minimize allowable PHP post size

post_max_size = 1K

# Ensure PHP redirects appropriately

cgi.force_redirect = 0

# Disallow uploading unless necessary

file_uploads = Off

# Enable SQL safe mode

sql.safe_mode = On

# Avoid Opening remote files

allow_url_fopen = Off

Instalando PHP-Suhosin

Porém, todas as configurações acima não são suficientes para assegurar o seu servidor. Mas para isso que existe o PHP-Suhosin, um projeto que tem como objetivo assegurar o seu ambiente PHP de diferentes tipos de ataque.

A instalação deste carinha é simples se você utiliza ubuntu ou CentOS, mas com os repositórios certos. No Ubuntu, basta vc executar apt-get install php5-suhosin, já para o CentOS, vc pode seguir o seguinte tutorial para instalação dos repositórios que contêm o pacote, para depois rudar o yum install php5-suhosin.

PHP-Suhosin instalado, agora partimos para segunda parte, configura-lo. Abaixo eu tenho mais uma receita, mas desta vez ela foi tirada do curso de segurança para servidores web da OYS – curso mais do que recomendado. As configurações abaixo deverão ser feitas no seguinte  arquivo /etc/php5/conf.d/suhosin.ini:

Habilitar o Suhosin, deixando a linha abaixo descomentada:

extension=suhosin.so

Limitar a quantidade de directory transversals (../../../): suhosin.executor.include.max_traversal=4

Desabilitar o /e no preg_replace, que normalmente é utilizado de forma insegura, já que esse parâmetro permite a execução de funções do PHP: suhosin.executor.disable_emodifier=Off

Proteger formulários de e-mail contra ataque de spammers: suhosin.mail.protect=2

Configurar limite de memória, pois quando o safe_mode está desabilitado, usuários podem utilizar o ini_set para alterar seu limite de memória: suhosin.memory_limit=256M — Cuidado com este parâmetro. Há blogs em que alocamos mais de 512MB, chegando a 1GB de memória para o PHP. Por isso que este parâmetro deverá acompanhar a mesma quantidade de memória alocada ao PHP

Qual ação o Suhosin executará ao filtrar algo (a opção 402 fará com que o código não seja executado e retornse uma resposta HTTP): suhosin.filter.action=402

Limite máximo de tamanho para variáveis vindas de COOKIE, POST e GET: suhosin.request.max_array_depth=4096 suhosin.request.max_array_index_length=2048 suhosin.request.max_name_length=2048 suhosin.request.max_value_length=650000 suhosin.request.max_vars=4096 suhosin.post.max_array_depth=8048 suhosin.post.max_array_index_length=1024 suhosin.post.max_name_length=2048 suhosin.post.max_totalname_length=8048 suhosin.post.max_vars=4096

Máximo upload de arquivos em um script: suhosin.upload.max_uploads=100 

Desabilitar qualquer include, curl, fpassthru, base64_encode, mail e outras opções na função eval(). Funciona muito bem quando um atacante poe fazer o upload de um script malicioso, cujo conteúdo normalmente é um código obfuscado a partir da base64 e passado para a eval().

suhosin.executor.eval.blacklist=include, include_once, require, require_once, curl_init, fpassthru, file, base64_encode, base64_decode, mail, exec, system, proc_open, leak, syslog, pfsockopen, shell_exec, ini_restore,symlink, stream_socket_server, proc_nice ,popen, proc_get_status, dl, pcntl_exec, pcntl_fork, pcntl_signal, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, socket_accept, socket_bind, socket_connect, socket_create, socket_create_listen, socket_create_pair, link, register_shutdown_function, register_tick_function

Desabilitar eval() por completo, caso não precise dessa função em suas aplicações:

suhosin.executor.disable_eval=Off

Filtra bloqueando todas as funções que não estejam na opção abaixo, separadas por vírgula:

suhosin.executor.func.whitelist=

É o equivalente ao disable_functions no php.ini: suhosin.executor.func.blacklist=

Armazenar em log todas as ações, além das queries SQL que falharam, com o syslog:suhosin.log.syslog = S_ALL & ~S_SQL

Desabilitar a possibilidade de fazer o upload de binários: suhosin.upload.disallow_binary=Off

Desabilitar a possibilidade realizar o upload de arquivos ELF: suhosin.upload.disallow_elf=Off

Essas alterações já nos ajudarão bastante no que diz respeito à segurança com o Suhosin. Para mais informações sobre mais outras opções de configuração, é possível consultá-las no endereço abaixo:

http://www.hardened-php.net/suhosin/configuration.html

*** Logo abordaremos o Varnish, uma solução de cache  que vem sendo implementada por dois grandes motivos – ganhos de performance e segurança, mas para mitigação de ataques DDoS/DoS, alguns deles  — HTTP/ HTTPS, que isso fique bem claro ***O Hardening do seu S.O. e do PHP continuam sendo pontos importantes para integridade do seu ambiente…

Segurança para servidores Web – Nginx

A instalação do Nginx é simples assim como a sua configuração. Segue mais uma receite com sugestões de parâmetros para assegurar o seu servidor Web. Não preciso repetir que cada caso é um caso, e precisa ser analisado.

No nginx.conf, você precisará adicionar as seguintes linhas:

 ## Start: Size Limits & Buffer Overflows ##
  client_body_buffer_size  1K;
  client_header_buffer_size 1k;
  client_max_body_size 1k;
  large_client_header_buffers 2 1k;
 ## END: Size Limits & Buffer Overflows ##
 ## Start: Timeouts ##
  client_body_timeout   10;
  client_header_timeout 10;
  keepalive_timeout     5 5;
  send_timeout          10;
## End: Timeouts ##

Todos os parâmetros acima e mais alguns podem ser vistos com mais detalhes no seguinte link, este outro link trás outros parâmetros e configurações que devem ser analisados..

Segurança para servidores Web – Nginx – WAF – Web Application Firewall

São poucos os blogs/sites/portais que possuem um web application firewall implementado em seus servidores web e o motivo disso é a total falta de conhecimento. Web Application Firewall(waf) são ferramentas focadas em assegurar aplicações WEB.. Elas se baseiam em assinaturas e comportamentos, atuando na mitigação e bloqueio de uma série de ataques, SQL Injection, XSS, DoS e tantos outros..

Os mais utilizados e implementados, do mundo opensource, são o modsecurity, que foi portado para o Nginx, e o Naxsi, esse dedicado ao Nginx, ainda.
O modsecurity está a mais tempo no mercado e tem a possibilidade de comprar regras/assinaturas da trustwave, empresa que o matem ou da atomic linux. O custo por servidor é relativamente baixo, cerca de US$ 200.00 por ano, para cada pacote de regras. Eu destaco as regras e o wiki da Atomic Linux, ambos são atualizados constantemente e ajudam e muito a galera que está começando a trabalhar com este tipo de tecnologia.

Mas não achem que um waf irá proteger os seus servidores de todos os ataques e ameaças existentes na web. Ele consegue eliminar boa parte deles, mas não é 100%. 🙂

Preciso postar algo que fale sobre a instalação do modsecurity no Nginx…***

Plugins para o WordPress

Esse é um dos maiores cuidados que devemos ter quando falamos sobre este CMS, isso porque boa parte das vulnerabilidades encontradas nos dias de hoje estão relacionadas aos seus plugins. Este problema é devido ao mal desenvolvimento ou não conhecimento das boas práticas de segurança pelos os que os criam, os desenvolvedores.

Muitas empresas, antes de implementar um plugin no WordPress, o colocam em quarentena, em um ambiente de testes para averiguar se há alguma falha de segurança ou possível bug com o ambiente que já está em produção. Depois deste período de quarentena é que o plugin é instalado e utilizado no ambiente produtivo.

Falando de plugins, há uma dezena deles especializados em assegurar o WordPress, abaixo segue um pequena lista dos mais utilizados:

  • 6Scan — .. $$$ — Pago
  • Securi da http://sitecheck.sucuri.net/scanner/ — muito bom e pago $$$$
  • Block Bad Queries (BBQ)
  • Bad Behavior
  • Exploit Scanner
  • Secure WordPress
  • WebsiteDefender WordPress Security
  • Wordfence Security
  • WP Plugin Security Check — um dos mais interessantes, pois ele verifica se os plugins que você utiliza são seguros, quer dizer, se há algum registro de problemas de segurança quanto aos plugins que você está utilizando no seu wordpress. 🙂
  • WordPress File Monitor Plus
  • WordPres Firewall 2
  • WP Security Scan

 Segurança na instalação do WordPress

Há centenas de configurações que devemos executar no wordpress para melhorar a sua segurança. Muitos deles estão associados a customização do arquivo .htaccess. O caso é que não iremos abordar este arquivo porque o mesmo é pertencente ao Apache e utilizaremos o Nginx, mas calma, há como migrar as regras contidas no .htaccess para o Nginx, basta utilizar o seguinte site.

Bom, falando ainda sobre segurança do wordpress e não querendo me alongar muito, gostaria que vocês dessem uma boa olhada no seguinte livro WordPress 3 Ultimate Security. Este livros trás uma dezena de recomendações importantes de segurança.

Espero que isso ajude a galera..