GNS3: Ferramenta open source para simulação de redes complexas

Hoje vamos ver uma ferramenta que já está por ai a muito tempo, mas conheci a pouco, o GNS3. Esta ferramenta serve basicamente para simular redes complexas, e obviamente, eu estava procurando algum modo de simular uma rede virtualmente, sem ter de comprar máquinas e equipamentos de rede. O que eu realmente precisava era um modo de melhorar a infra do meu lab de pentest, aquele que postei aqui a muito tempo atrás. Esta configuração que criei com as vm’s do virtualbox ajudou bastante no desenvolvimento dos meus conhecimentos de pentest, mas ela apresenta um problema.

Se você lembra, ou for olhar no outro post, vai ver que todas as vm’s estão configuradas na mesma rede, e a máquina que vai disparar os ataques está na mesma rede também, o que não se parece muito com uma rede real já que temos alguns detalhes a mais como os roteadores, switchs e possivelmente um firewall. Nesta configuração antiga tínhamos contato direto com a maquina alvo, sem nenhum obstáculo. O que o GNS3 vai fazer é trazer esses obstáculos.

Software

O GNS3 é um software open source (GNU GPL) que simula redes virtuais complexas bem próximas das redes reais, tudo isso sem precisar ter um hardware de rede dedicado como por exemplo roteadores e switchs.

GNS3 provê uma interface gráfica intuitiva para organizar e configurar as redes virtuais, pode ser usado computadores convencionais, e tem suporte a diferentes plataformas como Windows, Linux e Mac OS X.

Para poder disponibilizar simulações completas e precisas, o GNS3 usa os seguintes emuladores para emular os mais diversos sistemas operacionais presentes em redes reais:

Dynamips, o conhecido emulador de IOS da Cisco.

VirtualBox, roda os mais diversos sistemas operacionais para desktops e servidores.

QEMU, um emulador open source que pode rodar Cisco ASA, PIX e IPS.

GNS3 é uma excelente alternativa ou ferramenta complementar para engenheiros de rede, administradores e pessoas estudando as certificações Cisco CCNA, CCNP e CCIE, e também Juniper JNCIA, JNCIS e JNCIE. (E para nós do pentest também)

Também pode ser usada para experimentar novas soluções ou testar configurações que precisam ser aplicadas em redes reais.

Outras ferramentas também estão inclusas no GNS3, como conexão da rede virtual com uma rede real ou capturar pacotes usando o Wireshark. E para finalizar, um obrigado ao pessoal do VirtualBox que graças a eles, administradores e engenheiros podem usar o GNS3 para criar labs e testar qualquer coisa em uma rede.

Traduzido e adaptado da Wikipedia

Para mais informações acesse o site do GNS3

Uso

Usaremos o GNS3 aqui para as mais diversas funções entre elas, testar ataques em ambientes próximos da realidade, testar performance de equipamentos de rede, testar firewall, testar ataques  de fora da rede e muito mais.

As duas primeiras coisas que irei testar são um ataque com exploit de fora da rede, como o “Hackear Facebook com o SET" (Sugiro ler os comentários também), e ataques internos e externos a uma rede corporativa.

Para o primeiro ataque usaremos uma organização simples, bem similar a uma rede doméstica, com 2 máquinas com sistemas Windows, sendo um XP e um 7. Não gosto de usar Windows XP em meus labs e testes, ainda mais agora que perdeu o suporte, mas a quantidade de pessoas que infelizmente ainda usam é monstruosa. Este lab será similar ao abaixo: 

Veremos mais adiante como configurar tudo isso, vamos nos focar agora na organização. Temos aqui as 2 vm’s do VirtualBox, um switch e um roteador. Em casa as pessoas normalmente tem apenas um roteador disponibilizado pela operadora que já vem com algumas portas de rede para ligar algumas máquinas e provavelmente também disponibilizando Wireless. 

Estou usando 2 equipamentos para diminuir a configuração, seria um pouco mais complicado configurar e utilizar um desses “tudo em um”. Outro ponto que diferencia nossa rede virtual de uma rede convencional real é o roteador. Estou usando um roteador Cisco c7200, que com algumas pesquisas pode ver que não é nada parecido com o roteador que sua operadora deu a você. :)

Se você ainda não sabe, o firmware do roteador que é disponibilizado pela sua operadora normalmente é ultrapassado e vulnerável, nem perto de um desses da Cisco, tentarei adaptar um firmware mulambo desses no lugar do Cisco.

Configurarei minha máquina atacante fora desta rede, será colocado um roteador ligado ao R1 que simulará a internet, e atrás desse roteador minha máquina atacante.

As máquinas Windows desta rede serão instaladas bem como sabemos que as pessoas normalmente instalam, tudo no default, com softwares comuns e com sistemas de segurança desabilitados.

E o segundo lab, o da rede corporativa, vamos utilizar um modelo similar ao seguinte:

Aqui as coisas começam a ficar interessantes, teremos em torno de 8 vm’s rodando ao mesmo tempo. Vai ser necessário uma máquina relativamente boa para aguentar tudo isso ao mesmo tempo, o recomendado seria algo em torno de 16GB de RAM, processador intel i7 e 1TB de HD, mas estou rodando com 8GB de RAM, processador intel i5 e 500GB de HD e até o momento está rodando tudo bem.

Dica: Coloque o minimo possível de recurso em cada vm para que seja suficiente para ligar e funcionar, por exemplo, os clientes Linux podem rodar com 256MB de RAM sem problemas.

Então vamos lá, nessa rede temos a máquina externa como na anterior, que vai ser a vm que iremos disparar os ataques, mas em alguns casos podemos testar com uma interna também. Teremos o roteador que não está aparecendo na imagem e logo após ele o firewall. Nessa máquina de firewall será configurado um firewall funcional em Linux, na verdade, todos os servidores serão Linux. 

Seguindo em frente teremos a máquina DMZ que terá diversos serviços como por exemplo, DNS, email, FTP e servidor Web. 

A máquina Audit serve para questões de auditoria da rede e servidor de logs.

A máquina Storage como o nome sugere será um fileserver e backup.

O servidor Datacenter terá também diversos serviços como por exemplo LDAP, SMB, DHCP, MySQL e outros.

E por fim, as máquinas dos funcionários de nossa empresa, tendo pelo menos uma vm Linux e uma vm Windows.

Criarei um post e possivelmente um vídeo com a configuração do roteador e das vms, aguarde!

Separei em diversos posts porque iria ficar muuuuuito grande para um só.

Read More

10 dicas para manter seu servidor web Apache seguro

Se por acaso você tiver um servidor web confira aqui 10 dicas para deixar seu servidor mais seguro.

1. Desative módulos desnecessários

Se você está instalando o apache pelo seu código fonte você deve desativar alguns módulos. Se você usar o ./configure —help você verá todos os módulos que podem ser ativados ou desativados. Antes de desativar confira se não vai necessitar de um desses módulosOs principais são:

userdir – Mapeamento de diretórios específicos de usuários
autoindex – Lista os diretórios quando o index.html não estiver presente
status - Mostra o status do servidor
env - Limpar e configurar variáveis de ambiente
setenvif - Colocar variáveis de ambiente nos cabeçalhos
cgi - Scripts CGI
actions - Ações disparadas em certas requisições
negotiation - Negociação de conteúdo
alias - Mapeamento de requisições para diferentes sistemas de arquivos
include - Declarações server side
filter - Filtro de requisições
versão - Manipulação de informações de versão e arquivos conf
as-is - arquivos as-is

Desabilite isso tudo na hora do comando ./configure, conforme exemplo:

./configure \
--enable-ssl \
--enable-so \
--disable-userdir \
--disable-autoindex \
--disable-status \
--disable-env \
--disable-setenvif \
--disable-cgi \
--disable-actions \
--disable-negotiation \
--disable-alias \
--disable-include \
--disable-filter \
--disable-version \
--disable-asis

Se você habilitar o ssl, terá de habilitar o mod_setenv, se não receberá o erro:

Error: Syntax error on line 223 of /usr/local/apache2/conf/extra/httpd-ssl.conf: Invalid command ‘BrowserMatch’, perhaps misspelled or defined by a module not included in the server configuration

Após a instalação, você pode ver o que está instalado com o comando httpd -l:

/usr/local/apache2/bin/httpd -l
Compiled in modules:
core.c
mod_authn_file.c
mod_authn_default.c
mod_authz_host.c
mod_authz_groupfile.c
mod_authz_user.c
mod_authz_default.c
mod_auth_basic.c
mod_log_config.c
mod_ssl.c
prefork.c
http_core.c
mod_mime.c
mod_dir.c
mod_so.c

Neste caso, temos os seguintes módulos instalados:

core.c – Módulos principais do apache
mod_auth* – Módulos para autenticação
mod_log_config.c – Módulo para tratamento de logs
mod_ssl.c – Para SSL
prefork.c – Para MPM
httpd_core.c – Módulos principais do apache
mod_mime.c – Configurações do MIME
mod_dir.c – Módulo para redirecionamentos de diretórios para a index.html
mod_so.c – Para iniciar módulos no início e reinício

2. Rode o apache em um usuário e grupo separado do resto

Por padrão, o apache roda como nobody ou daemon. É bom rodar o apache com seu próprio usuário sem privilégios. Por exemplo um usuário chamado apache.

Vamos então criar o usuário e o grupo e configurar para ser o padrão do apache

groupadd apache
useradd -d /usr/local/apache2/htdocs -g apache -s /bin/false apache

vi httpd.conf
User apache
Group apache

Após isso, reinicie o apache, e com o comando ps -ef você verá que o apache está rodando no usuário apache.

3. Restrinja o acesso aos diretórios (com deny, allow)

Para isso, defina isso no arquivo httpd.conf:

Options None
Order deny,allow
Deny from all

Isto quer dizer:

Options None – Marcando isto como None vai evitar que alguma opção a mais seja habilitada
Order deny,allow – Isso é como as ações deveram ser seguidas. Usando deny,allow, todas as funções deny serão executadas por primeiro.
Deny from all – Isso remove o acesso a todos dos diretórios raiz. Como não tem nenhuma opção allow todos permanecem sem acesso a raiz.

4. Defina permissões apropriadas para os diretórios conf e bin

Estes diretórios devem ser acessados apenas por usuários autorizados. É uma boa idéia criar um grupo e adicionar todos os usuários que devem acessar e bloquear para todo o resto. Vamos chamar esse grupo de apacheadmin.

groupadd apacheadmin

chown -R root:apacheadmin /usr/local/apache2/bin
chmod -R 770 /usr/local/apache2/bin

chown -R root:apacheadmin /usr/local/apache2/conf
chmod -R 770 /usr/local/apache2/conf

vi /etc/group
apacheadmin:x:1121:user1,user2

5. Remova navegação por diretórios 

Se você não fizer isso, todos os usuários poderão ver todos os arquivos e diretórios, desde a raiz.


Para isso apenas precisamos colocar o None ou -Indexes como parâmetro nos arquivos de configuração:

Options None Order allow,deny Allow from all

ou

Options -Indexes
Order allow,deny
Allow from all

6. Não libere o .htaccess 

Usando o .htaccess dentro de um diretório, os usuários podem reescrever todas as diretivas do apache. Em algumas situações isso é bom, mas este arquivo deve ser evitado.

Precisamos usar a opção "AllowOverride None" para remover o .htaccess:

Options None
AllowOverride None
Order allow,deny
Allow from all

7. Desabilite outras opções

Segue algumas outras opções:


Options All – Todas as opções são habilitadas (exceto MultiViews). Se você não especificar nada, este é o estado padrão.
Options ExecCGI – Executa os scripts CGI (uses mod_cgi)
Options FollowSymLinks – Se você tiver links simbólicos eles serão seguidos
Options Includes – Permite includes server side (usando mod_include)
Options IncludesNOEXEC – Permite includes server side sem a possibilidade de rodar comandos ou scripts
Options Indexes – Remove a listagem de diretórios
Options MultiViews - Permite content negotiated multiviews (usando mod_negotiation)
Options SymLinksIfOwnerMatch – Similar ao FollowSymLinks. Mas, apenas se o dono do link e do diretório que aponta são os mesmos

Nunca especifique ‘Options All’. Sempre use uma ou mais das opções acima (você pode usar várias em conjunto).

Veja alguns exemplos:

Options Includes Indexes
AllowOverride None
Order allow,deny
Allow from all

Options -Includes +FollowSymLink
AllowOverride None
Order allow,deny
Allow from all

8. Remova os módulos DSO desnecessários

Se você carregou algum módulo dinâmico compartilhado no apache, ele estará presente dentro do httpd.conf dentro de "LoadModule".


Comente todas as linhas desnecessárias.

9. Remova o acesso a uma rede específica

Se você quer que seu site seja visto apenas por um range de ip específico ou por uma rede use o seguinte: 

Options None
AllowOverride None
Order deny,allow
Deny from all
Allow from 10.10.0.0/24

Ou

Options None
AllowOverride None
Order deny,allow
Deny from all
Allow from 10.10.1.21

10. Não mostre e nem envie informações com a versão do apache

Por padrão, um servidor HTTP responde nos cabeçalhos a versão do apache e do php. Isso a princípio é inofensivo, mas se pudermos remover essa informação de um possível atacante podemos melhorar nossa segurança.

vi httpd.conf
ServerTokens Prod

Segue abaixo alguns possíveis valores:

ServerTokens Prod displays “Server: Apache”
ServerTokens Major displays “Server: Apache/2″
ServerTokens Minor displays “Server: Apache/2.2″
ServerTokens Min displays “Server: Apache/2.2.17″
ServerTokens OS displays “Server: Apache/2.2.17 (Unix)”
ServerTokens Full displays “Server: Apache/2.2.17 (Unix) PHP/5.3.5″ (Se você não especificar nenhum ServerTokens este será o valor padrão)

Fonte: r00tsec

Read More

Lynis - Ferramenta para auditoria de sistemas unix/linux

Estava dando uma estudada em hardening em unix/linux e outras coisas relacionadas a segurança e acabei encontrando o post sobre o Lynis lá no Coruja de TI.

Um aluno me perguntou sobre uma ferramenta que pudesse auxilia-lo quanto a verificação das configurações feitas em um servido linux focando em segurança, no caso, ele está fazendo o hardening do servidor.
De cara, eu pensei no Lynis. Uma ferramenta opensource bem interessante que faz uma boa varredura a procura de possíveis falhas no seu sistema operacional. E vejam a lista de sistemas que ele, o Lynis, é compatível:

Arch Linux

CentOS

Debian

Fedora Core 4 and higher

FreeBSD

Gentoo

Knoppix

Mac OS X

Mandriva 2007

OpenBSD 4.x

OpenSolaris

OpenSuSE

PcBSD

PCLinuxOS

Red Hat, RHEL 5.x

Slackware 12.1

Solaris 10

Ubuntu

Vejam a tela do Lynis no momento do seu scanner:

A sua instalação é bem simples, basta executar os comandos abaixo:


wget http://www.rootkit.nl/files/lynis-1.3.0.tar.gz
tar xvfvz lynis-1.3.0.tar.gzsudo /opt/lynis-1.3.0/lynis --check-all -Q

Agora olhem as categorias que o Lynis varre no sistema operacional:

System tools: system binaries

Boot and services: boot loaders, startup services

Kernel: run level, loaded modules, kernel configuration, core dumps

Memory and processes: zombie processes, IO waiting processes

Users, groups and authentication: group IDs, sudoers, PAM configuration, password aging, default mask

Shells

File systems: mount points, /tmp files, root file system

Storage: usb-storage, firewire ohci

NFS

Software: name services: DNS search domain, BIND

Ports and packages: vulnerable/upgradable packages, security repository

Networking: nameservers, promiscuous interfaces, connections

Printers and spools: cups configuration

Software: e-mail and messaging

Software: firewalls: iptables, pf

Software: webserver: Apache, nginx

SSH support: SSH configuration

SNMP support

Databases: MySQL root password

LDAP services

Software: php: php options

Squid support

Logging and files: syslog daemon, log directories

Insecure services: inetd

Banners and identification

Scheduled tasks: crontab/cronjob, atd

Accounting: sysstat data, auditd

Time and synchronization: ntp daemon

Cryptography: SSL certificate expiration

Virtualization

Security frameworks: AppArmor, SELinux, grsecurity status

Software: file integrity

Software: malware scanners

Home directories: shell history files

Dois pontos interessantes quanto a utilização desta ferramenta são os seguintes:

Sugestões passadas por ele na hora do scanner – grep Suggestion /var/log/lynis.log

Os avisos de perigo no momento do scanner – grep Warning /var/log/lynis.log

Fica a dica para galera.

Fonte: Coruja de TI

Read More

SSH Hardening: como melhorar a segurança do seu SSH

O hardening, na área de segurança, é o processo de se aumentar a segurança de um serviço ou servidor como um todo através de configurações finas do sistema. Esta é talvez a tarefa mais importante pela qual você é responsável como um administrador de redes ou sistemas e deve ser feita em novos servidores ou mesmo em servidores que já estão em produção para reduzir os riscos a que você está expondo os seus dados.

Todo sistema operacional e todo serviço rodando nele possuem configurações para melhorar a segurança (ainda que muito pouco). No post de hoje você vai aprender a melhorar a segurança do SSH, um dos serviços mais importantes e populares presente em 99% dos servidores Unix.

NOTA: Tirando os itens “Usar port knocking” e “Se mantenha atualizado”, todas as configurações mostradas abaixo podem ser feitas através do arquivo sshd_config. Geralmente este arquivo está localizado no /etc/ssh, porém a localização na sua distribuição pode variar.

Não permitir login como root

Permitir que o root faça login via SSH é o maior erro que um administrador pode cometer. Primeiro, isso já facilita a vida do atacante pois ele não precisa adivinhar o nome de usuário do qual ele vai tentar adivinhar a senha já que ele pode usar o root, que é o padrão em todo sistema *nix (e descobrir qual sistema operacional está sendo executado por um host não é tão difícil assim. Basta um scan com NMap para descobrir). Segundo, se ele vier a adivinhar a senha, já era. Ele tem poder total no seu sistema e você não pode fazer mais nada pra segurar ele.

Felizmente, impedir que o root faça o login no sistema é bem simples. No arquivo sshd_config procure pela linha PermitRootLogin e mude para “no”:

PermitRootLogin no

Assim, outros usuários poderão fazer o login via SSH porém a conta root não conseguirá. Não se esqueça de criar um outro usuário no sistema e adicioná-lo a um grupo que tenha permissões para logar remotamente (veremos como fazer isso abaixo) para que você consiga usar o SSH.

Definir quais grupos e/ou contas de usuários podem fazer login via SSH

Além de impedir que o usuário root faça o login remotamente via SSH, é uma boa ideia que você também especifique quais usuários e/ou grupos podem fazer o login remoto. Para isso, existem algumas opções que você deve encontrar (ou adicionar) no arquivo de configuração:
AllowUsers
DenyUsers
AllowGroups
DenyGroups

Basta colocar os nomes de usuários ou grupos separados por espaço seguido das opções que começam com Allow para permitir o login ou das opções que começam com Deny, para bloquear o login:
AllowUsers joao maria jose
Denygroups rh controladoria visitantes

Assim, escolhendo a opção correta, fica bem simples controlar quem pode e quem não pode fazer o login.

Não permitir senhas em branco

Não permita que senhas em branco sejam aceitas pelo sistema. Acho que o motivo é óbvio, né? Para impedir que senhas em branco sejam aceitas, procure pela linha PermitEmptyPasswords e mude o valor para “no”:

PermitEmptyPasswords no

Fazer autenticação com chaves e não senhas

Esta dica vale ouro e passar a usar chaves ao invés de senhas sozinho já aumenta e muito a segurança do seu sistema. Já expliquei passo a passo como fazer esta configuração no post “SSH sem senha: autenticação através de certificados RSA“.

Recomendo que você vá lá e dê uma lida para apender a configurar mais esta proteção para o seu sistema.

Usar port knocking

O port knocking é um esquema muito interessante. Quando configurado adequadamente, ele fará com que uma determinada porta só seja aberta depois de o host enviar pacotes para um conjunto específico de portas e na ordem correta. Como existem mais de 65 mil portas em um sistema, adivinhar a combinação é bem complicado! É uma boa ideia combinar o port knocking com a dica de fazer com que o SSH use uma outra porta que não a 22.

Já fiz um post bem detalhado sobre como configurar o port knocking em “SSH Port Knocking“. Dê uma lida lá para mais informações sobre como implantar esta medida de segurança no seu servidor.

Forçar o uso da versão 2 do protocolo

A versão 1 do protocolo SSH possui falhas seríssimas de segurança que minam qualquer medida que você tome para aumentar a segurança do sistema. Por isso, você deve sempre forçar o uso da versão 2 do protocolo onde possível. Para isso, procure pela linha Protocol no sshd_config e deixe ela assim:

Protocol 2

Assim, o seu servidor SSH vai exigir que apenas a versão 2 do protocolo (considerada segura enquanto escrevo este texto) seja usada.

Modificar a porta padrão

Muitos atacantes fazem robôs que varrem a Internet fazendo um sweep atrás de hosts com a porta 22/TCP aberta. Isso facilita a vida pois identifica rapidamente hosts que podem ter o SSH habilitado e aceitando conexões de qualquer host na Internet. Se você não utilizar a porta padrão 22 (nem uma variação boba, tipo 2222) você já consegue se livrar de vários destes robôs, podendo ficar mais tranquilo.

Para mudar a porta na qual o SSH vai escutar, procure a linha Port logo no começo do arquivo e mude o valor dela para qualquer outro que esteja livre no seu sistema (de preferência, use valores de portas maiores que 1024):

Port 35670

Lembre-se que, depois de mudar a porta padrão do serviço, você vai precisar especificar a porta correta quando for se conectar via PuTTY ou mesmo usando o cliente SSH na linha de comando:

$ ssh -p 35670 usuario@192.168.0.1

Ignore o arquivo .rhosts

O arquivo .rhosts era utilizado para identificar hosts nos quais o seu servidor confia. Este arquivo servia principalmente para configurar o conjunto de ferramentas comumente apelidado de “rtools”: rsh, rcp, rlogin, rwho e rexec. Todas estas em desuso atualmente, principalmente por causa da falta de segurança que acaba causando muita dor de cabeça.

Enfim, como as ferramentas não são mais utilizadas justamente por não serem seguras, nós podemos falar para o sistema não confiar mais no rhosts. Como? Assim:
IgnoreRhosts yes
RhostsAuthentication no
RhostsRSAAuthentication no

É muito provável que o arquivo de configuração do seu servidor já tenha estas opções configuradas dessa maneira. Mas é sempre bom ter certeza de que tudo está certo, por isso é uma boa ideia verificar e ficar tranquilo! :)

​

Ative os timeouts

É muito comum que durante o dia nós precisemos sair das nossas mesas para irmos a alguma outra sala, tomar uma água, ir ao banheiro, etc. Nestas ocasiões, nem sempre nos lembramos de bloquear a nossa máquina onde estamos conectados ao servidor via SSH. O que, obviamente, é um grande risco para a segurança.

Por isso, é sempre interessante que você configure um timeout que irá desconectar do servidor depois de um tempo de inatividade. Para isso, edite ou adicione as seguintes linhas:
ClientAliveInterval 300
ClientAliveCountMax 3

O parâmetro informado em “ClientAliveInterval” deve ser informado em segundos. No exemplo acima, a conexão seria finalizada se o cliente ficasse inativo por mais de 300 segundos (ou 5 minutos). A opção ClientAliveCountMax define a quantidade de mensagens de “client alive” (parecido com um heartbeat, usado para saber se a outra ponta da conexão está ativa ou não) que podem ser enviadas para o cliente sem que este envie alguma resposta. O valor padrão é três. O efeito disso está descrito na página de manual do SSH (traduzido livremente por mim):

“Se ClientAliveInterval for configurada para 15, e ClientAliveCountMax é deixada no valor padrão de 3, clientes SSH que não responderem serão desconectados em aproximadamente 45 segundos.”

Use o sudo

Não só não é bom deixar que o root faça login via SSH, como também não é bom que qualquer usuário (por mais experiente que seja) use esta conta no dia-a-dia. O ideal é que você instale e configure o sudo nos seus servidores para que cada usuário use a sua própria conta e para que todas as atividades executadas com poderes de root sejam devidamente logadas.

Já detalhei bastante a configuração do sudo no post “Como configurar e usar o sudo“. Recomendo que você vá lá e dê uma boa lida em como fazer e implante a ferramenta no seu servidor assim que possível!

Se mantenha atualizado

Deixar o seu sistema desatualizado vai fazer com que você fique vulnerável mesmo que siga à risca todas as dicas acima. É importantíssimo que você sempre utilize as versões mais recentes de todos os softwares instalados na máquina e que aplique as correções de segurança assim que elas são disponibilizadas.

Porém, cuidado ao aplicar patches e instalar novas versões em sistemas que estão em produção pois isso pode acabar fazendo com que o serviço em questão pare de funcionar. O ideal é que você utilize máquinas virtuais que imitam o ambiente de produção e teste tudo nestas VMs antes de aplicar as correções ou instalar novas versões no host de produção. Isso já diminui muito a chance de alguma coisa dar errado e você consegue se manter seguro.

Não seja preguiçoso: assim que patches forem lançados, teste e os aplique nos seus hosts.

Reinicie o serviço depois de fazer todas as configurações!

Depois que você analisar todas as dicas acima e adaptá-las ao seu ambiente, salve e feche o arquivo sshd_config. Para fazer com que todas as alterações entrem em vigor você vai precisar reiniciar o serviço. O modo de reiniciar o serviço varia um pouco de distribuição para distribuição. No Ubuntu e no CentOS você pode usar o comando service:

# service sshd restart

A diferença é que no Ubuntu você precisa colocar o “sudo” na frente do comando para executá-lo como root.

Conclusão

O hardening não é o tipo de coisa que você pode deixar pra depois. Em novos servidores, é interessante que você tenha uma checklist de tudo o que é necessário fazer para ter um servidor mais seguro assim que ele entrar em produção. Porém, também é necessário que você faça o hardening em servidores que já estão em produção. Estes são os seus principais alvos já que eles já oferecem riscos à sua infra por estarem em produção sem as devidas medidas de segurança.

No geral, aquelas dicas de sempre também valem: mantenha seus servidores sempre atualizados; configure o seu firewall corretamente; não seja preguiçoso, faça tudo da maneira segura e não da maneira fácil e conheça bem a sua rede e as ameaças.

​

​Creditos: Pedro Pereira

Read More