Objetivo:
Explicar como Gerenciar usuarios e grupos no samba4 pelo shell

Introdução:
Este Post tem como objetivo explicar:

Usúarios:

• Trocar senha
• Força a troca de senha no proximo login
• Deletar usuarios
• Listar todos os usuarios do Dominio
• Desabilitar e Habilitar Usuario
• Configurar a expiração de senha

Grupos

• Adicionar
• remover
• Adicionar e remover membros ( usuario ) em grupos
• Podemos adicionar Grupos dentro de outro grupo

No post anterior “Criando usuário Pelo Shell no Samba4” expliquei como criar usuário pelo shell

Cenário:
Servidor: Debian 7
Versão do Samba: 4.0.3
Nome do usuario que sera criado = mundoti e mundoti2
Nome do grupo que sera criado = diretoria e diretoria_ead
Senha do usuario = 1234.Mudar.Senha
Nome do dominio = empresa.net
Diretório de instalação do samba = /opt/samba/

Agora vamos gerencia-los

*Obs: para executar esses comandos sem ter digitar o caminho completo
Ex samba-tool /opt/samba/bin/samba-tool
você tem que ter exporta a variável path do local da instalação do samba4 isso pode ser feito da seguinte forma.

Digitando o comando:

# export PATH=$PATH:"/opt/samba/bin:/opt/samba/sbin”

Trocar senha do usuário:

# samba-tool user setpassword mundoti --newpassword=1234.Mudar.Senha

Trocar senha do usuário e forca a troca no Próximo Login:

# samba-tool user setpassword mundoti --newpassword=1234.Mudar.Senha --must-change-at-next-login

Deletar Usuário:

# samba-tool user delete mundoti

Deletar Usuário e Deletar a sua pasta Home:

# samba-tool user delete mundoti && rm -r /home/samba/mundoti

Listar Todos os Usuários do samba:

# samba-tool user list

Desabilitar o Usuário
com essa opção a conta não pode ser utilizada, mas permanece no servidor:

# samba-tool user disable mundoti

Habilitar Usuário:

# samba-tool user enable mundoti

Expiração de senha do usuário
A expiração de senha para todos os usuários do domínio e feita com outro comando essa altera somente do usuário especificado ( bom para ser usado em certas exceções como por exemplo aquele diretor que insiste em ser uma exceção a regra ) 10 e o numero de dias em que a senha ira expirar:

# samba-tool user setexpiry mundoti --days=10

Desabilitar a expiração de senha:

# samba-tool user setexpiry mundoti --noexpiry

Grupos

Criar um grupo:

# samba-tool group add diretoria

Adicionar Vários Grupos de uma vez:

# samba-tool group add "diretoria diretoria_ead”

Criar um grupo e adicionar um descrição ao grupo:

# samba-tool group add diretoria --description="Grupo da diretoria"

Adicionar um membro a um grupo:

# samba-tool group addmembers diretoria mundoti

Adicionar um Grupo dentro de Outro Grupo
No samba4 podemos adicionar um grupos dentro de outro isso é muito útil

# samba-tool group addmembers diretoria diretoria_ead

Adicionar Vários Membros a um grupo de uma vez só:

# samba-tool group addmembers diretoria "mundoti,mundoti2"

Remover um grupo:

# samba-tool group delete diretoria

Removendo Vários grupos de uma vez:

# samba-tool group delete "diretoria diretoria_ead”

Remover um membro de um grupo:

# samba-tool group removemembers diretoria mundoti

Remover Membros de um grupo:

# samba-tool group removemembers diretoria "mundoti,mundoti2"

Listar todos os grupos:

# samba-tool group list

Listar Usuários pertencente a um grupo:

# samba-tool group listmembers diretoria

In this tutorial, we will be discussing how to restrict SFTP users to their home directories or specific directories. It means the user can only access his/her respective home directory, not the entire file system.

Restricting users home directories is vital, especially in a shared server environment, so that an unauthorized user won’t sneak peek into the other user’s files and folders.

Important: Please also note that the purpose of this article is to provide SFTP access only, not SSH logins, by following this article will have the permissions to do file transfer, but not allowed to do a remote SSH session.

Suggested Read: Restrict SSH User Access to Certain Directory Using Chrooted Jail

The simplest way to do this, is to create a chrooted jail environment for SFTP access. This method is same for all Unix/Linux operating systems. Using chrooted environment, we can restrict users either to their home directory or to a specific directory.

Restrict Users to Home Directories

In this section, we will create new group called sftpgroup and assign correct ownership and permissions to user accounts. There are two choices to restrict users to home or specific directories, we will see both way in this article.

Create or Modify Users and Groups

Let us restrict the existing user, for example tecmint, to his/her home directory named /home/tecmint. For this, you need to create a new sftpgroup group using groupadd command as shown:

# groupadd sftpgroup

Next, assign the user ‘tecmint’ to sftpgroup group.

# usermod -G sftpgroup tecmint

You can also create a new user using useradd command, for example senthil and assign the user to sftpusers group.

# adduser senthil -g sftpgroup -s /sbin/nologin
# passwd tecmint

Modify SSH Configuration File

Open and add the following lines to /etc/ssh/sshd_config configuration file.

Subsystem sftp internal-sftp
 
   Match Group sftpgroup
   ChrootDirectory /home
   ForceCommand internal-sftp
   X11Forwarding no
   AllowTcpForwarding no

Save and exit the file, restart sshd service to take new changes into effect.

# systemctl restart sshd
OR
# service sshd restart

If you chroot multiple users to the same directory, you should change the permissions of each user’s home directory in order to prevent all users to browse the home directories of the each other users.

# chmod 700 /home/tecmint

Verify SSH and SFTP Users Login

Now, it’s time to check the login from a local system. Try to ssh your remote system from your local system.

# ssh [email protected]

Here,

1. tecmint – remote system’s username.
2. 192.168.1.150 – Remote system’s IP address.

Sample output:

[email protected]'s password: 
Could not chdir to home directory /home/tecmint: No such file or directory
This service allows sftp connections only.
Connection to 192.168.1.150 closed.

Then, access remote system using SFTP.

# sftp [email protected]

Sample output:

[email protected]'s password: 
Connected to 192.168.1.150.
sftp>

Let us check the current working directory:

sftp&gt pwd
Remote working directory: /

sftp&gt ls
tecmint  

Here, tecmint is the home directory. Cd to the tecmint directory and create the files or folders of your choice.

sftp&gt cd tecmint
Remote working directory: /

sftp&gt mkdir test
tecmint  

Restrict Users to a Specific Directory

In our previous example, we restrict the existing users to the home directory. Now, we will see how to restrict a new user to a custom directory.

Create Group and New Users

Create a new group sftpgroup.

# groupadd sftpgroup

Next, create a directory for SFTP group and assign permissions for the root user.

# mkdir -p /sftpusers/chroot
# chown root:root /sftpusers/chroot/

Next, create new directories for each user, to which they will have full access. For example, we will create tecmint user and it’s new home directory with correct group permission using following series of commands.

# adduser tecmint -g sftpgroup -s /sbin/nologin
# passwd tecmint
# mkdir /sftpusers/chroot/tecmint
# chown tecmint:sftpgroup /sftpusers/chroot/tecmint/
# chmod 700 /sftpusers/chroot/tecmint/

Configure SSH for SFTP Access

Modify or add the following lines at the end of the file:

#Subsystem  	sftp	/usr/libexec/openssh/sftp-server
Subsystem sftp  internal-sftp
 
Match Group sftpgroup
   ChrootDirectory /sftpusers/chroot/
   ForceCommand internal-sftp
   X11Forwarding no
   AllowTcpForwarding no

Save and exit the file. Restart sshd service to take effect the saved changes.

# systemctl restart sshd
OR
# service sshd restart

That’s it, you can check by logging into the your remote SSH and SFTP server by using the step provided above at Verify SSH and SFTP login.

Be mindful that this method will disable the shell access, i.e you can’t access the remote system’s shell session using SSH. You can only access the remote systems via SFTP and do file transfer to and from the local and remote systems.

Conclusion

Now you know how to restrict users home directories using a Chroot environment in Linux. If you find this useful, share this article on your social networks and let us know in the comment section below if there is any other methods to restrict users home directories.

teste

crie um script e coloque no crontab 1/60 minutos.

vi /bin/up_net.sh

conteúdo script.

!/bin/sh

/sbin/ping -c 5 8.8.8.8
chmod 777 /tmp/FailCount
cat /var/log/system.log | grep -a “date +%d date +%R” | grep -c “allocate llinfo for” > /tmp/FailCount
data=date +%R
FailCount=cat /tmp/FailCount
echo $FailCount
if [ “$FailCount” == “0” ]; then
echo “Error detected in logs. Attempting Repair. $data” >> /tmp/FailCount.txt
ifconfig re0 down
ifconfig re0 up
ifconfig re1 down
ifconfig re1 up
else
echo “Log file doesn’t show arp errors. $data” >> /tmp/FailCount.txt
fi

crontab

1/60 * * * * /bin/up_net.sh

so deixar rodar e o problema esta resolvido princialmente.

Os desenvolvedores do WordPress levam a segurança muito a sério, mas como em qualquer outro sistema, existem potenciais problemas de segurança que podem surgir se algumas precauções básicas de segurança não forem tomadas. Este artigo irá listar algumas formas comuns de vulnerabilidades, e as providências que você pode tomar para manter sua instalação do WordPress segura.

Este artigo não é o guia rápido e definitivo para resolver suas preocupações com a segurança. Se você tem preocupações específicas ou dúvidas, discuta-as com usuários em quem você confie que tenham conhecimento suficiente de segurança em computadores e WordPress.

Contents

• 1 O que é segurança?
• 2 Temas sobre Segurança
• 3 Vulnerabilidades no seu computador
• 4 Vulnerabilidades no WordPress
  • 4.1 Atualizando o WordPress
  • 4.2 Reportar Problemas de Segurança
• 5 Vulnerabilidades no Servidor Web
• 6 Vulnerabilidades na Rede
• 7 Senhas
• 8 FTP
• 9 Permissões de Arquivo
  • 9.1 Modificando as permissões de arquivos
  • 9.2 Sobre as atualizações automáticas
• 10 Segurança do Banco de Dados
• 11 Blindando o wp-admin
• 12 Blindando o wp-includes
• 13 Blindando o wp-config.php
• 14 Criptografia SSL
• 15 Plugins
  • 15.1 Plugins de Firewall
  • 15.2 Plugins que necessitam de acesso para escrita
  • 15.3 Plugins de execução de código
• 16 Segurança por obscuridade
• 17 Backup dos dados
• 18 Guardando registros (Logging)
• 19 Monitorando
  • 19.1 Monitorando seus logs
  • 19.2 Monitorando alterações nos seus arquivos
  • 19.3 Monitorando seu servidor externamente
• 20 Recursos
• 21 Veja Também

O que é segurança?

Fundamentalmente, a segurança não é apenas possuir sistemas perfeitamente seguros, que poderiam muito bem ser impossíveis de encontrar e/ou manter. Um servidor seguro protege a privacidade, integridade e disponibilidade dos recursos que estão sob o controle do seu administrador.

Entre as qualidades de um provedor de hospedagem confiável estão:

• Discutir prontamente as suas preocupações e quais processos e funcionalidades de segurança ele oferece com o serviço de hospedagem.
• Oferecer as versões mais recentes e estáveis de todos os softwares no servidor.
• Oferecer métodos confiáveis para backup e recuperação.

Decida qual abordagem de segurança utilizar no seu servidor pensando primeiro no software e nos dados que precisam ser assegurados. O restante desse guia vai ajuda-lo a fazer isso.

Temas sobre Segurança

Tenha em mente algumas diretrizes gerais enquanto pensa sobre cada aspecto de segurança do seu sistema:Limitar o acessoFaça escolhas seguras que reduzirão os pontos passíveis de invasão por pessoas mal-intencionadas.ContençãoSua instalação deve estar configurada para minimizar o tamanho do estrago que pode ser causado caso o sistema venha a ser comprometido ou invadido.Preparação e conhecimentoMantenha backups e confira o estado da sua instalação do WordPress regularmente. Traçar um plano de backup e recuperação da instalação no caso de uma catástrofe pode ajudar a estar novamente online muito mais rápido caso haja um problema.

Vulnerabilidades no seu computador

Tenha certeza que os computadores que você usa para postar no WordPress estão livres de spyware, malware e outros tipos de infecções e vírus. Toda a segurança do mundo no WordPress e no seu servidor web não farão a menor diferença se houver um keylogger instalado no seu computador.

Mantenha sempre atualizados o seu sistema operacional e os softwares instalados, principalmente o seu navegador, para garantir sua proteção contra vulnerabilidades.

Vulnerabilidades no WordPress

Como muitos dos mais modernos pacotes de software, o WordPress é atualizado regularmente para evitar e resolver novas ameaças que possam surgir. Melhorar a segurança do software é uma preocupação constante, e por isso é importante manter a sua instalação sempre atualizada com a versão mais recente do WordPress. As versões antigas do WordPress não recebem atualizações de segurança.

Atualizando o WordPress

A versão mais recente do WordPress está sempre disponível no site principal em http://wordpress.org e a versão em Português Brasileiro em http://br.wordpress.org. Não existem versões oficiais disponíveis em outros sites – nunca baixe ou instale o WordPress de qualquer outro endereço que não o http://wordpress.org.

O WordPress conta com atualizações automáticas desde a versão 2.7. Use esta funcionalidade para facilitar o processo de atualização constante. Você também pode usar o Painel de Administração para se manter informado dos updates. Leia o artigo indicado no Painel de Administração ou no WordPress Developer Blog para saber quais passos tomar para se atualizar e manter o sistema seguro.

Se uma vulnerabilidade é descoberta no WordPress e uma nova versão é lançada para resolver o problema, a informação necessária para explorar a falha já estará certamente em domínio público. Isto faz com que as versões antigas estejam mais propensas a sofrerem ataques, e é um dos principais motivos pra que você mantenha seu WordPress atualizado.

Se você é um administrador e mantém vários sites com WordPress, considere usar o Subversion para gerenciá-los de forma mais simples.

Reportar Problemas de Segurança

Se você encontrou uma falha de segurança no WordPress, você pode ajudar a soluciona-la reportando o que encontrou. Veja a página Security_FAQ para mais informações sobre como proceder nesse caso.

Se você encontrou um bug, também reporte. Veja como fazer isso na página Submitting_Bugs. Você pode ter descoberto uma vulnerabilidade, ou um bug que pode levar a uma falha.

Vulnerabilidades no Servidor Web

O servidor rodando WordPress, e os outros softwares nele, podem ter falhas de segurança. Por isso, tenha certeza que está rodando versões estáveis e seguras do seu servidor e dos outros softwares instalados, ou contrate um provedor de hospedagem confiável e que cuide desses assuntos para você.

Se você está em um servidor compartilhado (que hospeda mais sites, além do seu) e um outro site no mesmo servidor está comprometido, o seu site também pode, potencialmente, ser atingido, mesmo que você siga todas as dicas deste guia. Pergunte ao seu provedor sobre as medidas de segurança que eles tomam para protegê-lo.

Vulnerabilidades na Rede

Os dois lados da rede — o lado do servidor WordPress e o lado da rede do cliente — devem ser confiáveis. Isso significa atualizar as regras do firewall do seu roteador em casa e também tomar cuidado com quais redes você usa para trabalhar. Uma lan-house movimentada onde você está enviando senhas em uma conexão não-criptografada, wireless ou não, não é uma rede confiável.

O seu provedor de hospedagem deve garantir que a rede dele não seja comprometida por ataques, e você deve fazer o mesmo. Falhas de segurança em redes podem permitir que senhas e outras informações sensíveis sejam interceptadas.

Senhas

Muitas ameaças potenciais podem ser evitadas com bons hábitos de segurança. Uma senha forte é um aspecto muito importante disso.

O objetivo da sua senha é dificultar que outras pessoas possam adivinhar e também para evitar que ataques de força bruta sejam bem-sucedidos. Existem diversos geradores automáticos de senhas que podem ser usados para criar senhas seguras.

O WordPress também tem um medidor de segurança das senhas, que é exibido sempre que você está definindo ou alterando uma senha no WordPress. Use sempre esta ferramenta para garantir que está usando senhas adequadas.

Quando estiver escolhendo uma senha, evite:

• Usar pequenas alterações no seu nome real, nome de usuário, nome da sua empresa ou nome do seu site.
• Usar apenas uma palavra do dicionário, em qualquer idioma.
• Usar senhas curtas
• Usar senhas que tenham somente letras ou somente números (uma combinação dos dois é o ideal).

Uma senha forte não serve só para proteger o seu conteúdo. Um hacker que tenha acesso à sua conta de administração terá poderes para instalar scripts maliciosos que inclusive poderão comprometer todo o servidor.

FTP

Se o seu provedor de hospedagem permitir, prefira sempre usar conexões criptografadas SFTP para acessar o seu servidor. Se você não ter certeza se este serviço está disponível, pergunte à empresa de hospedagem.

Usar o SFTP funciona da mesma forma que o FTP, exceto que a sua senha e outras informações são transmitidas de forma criptografada entre o seu computador e o site. Isso significa que a sua senha nunca é enviada em aberto e então não pode ser interceptada por um hacker.

Permissões de Arquivo

Algumas das funcionalidades mais legais do WordPress precisam da permissão para que alguns arquivos sejam alterados no servidor. No entanto, permitir acesso à alteração de arquivos é um risco em potencial, principalmente em servidores compartilhados.

O melhor a fazer é restringir ao máximo as permissões dos seus arquivos e liberar apenas nos casos em que você precise permitir a escrita, ou criar pastas específicas com menos restrições para algumas atividades, com o upload de arquivos.

Este é um dos esquemas possíveis de permissões:

A sua conta de usuário deve ser a dona de todos os arquivos, e deve ter acesso à escrita em todos eles. Os arquivos que necessitam de escrita pelo WordPress devem estar em um grupo, também pertencente à sua conta de usuário utilizada no servidor./O diretório raiz do WordPress: todos os arquivos devem ter permissão de escrita somente pelo seu usuário, exceto o .htaccess se você quiser que o WordPress gere automaticamente as regras de reescrita para você./wp-admin/A área de administração do WordPress: todos os arquivos devem ter permissão de escrita somente pelo seu usuário./wp-includes/A maior parte da lógica de sistema do WordPress: todos os arquivos devem ter permissão de escrita somente pelo seu usuário./wp-content/Conteúdo inserido pelos usuários: estes arquivos devem ter permissão de escrita por todos os usuários (proprietário/usuário, grupos e público).

Dentro de /wp-content/ você vai encontrar:/wp-content/themes/Arquivos de temas/templates. Se você quiser utilizar o editor de temas do painel de administração, todos os arquivos devem ter permissão de escrita. Se não, todos podem ser escritos somente pela sua conta de usuário./wp-content/plugins/Arquivos de plugins: todos os arquivos devem ter permissão de escrita somente pelo seu usuário.

Outras pastas que podem existir em /wp-content/ devem estar documentadas pelos temas ou plugins que as necessitam. As permissões podem variar.

Modificando as permissões de arquivos

Se você tem acesso ao seu servidor, poderá alterar as permissões de arquivos recursivamente utilizando os comandos a seguir:

Para diretórios:

find /caminho/para/a/pasta/do/wordpress/ -type d -exec chmod 755 {} \;

Para arquivos:

find /caminho/para/a/pasta/do/wordpress/ -type f -exec chmod 644 {} \;

Sobre as atualizações automáticas

Quando você faz uma atualização automática do WordPress, todas as operações são feitas pelo usuário proprietário dos arquivos, não pelo usuário do servidor web. Todos os arquivos são configurados como 0644 e todos os diretórios como 0755, com permissão de escrita somente pelo usuário e de leitura para todos, inclusive o servidor.

Segurança do Banco de Dados

Se você tem vários sites no mesmo servidor, é importante considerar mantê-los em bancos de dados diferentes, cada um gerenciado por um usuários isolado. A melhor hora para fazer isso é na Instalação. Isto é uma estratégia de contenção: se um invasor conseguir quebrar uma das suas instalações do WordPress, essa medida dificultará muito que ele consiga alterar os outros sites.

Se você mesmo administra o MySQL, tenha certeza que compreende bem a configuração do MySQL e desabilite algumas funcionalidades desnecessárias (como aceitar conexões TCP remotas). Leia o artigo Secure MySQL Database Design para uma boa introdução a este assunto.

Blindando o wp-admin

Colocar uma proteção de senha ao /wp-admin/ no lado do servidor adiciona uma 2ª camada de proteção ao redor do seu Painel de Administração, login e arquivos. Isso exige que um invasor ou bot ataque esta segunda camada de proteção, ao invés dos seus arquivos. Muitos dos ataques ao WordPress são feitos de forma autônoma, por softwares e bots maliciosos.

Mas simplesmente bloquear o diretório /wp-admin/ pode desabilitar algumas funcionalidades do WordPress, como o handler de AJAX em /wp-admin/admin-ajax.php. Veja a seção #Recursos para mais documentação sobre a forma correta de proteger seu /wp-admin/ com uma senha.

Os ataques mais comuns a uma instalação WordPress geralmente caem em duas categorias:

1. Enviam pedidos HTTP para o servidor, especialmente programados para explorar a carga útil procurando vulnerabilidades específicas. Estes incluem plugins e softwares antigos ou desatualizados.
2. Tentam ganhar acesso ao seu site usando ataques de “força bruta”, para adivinhar a sua senha.

A melhor implementação dessa segunda camada de segurança por senha é exigir uma conexão criptografada HTTP SSL para a administração do site, de forma que toda a comunicação e dados sensíveis seja criptografada. Veja Administration Over SSL

Blindando o wp-includes

Uma segunda camada de proteção pode ser adicionada nas partes onde os scripts geralmente não devem ser acessados por nenhum usuário. Uma forma de fazer isso é usar mod_rewrite para bloquear os scripts no arquivo .htaccess.

# Block the include-only files.
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
# BEGIN WordPress

Note que isto não deve funcionar bem em instalações MultiSite, já que RewriteRule ^wp-includes/[^/]+\.php$ – [F,L] evitaria que o arquivo ms-files.php gere imagens. Retirar esta linha permitirá o funcionamento, oferecendo um pouco menos de segurança.

Blindando o wp-config.php

Você pode mover o arquivo wp-config.php para o diretório logo acima da sua instalação do WordPress. Assim, para sites instalados na raiz do servidor, o arquivo wp-config.php podera ficar for da área acessível.

Note que o wp-config.php poderá ficar apenas UM nível acima da instalação do WordPress (onde está a pasta wp-includes). Permita também que somente o seu usuário (e o do servidor) possam acessar este arquivo (geralmente isso significa uma permissão 0400 ou 0440).

Se você usa .htaccess no seu servidor, você pode também inserir o código abaixo no arquivo, para negar acesso a qualquer um que esteja navegando atrás dele:

<files wp-config.php>
order allow,deny
deny from all
</files>

Criptografia SSL

Artigo principal: Administration Over SSL.

Plugins

Em primeiro lugar, mantenha sempre todos os seus plugins atualizados. Se você não está mais usando algum plugin, delete os arquivos do servidor.

Plugins de Firewall

Alguns plugins prometem eliminar pedidos suspeitos baseados em listas de regras de bancos de dados e/ ou whitelists. BlogSecurity’s WPIDS plugin instala o PHPIDS, uma camada de segurança genérica para aplicações PHP, enquanto o WordPress Firewall usa algumas regras pré-configuradas, criadas para o WordPress, além de uma whitelist para eliminar ataques sem muitas configurações.

Plugins que necessitam de acesso para escrita

Se um plugin exige permissão de escrita para os arquivos e ou pastas do WordPress, pesquise o código para saber se ele é bem-intencionado, ou confira com algum usuário mais experiente em quem você confie. Se tiver dúvidas, pergunte nos Forums de Suporte e/ou no Canal IRC.

Plugins de execução de código

Como dissemos, uma parte do objetivo de blindar o WordPress é conter o estrago causado quando um ataque tiver sucesso. Plugins que permitem a execução de códigos PHP arbitrários ou outros códigos a partir de entradas no banco de dados aumentam a possibilidade de danos em caso de ataques bem sucedidos.

Uma forma de evitar o uso destes plugins é usar custom page templates que executem as funções. Uma parte da segurança que essa medida garante só é efetiva quando você proíbe a edição de arquivos por dentro do WordPress.

Segurança por obscuridade

Segurança por obscuridade é comumente tida como uma estratégia primária pouco segura. No entanto, existem algumas áreas do WordPress em que obscurescer algumas informações pode ajudar na segurança:

1. Renomeie a conta de administração: Em novas instalações, você pode simplesmente criar uma nova conta de administrador e excluir a conta admin padrão. Em uma instalação já existente, você pode renomear a conta atual pela linha de comando do MySQL usando UPDATE wp_users SET user_login = ‘newuser’ WHERE user_login = ‘admin’;, ou usando um front-end como o phpMyAdmin.
2. Altere o table_prefix: Muitos dos ataques conhecidos que visam invadir sites em WordPress assumem que o table_prefix é o padrão: “wp_”. Modificar isto pode bloquear pelo menos alguns ataques de injeção SQL.

Backup dos dados

Faça backup dos seus dados regularmente, incluindo seus bancos de dados MySQL. Veja o artigo principal: Backing Up Your Database).

A integridade dos dados é crítica para se ter downloads confiáveis. Criptografar o backup, manter registros independentes dos hashes MD5 de cada arquivo de backup e/ou colocar os backups em mídias de somente-leitura aumenta a confiança de que seus dados não foram adulterados.

Uma estratégia segura de backup pode incluir manter um set regular de imagens temporais de toda a sua instalação do WordPress (inclusive os arquivos do core e o banco de dados) em um local seguro e confiável. Pense em um site que faz imagens semanalmente. Uma estratégia como essa significa que se o site for comprometido no dia 1º de Maio mas o dano só for percebido no dia 12, o proprietário terá backups anteriores à data da invasão, que poderão ajudar na re-construção do site e também backups posteriores, que podem ajudar a determinar como a invasão aconteceu.

Guardando registros (Logging)

É possível registar vários pedidos enviados ao WordPress. Os logs padrão do Apache não oferecem muita ajuda para lidar com investigações de segurança. Veja: Mod_Security – Logs and Prevents using Apache

Monitorando

Em alguns casos a prevenção não é suficiente e você pode mesmo assim ser hackeado. É por isso que a detecção/monitoramento de invasões é muito importante. Ela permite que você reaja mais rápido, descubra o que aconteceu e recupere seu site.

Monitorando seus logs

Se você está em um servidor privado (onde você tem acesso de administração), você deve monitorar os logs para descobrir tentativas de quebrar senhas, ataques virtuais e etc. Uma boa solução de código aberto para monitorar os seus logs em tempo real e bloquear os atacantes é a OSSEC.

Monitorando alterações nos seus arquivos

Quando um ataque acontece, ele sempre deixa rastros, seja nos logs ou no sistema de arquivos (novos arquivos, arquivos modificados, etc). Se você está usando OSSEC por exemplo, seus arquivos serão monitorados e você será alertado quando eles forem modificados.

Monitorando seu servidor externamente

Se o invasor tentar desfigurar o seu site, ou enviar malware, você também pode detectar estas alteranções usando uma ferramenta online para o monitoramento de integridade.

Seu domínio está hospedado em um servidor Linux usando o Postfix  para enviar emails e está na lista negra de spam ?

Você provavelmente tem um script malicioso  enviando um grande número de e-mails diretamente do servidor … bem, você pega o inimigo em casa!

Se o seu daemon de e-mail de saída (ou seja, o software usado para enviar e-mails) for o Postfix, você poderá identificar a fonte de spam em apenas algumas etapas simples.

A resolução do problema pode ser igualmente fácil, embora na maioria dos casos precise de mais investigações.

Na verdade, é necessário impedir que a situação ocorra novamente, como se alguém pudesse carregar um script no seu servidor, você pode ter alguma falha de segurança.

A primeira coisa a fazer é fazer logon no servidor de correio com um usuário com direitos administrativos (sudo) e verifique se o arquivo php.ini do seu domínio (e / ou servidor global) contém a seguinte linha:

mail.add_x_header = On

sem o qual o que faremos a seguir não produzirá nenhum resultado útil.

Uma vez verificado isso, você precisará inspecionar a fila de mensagens com o comando:

mailq

Na primeira coluna, você verá o ID exclusivo de cada email de saída, por exemplo:

DA5E8647235C 369763 Wed Mar 29 16:30:19 [email protected]

(connect to somedomain.com[123.123.123.123]:25: Connection refused)

[email protected]

Uma vez identificado um desses e-mails que obviamente é spam, examinaremos seus detalhes com o comando:

postcat -q <ID>

e procuramos uma linha que comece com ” X-PHP-Originating-Script ” (presente graças à linha php.ini mencionada acima).

Por exemplo, usando grep para evitar a rolagem manual do conteúdo do email:

postcat -q DA5E8647235C | grep X-PHP-Originating-Script

poderíamos obter uma saída como esta:

X-PHP-Originating-Script: 45:badmailer.php

O número 45 é o UID, que é o ID do usuário do Linux que executou o script, enquanto badmailer.php é o script que está enviando emails de spam.

Nesse ponto, basta localizar o arquivo badmailer.php, excluí-lo ou limpá-lo e, acima de tudo, para entender como ele foi carregado no seu servidor e executado a partir daí.

Se o seu cabeçalho não contiver a linha X-PHP-Originating-Script, provavelmente sua conta de email foi invadida e é usada para “legitimamente” enviar spam do seu servidor. Nesse caso, identificou um email de saída de spam, você deve iniciar o seguinte comando para ver qual conta foi usada para autenticação:

postcat -q DA5E8647235C | grep sasl_username

Você obterá uma saída como esta:

named_attribute: [email protected]

No exemplo, você deve alterar imediatamente a senha da conta [email protected] por uma senha mais forte (longa, com caracteres especiais, maiúsculas e minúsculas).

Outra coisa que você pode fazer para conter o dano é liberar sua fila de mensagens enviadas com o seguinte comando:

postsuper -d ALL

Se, no entanto, e-mails importantes também estiverem na fila, além de e-mails com spam, você deverá excluir os e-mails indesejados individualmente com o comando:

postsuper -d <ID>

Portanto, no exemplo, lançaremos o seguinte comando:

postsuper -d DA5E8647235C

É isso aí… se você tiver problemas, basta adicionar um comentário a este artigo e tentaremos ajudá-lo!