Por motivos de segurança, é comum alterar a porta do Microsoft Sql Server. O assunto é discutido aqui em Mudar a porta do SQL Server é realmente muito mais seguro?
minha pergunta é: isso também se aplica ao PostgreSQL? Ou não tem relação?
Por motivos de segurança, é comum alterar a porta do Microsoft Sql Server. O assunto é discutido aqui em Mudar a porta do SQL Server é realmente muito mais seguro?
minha pergunta é: isso também se aplica ao PostgreSQL? Ou não tem relação?
As opiniões variam, mas, na minha opinião, é levemente útil usar uma porta não padrão em qualquer serviço exposto à Internet que não seja para uso do público em geral. Alterar sua porta não é segurança. Ele não adiciona absolutamente nenhuma segurança na operação normal e é minimamente útil se sua segurança já estiver comprometida pela descoberta de uma falha de segurança explorável remotamente. Na melhor das hipóteses, é uma opção de atraso e mitigação para dar a você uma chance um pouco maior de corrigir uma falha de segurança antes que um worm a explore.
O uso de uma porta não padrão não o protegerá de vulnerabilidades exploradas ou de qualquer tipo de ataque direcionado. Isso pode ajudar a reduzir as chances de que um worm simples ou um esforço de varredura casual de base ampla tente explorar uma brecha de segurança em seu serviço, mas não atrasará ninguém que esteja interessado em seu sistema especificamente por um piscar de olhos.
Observe que o PostgreSQL não tem o mesmo tipo de histórico de graves falhas de segurança remotamente exploráveis que o MS SQL Server tem. Isso não significa que nunca haverá falhas exploráveis remotamente ou em mecanismos de autenticação de plug-in como Kerberos, portanto, você deve estar sempre pronto para a possibilidade.
Para segurança real, você deve pensar em:
Limitando conexões a máquinas confiáveis. Se o seu banco de dados estiver em uma VLAN que contém apenas a si mesmo e o servidor de aplicativos, não faz sentido brincar com as portas. Da mesma forma, se você não precisar que o banco de dados seja exposto à Internet, certifique-se de que ele não seja executado em um host público ou, pelo menos, configure-o para vincular apenas a um endereço IP interno e desative-o com firewall também.
Proibindo a autenticação de texto não criptografado. Use pelo menos SSL, se não Kerberos ou outro protocolo moderadamente forte.
Autenticação forte ou multifator; nada desse negócio de nome de usuário igual à senha.
Certifique-se de que seus aplicativos nunca usem funções de superusuário e tenham apenas os privilégios mínimos necessários nos objetos de banco de dados com os quais interagem. Seus aplicativos não devem se conectar ao usuário/função que possui o banco de dados ou suas tabelas, a menos que seja absolutamente necessário.
GRANT
lhes os direitos mínimos exigidos.Não permitir conexão remota por funções de superusuário em
pg_hba.conf
Limites de conexão IP. Se todos os clientes da máquina usarem um determinado ISP, use um firewall para descartar conexões de fora dos netblocks IP que você sabe que podem ser usados. Você também pode fazer isso
pg_hba.conf
, mas se fizer isso no firewall, estará impedindo que eles façam um handshake com o Pg.... e muito mais. Há muito na rede sobre como bloquear e proteger Pg. Veja, por exemplo, o artigo de Depesz , a apresentação de Bruce Momjian e este artigo do DeveloperWorks .
Eu altero a porta SSH pública em todas as minhas máquinas por um motivo semelhante. Isso não vai parar ninguém, mas pode desacelerar um pouco os ataques automatizados e os worms. Mais importante, ele reduz o enorme volume de varredura de spam nos logs do meu sistema a ponto de os logs se tornarem úteis novamente.
Eu diria Não , embora, claro, isso não seja tanto uma resposta quanto um princípio. O resultado principal é provavelmente uma falsa sensação de segurança extra.
A pergunta que você precisa fazer é "do que estou tentando me proteger?".
Em geral, em um banco de dados exposto à Internet pública, você não abriria uma porta para o banco de dados - o mundo veria apenas sua camada de aplicativo.
Em bancos de dados que só precisam ser acessados por usuários em sua LAN (e VPN), muitas vezes você precisa de acesso direto ao banco de dados, e este é provavelmente o caso que você tem em mente? A segurança na LAN é um equilíbrio entre conveniência e proteção, e acho que você deve escolher se quer:
No primeiro caso não há necessidade de alterar o número da porta, no segundo, alterar o número da porta não é suficiente.
Pessoalmente, eu olharia para isso somente após todas as outras opções. Por exemplo, firewalls, bloqueando o pg_hba.conf apropriadamente, etc. Pode ser útil, mas está tão longe na lista de ferramentas úteis que eu ficaria preocupado se isso fosse uma distração do resto.