From: | "Dan Ostrowski" <dan(at)triad-dev(dot)com> |
---|---|
To: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>, "dan radom" <dan(at)radom(dot)org> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Different Port for PostgreSQL? |
Date: | 2002-09-23 19:20:49 |
Message-ID: | 007d01c26336$568a8e60$0200000a@dan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Yes, and I replied to him. I will try to pump them to get the extra firewall
machine, but I am not sure if they will go for it. running PostgreSQL on
the firewall machine is NOT my preferred measure for sure.
But yes, that was a silly question to ask in retrospect. I will just pipe
ONLY source IPs from the webhost to the DB. Easily done. Sorry. Sometimes
you get a brain lock and you have to ask a dumb question to realize what you
are thinking of wrong.
Thanks for the responces. =)
regards,
dan
----- Original Message -----
From: "Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
To: "dan radom" <dan(at)radom(dot)org>
Cc: <pgsql-general(at)postgresql(dot)org>
Sent: Monday, September 23, 2002 2:03 PM
Subject: Re: [GENERAL] Different Port for PostgreSQL?
>
>
> Ones got to question why you'd have the PostgreSQL port completely open on
the
> external interface at all. You must know the IP address(es) of the
external web
> servers so just enable traffic for them.
>
> As for doing the reject message:
> 1) if you haven't got a listener on a port the kernel's going to reject
the
> connection attempt pretty quickly
> 2) wrap your DB starting and stopping commands with iptable manipulation
to
> enable/disable the web server's traffic as appropiate
>
> On the whole the best solution is Dan's response. You'd manipulate the
firewall
> rules separately to the DB scripts of course but then if you're starting
and
> stopping the DB I see no reason to not require manual intervention in the
> firewall.
>
> --
> Nigel J. Andrews
>
>
> On Mon, 23 Sep 2002, dan radom wrote:
>
> > wouldn't it make sense to use a lower end system as your iptables gw /
fw? i mean hardware is cheap, and iptables has no problems forwarding web
traffic to a httpd on the iternal network that where postgres lives. why
even open the database up to the general internet population when the httpd
only needs to talk to it.
> >
> > dan
> >
> > * Dan Ostrowski (dan(at)triad-dev(dot)com) wrote:
> > > Hello all...
> > >
> > > I am developing a databasing system that will be used localy, but in
tandem with a hosted web server.
> > >
> > > As such, I will be implementing a local PostgreSQL server and
connecting it to the internet. However, this machine ( unfortunately ) will
probably also have to run the firewall as well, but that's all it will be
more than likely.. database and firewall.
> > >
> > > Ideally, I would be able to send a "REJECT" message ( via iptables )
if the connection is refused because the Database is down or somesuch,
instead of just "DROP"ing the connection. This would speed up things for the
web scripts when the DB is unreachable locally. However, port scans will
then be able to easily figure out that I am running PostgreSQL on the
standard port, presumably.
> > >
> > > Is there a way to run Postgre on some other non-standard port? Does it
do well in this regard? How would i go about doing that?
> > >
> > > I know it won't "hack proof" anything really, just make it a bit more
confusing for anyone doing port scans on my machine.
> > >
> > > ideas?
> > >
> > >
> > > regards,
> > > dan
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2002-09-23 19:38:59 | Re: Speaking of dblink |
Previous Message | Jochem van Dieten | 2002-09-23 19:11:22 | Re: How to i18n work with jdbc? |