Liberar Portas Postgres

Evanio
(usa Slackware)

Enviado em 31/10/2017 - 18:57h

Olá pessoal, como meu conhecimento é limitado preciso de ajuda, Apesar de já ter pesquisado muito na internet sobre o assunto porque além de solucionar o problema eu queria aprender, não obtive sucesso, então espero que possam me dar essa força por favor.
A situação é simples mas não consigo resolver, preciso liberar a saída de um SGBD Postgres que está rodando em um CENTOS, tendo um DEBIAN que faz o NAT. Não da para listar aqui o tanto de regras que já tentei sem sucesso, eu fiz todos os DROPS no centos por que estou com problema de invasão e ataques constantes, então as regras que preciso aplicar são, bloquear tudo e liberar apenas o POSTGRES e Samba para sair e entrar! O samba é interno então não tive problemas, a entrada dos POSTGRES tb está OK, só não está tenso saída para a conexão com outro POSTGRES que está na internet. Espero que tenha sido claro. Obrigado

Abaixo minhas regras atuais as outras já deletei:

#!/bin/bash

# Apagando todas as regras
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

# bloquear tudo

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Libera conexões pre-estabelecidas

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Liberar Portas

#samba
iptables -A INPUT -p udp --dport 137 -j ACCEPT
iptables -A INPUT -p udp --dport 138 -j ACCEPT
iptables -A INPUT -p tcp --dport 139 -j ACCEPT
iptables -A OUTPUT -p udp --sport 137 -j ACCEPT
iptables -A OUTPUT -p udp --sport 138 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 139 -j ACCEPT

#Postgres
#liberantrada na porta 5432
iptables -A INPUT -p tcp -s 0/0 -d IPSERVIDOR --dport 5432 -j ACCEPT
iptables -A INPUT -p udp -s 0/0 -d IPSERVIDOR --dport 5432 -j ACCEPT

#libera saida na porta 5432
iptables -A OUTPUT -p tcp -s 192.168.4.250 --sport 5432 -d 0/0 -j ACCEPT
iptables -A OUTPUT -p udp -s 192.168.4.250 --sport 5432 -d 0/0 -j ACCEPT

#iptables -A INPUT -p tcp --sport 5432 -j ACCEPT
#iptables -A INPUT -p tcp --dport 5432 -j ACCEPT
#iptables -A OUTPUT -p tcp --sport 5432 -j ACCEPT
#iptables -A OUTPUT -p tcp --dport 5432 -j ACCEPT

#ssh

iptables -A INPUT -s $192.168.4.0/24 -i $em1 -p tcp --dport 2242 -j ACCEPT

LSSilva
(usa Outra)

Enviado em 31/10/2017 - 22:09h

Acredito que com:

iptables -A FORWARD -i $interfaceredelocal -s $faixaredelocal -p tcp --dport 5432 -o $interfaceinternet -m state --state NEW --syn -j ACCEPT

Evanio
(usa Slackware)

Enviado em 01/11/2017 - 10:37h

Eu testei e não funcionou, não se comunica com o outro banco, a entrada esta ok.

Acredito que com:

iptables -A FORWARD -i $interfaceredelocal -s $faixaredelocal -p tcp --dport 5432 -o $interfaceinternet -m state --state NEW --syn -j ACCEPT [/quote]

LSSilva
(usa Outra)

Enviado em 01/11/2017 - 13:00h

[/quote]
Me explica melhor este cenário seu...
É o centos que está dentro da sua rede que não está conseguindo conectar em um servidor PostgreSQL externo? Se for este o caso, essa regra deveria resolver, digo que quando propus ela, tinha em mente que já havia habilitado o IP_forward no seu router e feito o masquerading. Essa regra que citei deve ser usada no gateway da rede (no seu caso é o Debian) e no centos deve ser feito:
iptables -A OUTPUT -p tcp --dport 5432 -m state --state NEW --syn -j ACCEPT.

Se o cenário for outro muda tudo. E isso cobre apenas sua rede, não cobre a config do server remoto onde está o BD, que deve conter:
iptables -A INPUT -p tcp --dport 5432 -j ACCEPT.

Explica mais detalhado como está funcionando a rede aí.

Evanio
(usa Slackware)

Enviado em 03/11/2017 - 16:40h

Me explica melhor este cenário seu...
É o centos que está dentro da sua rede que não está conseguindo conectar em um servidor PostgreSQL externo? Se for este o caso, essa regra deveria resolver, digo que quando propus ela, tinha em mente que já havia habilitado o IP_forward no seu router e feito o masquerading. Essa regra que citei deve ser usada no gateway da rede (no seu caso é o Debian) e no centos deve ser feito:
iptables -A OUTPUT -p tcp --dport 5432 -m state --state NEW --syn -j ACCEPT.

Se o cenário for outro muda tudo. E isso cobre apenas sua rede, não cobre a config do server remoto onde está o BD, que deve conter:
iptables -A INPUT -p tcp --dport 5432 -j ACCEPT.

Explica mais detalhado como está funcionando a rede aí.
[/quote]

O cenário é exatamente esse, o CENTOS está na rede interna atrás de um DEBIAN que faz o NAT, eu ja fiz o redirecionamento de portas para o INPUT no DEBIAN, as regras de DROP estão todas no CENTOS, quando não habilitadas ele passa normalmente pelo DEBIAN e se comunica a outro CENTOS que roda outro Postgres, mas quando faço o DROP ele apenas recebe, ou seja o INPUT funciona só não consegue sair para se comunicar com o outro Postgres.

Testei sua regra no DEBIAN e reporta um erro de Bad argument com essa regra:

iptables -A FORWARD -i $eth1 -s $192.168.4.0/24 -p tcp --dport 5432 -o $eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

LSSilva
(usa Outra)

Enviado em 03/11/2017 - 21:19h

Onde:
iptables -A FORWARD -i $eth1 -s $192.168.4.0/24 -p tcp --dport 5432 -o $eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Seria:
iptables -A FORWARD -i eth1 -s 192.168.4.0/24 -p tcp --dport 5432 -o eth0 -m state --state NEW -j ACCEPT

Utilizei variáveis na explicação pois não sabia quais eram suas interfaces de rede local e de internet; não daria certo se utilizasse o ESTABLISHED,RELATED, pois você terá que permitir conexões novas, se não houver novas conexões, não haverão conexões correntes.
Nesta correção estou assumindo, pelo seu exemplo, que eth1 é a interface de rede interna, eth0 de internet e 192.168.4.0/24 seu range de rede local.

removido
(usa Nenhuma)

Enviado em 04/11/2017 - 23:00h

Olá,

Vamos por partes...

1. Você postou o arquivo de firewall do debian(firewall) ou do centos(postgres)?
2. Poderia especificar melhor as interfaces de rede? se possível postar o resultado de "ifconfig", ou "ip a" para que possamos indicar as regras...
3. Já verificou se o servidor firewall está na DMZ ou possui uma regra de redirecionamento no roteador?

Evanio
(usa Slackware)

Enviado em 06/11/2017 - 16:41h

Ok, Obrigado pela iniciativa então...

1 - O Firewall postado é do CENTOS estou desconsiderando o DEBIAN pois quando as regras de DROP não estão habilitadas no CENTOS tudo funciona normalmente ou seja IINPUT e OUTPUT passa. Quando rodo esse firewall no CENTOS somente a saída não funciona, pois o outro banco consegue enviar os dados para o que está neste CENTOS.

2 - No CENTOS tenho apenas uma interface (em1 - rede interna), e no debian duas (eth0 - Internet e eth1 - Rede interna).

3 - Quanto a DMZ eu não verifiquei, pq no debian eu tenho um IP comercial desbloqueado, no DEBIAN eu apenas fiz o redirecionamento da porta 5432(postgres) para o ip do servidor CENTOS que está na rede interna.

Obs. Eu acredito que o problema é em relação à saída do CENTOS pq quando o firewall não está ativado ele se comunica normalmente com o outro CENTOS que está na internet então ao meu ver não acho que seja problema de redirecionamento, (espero que eu esteja errado rsrsrsr), acho que o firewall bloqueia a saída da porta do posgres no CENTOS.

Espero que tenho sido claro e obrigado pela atenção dispensada e se não fui eu tento explicar novamente.

removido
(usa Nenhuma)

Enviado em 11/11/2017 - 12:52h

Bom, segue as regras que eu utilizaria...
Aí você adapta conforme precisar

Servidor Postgres
iptables -I INPUT -p tcp --dport 5432 -j ACCEPT
iptables -I OUTPUT -p tcp --sport 5432 -j ACCEPT

Servidor Firewall
iptables -t nat -I PREROUTING -p tcp --dport 5432 -j DNAT --to 192.168.1.100
iptables -I FORWARD -p tcp --dport 5432 -j ACCEPT
iptables -I FORWARD -p tcp --sport 5432 -j ACCEPT

Digitando dessa maneira é pra funcionar, claro, altere o ip 192.168.1.100 para o ip interno do Postgres
Também é interessante especificar as interfaces de rede com as opções -i para INPUT e -o para OUTPUT e ( -i e -o para FORWARD)
Qualquer problema só falar

removido
(usa Nenhuma)

Enviado em 11/11/2017 - 12:56h

Outra coisa, para testar é possível utilizar o nmap: nmap -p 5432 IP
Se aparecer OPEN, também pode ser alguma permissão no banco de dados que não foi concedida..