NYCPHP Meetup

[Chris Bielanski]

I was going to respond the the first letter but I'll combine here...

I wasn't the first to bring up SSL, I just brought up that it seems silly to
reinvent a well-worn wheel for the prospect you raise.

Hopefully I'm not being patronizing when I ask you not to forget that most
firewalls should be able to handle a security protocol such that you can
allow SSL in and out only for specific IP addresses, and further constrain
the ports on which traffic may pass. SSL runs on 443 and not 80, so that's
one problem out of the way. As far as emulating a webserver, there's not
much you can do about that. However, if you have your *own* code running at
both ends, there's nothing to stop you from using private encryption on the
datastream within the SSL tunnel.

~C

> -----Original Message-----
> From: Faber Fedor [mailto:faber at linuxnj.com]
> Sent: Wednesday, March 24, 2004 10:48 AM
> To: NYPHP Talk
> Subject: Re: [nycphp-talk] Secure (XML-RPC) connection
> 
> 
> On Wed, Mar 24, 2004 at 10:03:10AM -0500, Mitch Pirtle wrote:
> > Faber Fedor wrote:
> > 
> > >The client insists that this be done in real-time, so I 
> can't have a
> > >copy of the database on the web server.
> > >
> > >Any ideas?
> > 
> > I am a unix guy, so I don't know how to implement this in 
> the Windows 
> > world - keep that in mind.
> 
> What do I care about Windows?  I'm a Linux guy and all the servers
> involved are Linux. :-)
> 
> > One approach I took in the past was to use ssh and port 
> forwarding (e.g. 
> > forwarding port 9876 on the webserver to 80 on the 
> production machine). 
> >  Then set tcpwrappers to only allow localhost access to port 9876. 
> > That way your xml-rpc calls can go to localhost:9876...
> > 
> > You are now talking on a ssh-encrypted tunnel to the 
> production machine.
> > 
> > Does that fit the bill?
> 
> Sounds good, but how does that stop crackers?
> 
> See, my main concern is that to make this work I have to open 
> a whole in
> the firewall via port forwarding.  Okay, so it's only for port 80, but
> now that that port is open, the production server is exposed.  What's
> stopping a cracker from emulating the Web Server? Putting 
> tcpwrappers or
> iptables on the Prodn Server isn't going to work, since all 
> packets will
> look like they're coming from the firewall (192.168.1.1) and I know of
> no way to differentiate the packets once they've been NATed.
> 
> 
> -- 
>  
> Regards,
>  
> Faber                     
> 
> Linux New Jersey: Open Source Solutions for New Jersey
> http://www.linuxnj.com
> 
> 
> 
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>