Proteger o servidor na internet

matheusssilva
(usa Fedora)

Enviado em 11/11/2013 - 09:07h

Bem, no ultimo final de semana fui a um evento tecland que ocorreu aqui no meu estado. Um dos palestrastes levantou uma questão na qual meu caso se enquadra.
Ele criticou casos em que o admin configura um servidor ssh ou de banco de dados e deixa o servidor "de cara para Internet", ou seja, sem nenhuma regra de proteção ou isolamento.
Não sou admin de redes, minha área é programação, desenvolvimento, porém, muitas vezes, quando o cliente é de pequeno porte acabamos fazendo o papel de admin também. E creio também que isso é uma proteção básica, que qualquer servidor deve ter.
O que devo fazer para proteger o servidor? Meu conhecimento de iptables é quase nulo.

brunarega
(usa Slackware)

Enviado em 11/11/2013 - 10:07h

Sugiro então que de uma estudada em iptables, é o único jeito, o ideal é sempre ter um firewall entre o link e os servidores de aplicação.

Buckminster
(usa Debian)

Enviado em 11/11/2013 - 13:11h

Para proteção deve-se colocar o firewall (Iptables) "de cara" para a internet. Ou você pode instalar e configurar o Iptables na mesma máquina onde está o servidor que se quer proteger.

Aliás, o Iptables tecnicamente não é um firewall, é um filtro de pacotes que atua diretamente no kernel.
O conceito de firewall envolve uma ´serie de servidores (um filtro de pacotes [Iptables], um proxy [Squid], um IDS, um IPS, um "honey pot", uma DMZ, etc). Porém esse tipo de configuração tem mais necessidade em empresas que requerem maior segurança para proteção de seus dados e que tenham maior possibilidade de ataques. Ou seja, em empresas que são mais visadas para sofrer ataques.

Geralmente, na maioria dos casos, o Iptables e o Squid fornecem a segurança necessária.


Veja o Manuel:
http://www.vivaolinux.com.br/artigo/Manual-do-IPtables-Comentarios-e-sugestoes-de-regras/

souzacarlos
(usa Outra)

Enviado em 11/11/2013 - 13:27h

Boa tarde, vê se isso te ajuda.

Em primeiro lugar tanto faz onde vai ficar teu servidor SSH ele pode sim ficar na máquina/router/dispositivo que fica de cara pra internet, porém com algumas ressalvas...

1º - Vc pode desabilitar o acesso como root em todas as interfaces: vantagens > primeiro vc terá que logar como outro usuário do sistema para só depois poder tentar as diretivas de root.

2º - Como vc mesmo comentou de IPTABLES vc pode também DROP todas as conexões a porta do SSH provenientes da internet.
Obs: eu trocaria também a porta a qual o server SSH escuta.

3º - O serviço SSH permite uma lista de usuários permitidos para login ao serviço, com isso mesmo que o cara descubra a porta de dentro da sua rede local ele mesmo assim precisa autenticar com um usuário desta lista.

São medidas simples mas que com certeza irão diminuir muito suas chances de sofrer um ataque a este serviço.

Abraços.

stefaniobrunhara
(usa CentOS)

Enviado em 11/11/2013 - 13:45h

Não adianta falar só de iptables/squid etc... Porque se você tem acesso externo uma desta etapas ja esta permitindo o acesso remoto.

Um firewall e um conjunto de coisas voltado para a segurança dos seus dados, como nosso amigo Buckminster falou, isto inclui também senha e daemon. Agora partindo do ponto de vista do palestrante, o ponto preocupante do firewall seria senha e daemon, pois afinal você precisa ter o acesso externo.

Se Senha e daemon faz parte do contexto firewall, então você precisa de senha complexa, e daemons (ssh/banco de dados) sempre atualizados, para você não ser vitima de falha de senha fraca e daemon bugado.

No caso da senha como ela pode passar de mãos em mãos, um politica de senha "trocar de tempos em tempos " seria necessário.

matheusssilva
(usa Fedora)

Enviado em 11/11/2013 - 15:46h

Os casos a que me refiro são realmente empresas de micro e pequeno porte, de 2 a 8 máquinas em cada loja, geralmente são farmácias, mini mercados, escritórios, empresas de serviços, etc...
Não posso bloquear o acesso externo do SSH devido ao suporte remoto, o BD também é acessado remotamente.
A confidencialidade de dados não é um requisito crítico, minha preocupação é mais com perda de dados, falha do sistema, etc...

Buckminster vou ver o que posso estar implementando de lá.

estefaniobrunha valeu pelas dicas também. vou tentar criar alguma coisa para realizar essa mudança periódica de senhas.

As dicas 1 e 3 do souzacarlos parecem bem convenientes. Como proceder para implementá-las?

O servidor é Ubuntu Server

Buckminster
(usa Debian)

Enviado em 11/11/2013 - 18:14h

Perda de dados se previne com servidor de backup ou um HD extra na máquina para backup.

Falhas do sistema se previne fazendo boas configurações e fazendo manutenção preventiva no hardware.

souzacarlos
(usa Outra)

Enviado em 11/11/2013 - 19:00h

Boa noite aqui mesmo na comunidade vc encontra material pra configurar essas políticas, e sim vc precisa de uma medida alternativa pra bkp de dados. Uma boa leitura sobre uma ferramenta seria Rsync que dá para gerenciar de forma bem profissional
o bkp de dados críticos.

Matheus não estou entrando no mérito de configuração para justamente lhe dar a oportunidade de estudar a respeito, entendo que vc seja de outra área, porém é interessante entender como funciona o método de acesso de um serviço na pilha de protocolo, até mesmo para futuras interações entre o teu sistema e o ambiente do cliente.

Abraço.

matheusssilva
(usa Fedora)

Enviado em 12/11/2013 - 09:21h

Rotinas de backups já existem, estamos estudando a possibilidade de implantar RAID5 em alguns clientes mais críticos.

Porém, minha preocupação é justamente essa, evitar a necessidade de usar os backups, protegendo a rede de algum iluminado que invada o sistema só para danificá-lo, deletando arquivos, etc.. Nem todo invasor invade como intuito de roubar informações valiosas, até por que ele não encontrará informações relevantes que lhe sirvam para alguma coisa.
Também existem aqueles que invadem com o único objetivo de propagar o caos. É com esses que me preocupo.
Infelizmente não podemos nos ater demais com as questões envolvendo a rede, pois a parte de desenvolvimento nos ocupa por demais, a legislação brasileira é um inferno.
Meu objetivo é fazer o básico, backups, RAID em alguns casos, e alguns procedimentos básicos de segurança, porém deixando o cliente ciente de que existem procedimentos e configurações mais elevadas de segurança e que nesse caso, caso deseje, deve contratar uma empresa especializada na área.
Por isso talvez as instruções 1 e 3 do souza + alguma coisa referente a mudança periódica de senhas seja o que podemos fazer a principio.
A questão sobre serviços na pilha é realmente interessante, talvez não para criarmos rotinas de segurança, e sim porque possibilita um gama de funcionalidades para uma aplicação.

Vou sondada nos assuntos passados aqui. Qualquer dificuldade eu subo o tópico novamente.

souzacarlos
(usa Outra)

Enviado em 12/11/2013 - 11:39h

Bom dia, uma coisa bacana que custumo fazer é o seguinte, existe uma opção do IPTABLES que é tabela "NAT"
dentro desta tabela existem algumas chains onde posso definir coisas tipo destinações de requisições que é o DNAT e o SNAT, com isso é possível:

1 - Que um acesso de um cliente externo ao SSH seja direcionado para um servidor local de dentro da sua rede e somente depois de ter logado neste servidor vc consegue acessar o SSH configurado no computador/dispositivo de borda é uma abordagem bem profissional da ferramenta onde vc coloca uma outra camada de proteção entre o cliente e o servidor onde vc pretende acessar para ex: Atualizar um banco.

Abraço.

stefaniobrunhara
(usa CentOS)

Enviado em 14/11/2013 - 10:06h

Nenhum firewall funciona bem se os daemons não estão bem configurado. Desativar serviços desnecessários é uma boa opção para melhorar a segurança também!

Para Melhorar a segurança do seu sshd

vim /etc/ssh/sshd_config

Usuarios que poder conectar pelo ssh
AllowUsers Estefanio

Não permitir login como root
PermitRootLogin


Se você precisa somente do ssh, desative apache, telnet, postfix, squid, etc... etc... No caso de você não ter um firewall e precisar de um serviços exporta para a internet, o maior risco que você corre e dele ser derrubado por Denial-of-service, a invasão só e uma consequência de falta de atualização e da segurança da senha.

O maior buraco de segurança que eu conheço se chama APACHE+PHP isto mau configurado, é um problemão!!