Início / dba / Perguntas / 220931
Accepted
Basil Bourque
Asked: 2018-10-25 10:34:31 +0800 CST

A configuração do sistema `listen_addresses` no Postgres pode parar as explorações de pré-autenticação?

  • 772

Você pode definir vários parâmetros de configuração para o Postgres editando o postgresql.confarquivo manualmente ou chamando ALTER SYSTEMcomandos.

Uma dessas configurações de configuração é listen_addresses. Para citar a documentação:

Especifica o(s) endereço(s) TCP/IP nos quais o servidor deve escutar conexões de aplicativos clientes. O valor assume a forma de uma lista separada por vírgulas de nomes de host e/ou endereços IP numéricos. A entrada especial * corresponde a todas as interfaces IP disponíveis. A entrada 0.0.0.0 permite escutar todos os endereços IPv4 e :: permite escutar todos os endereços IPv6. Se a lista estiver vazia, o servidor não escuta em nenhuma interface IP, nesse caso apenas os soquetes do domínio Unix podem ser usados ​​para se conectar a ele. O valor padrão é localhost, que permite que apenas conexões locais TCP/IP “loopback” sejam feitas. Enquanto a autenticação do cliente (Capítulo 20) permite um controle refinado sobre quem pode acessar o servidor, listen_addresses controla quais interfaces aceitam tentativas de conexão, que pode ajudar a evitar solicitações repetidas de conexão mal-intencionada em interfaces de rede inseguras. Este parâmetro só pode ser definido na inicialização do servidor.

➥ Isso significa que listen_addressesteoricamente interrompe as explorações de pré-autenticação?

Existe algum envolvimento entre o servidor Postgres e a conexão de entrada que possa resultar em um exploit? Ou a conexão de entrada proibida será bloqueada sem qualquer envolvimento?

É claro que, idealmente, um firewall no sistema operacional do host também estaria instalado para bloquear conexões de entrada indesejadas. Mas vamos ignorar firewalls para o propósito desta pergunta.

postgresql authentication

1 respostas

  1. Best Answer

    listen_addressesfiltra conexões antes que o postgres as veja

    ➥ Isso significa que listen_addressesteoricamente interrompe as explorações de pré-autenticação?

    Sim. Se o postmaster do PostgreSQL não estiver escutando em uma determinada interface (conforme identificado por seu endereço local), nenhum host remoto poderá se conectar a ele por meio dessa interface. O sistema operacional relatará a porta TCP como fechada e enviará um TCP RST para o host de conexão; O código do PostgreSQL nunca é alcançado, então os bugs do PostgreSQL não podem ser explorados, mesmo os de pré-autenticação. 1 .

    listen_addressesbloqueia exploits de pré-autenticação

    Existe algum envolvimento entre o servidor Postgres e a conexão de entrada que possa resultar em um exploit? Ou a conexão de entrada proibida será bloqueada sem qualquer envolvimento?

    No. listen_addressesconfigura o soquete TCP de escuta no nível do sistema operacional, vinculando-o apenas à(s) interface(s) de rede especificada(s) 2 . Ele filtra o endereço de destino da conexão especificado pelo host remoto . O sistema operacional não informa ao PostgreSQL sobre conexões com outras interfaces.

    Observe que o mesmo não é verdade para pg_hba.conf. pg_hba.confcontrola a filtragem de endereço de origem do host remoto e a configuração de autenticação. O postmaster do PostgreSQL lida com qualquer conexão que chega em um endereço de escuta e é então rejeitada pela pg_hba.confconfiguração.

    Você pode fazer a filtragem baseada no endereço do remetente antes que o PostgreSQL veja a conexão configurando as regras de firewall do sistema operacional. Isso impedirá as explorações de pré-autenticação do PostgreSQL, bloqueando a conexão de chegar ao PostgreSQL.

    Portanto, se você sabe que apenas os hosts da rede 111.1.0.0/16 têm algum negócio conectado ao seu PostgreSQL, é uma boa ideia configurar uma regra de firewall de acordo. Você deve definir pg_hba.confcomo um fallback, mas a regra de firewall deve impedir que qualquer pessoa tente se conectar ao próprio postgres.

    Entendendo o fluxo de autenticação

    Para se conectar ao postgres você deve passar por uma série de "portões" do tipo. Ignorando soquetes UNIX para esta explicação, temos:

    • Rede do sistema operacional e nível TCP, antes de acessar o código PostgreSQL:
      • Qualquer roteador de borda ou firewall entre você e o postgres deve permitir a conexão TCP
      • Qualquer firewall do sistema operacional configurado no host postgres deve permitir a conexão TCP
      • listen_addresses- o postgres deve estar escutando na interface ou o SO trata a porta TCP como fechada
      • Quaisquer extensões de segurança de rede como TCP Wrappers ( /etc/hosts.allowe /etc/hosts.deny) devem permitir a conexão. (Supondo que eles sejam suportados em seu sistema operacional e o postgres seja compilado para usá-los)
    • Dentro do código PostgreSQL:
      • Uma regra ou é encontrada ao corresponder por endereço de origem pg_hba.conf host, modo ssl, nome de banco de dados de destino e nome de usuário solicitadohostsslhostnossl
      • A pg_hba.confregra correspondente não deve especificarreject
      • Se as verificações de certificado de cliente SSL estiverem habilitadas, o certificado de cliente SSL satisfará o certificado de CA configurado.
      • O nome de usuário e o nome do banco de dados solicitados devem existir nos catálogos do PostgreSQL
      • O nome de usuário solicitado ou uma função que ele herda deve ter a LOGINopção nos catálogos do PostgreSQL
      • O usuário solicitado deve ter CONNECTdireitos sobre o banco de dados solicitado. (Por padrão, a publicfunção da qual todos os usuários são membros tem CONNECTdireitos, mas você pode REVOKEisso e GRANTapenas para usuários ou funções/grupos específicos).
    • Eba, você se conectou

    Se uma conexão for bloqueada em um estágio anterior, ela nunca interage com estágios posteriores. Eu não verifiquei a ordem exata das verificações de privilégio dbname vs username, mas o resto está certo.

    Eu ignorei pg_ident.confe mapeamentos de nome de usuário, mapeamentos de DN de certificado de cliente, os detalhes de coisas como SSPI/GSSAPI e métodos de autenticação de baixo nível, etc aqui.

    Agora, se você estiver usando soquetes UNIX ( unix_socket_directories, e um libpq hostendereço que é um caminho ou omitido inteiramente), o estágio do PostgreSQL é o mesmo , exceto que a pg_hba.confcorrespondência não verifica o endereço de origem e procura por locallinhas em vez de host, hostsslou hostnossllinhas. O peermodo de autenticação é suportado para exigir um nome de usuário unix para correspondência de nome de usuário postgres. Detalhes no manual.

    Expondo o PostgreSQL à Internet

    Deixe-me observar que as explorações de pré-autenticação para o PostgreSQL não são totalmente desconhecidas , mas são raras. É bastante rotineiro expor o PostgreSQL diretamente na Internet.

    Você deve usar hostsslin pg_hba.confpara impor conexões SSL para proteger as trocas de autenticação e tornar a verificação casual um pouco mais difícil. E você deve adotar as mesmas medidas de proteção que usa para qualquer outro serviço exposto à Internet: use fail2ban ou similar, use um IDS, monitore logs e tenha regras de firewall para excluir qualquer coisa que você saiba que não tenha conexão comercial.

    No entanto , se você não precisa expor o PostgreSQL à Internet, não faça isso. Em particular, se você precisar apenas de conexões de loopback, vincule o PostgreSQL ao(s) endereço(s) de loopback 127.0.0.1e ::1. Ou melhor ainda, use soquetes unix .

    Veja também

    1 O invasor ainda pode explorar bugs do SO na pilha de rede. Ou (muito improvável) eles podem usar truques como falsificação de endereço de origem para enganar um sistema operacional com bugs e permitir que ele envie um pacote inicial para o PostgreSQL mesmo quando estiver vinculado a uma interface diferente. Qualquer sistema operacional moderno e configurado com sensatez impedirá isso.

    2 Internamente, cada listen_addressesentrada é usada para criar um soquete TCP de escuta separado. Para sistemas operacionais do tipo UNIX, ele é passado para a bind(...)chamada em cada soquete. Veja postmaster.cem torno da linha 1012, if (ListenAddresses)e veja o StreamServerPortadaptador em src/backend/libpq/pqcomm.ctorno da linha 532.

    • 4

relate perguntas