Port blocking

[Mark Carter]

Supposing I decide to write a server-side application using something
like corba or pyro.

What's the chance that in big corporations, the client's ports (in both
senses of the word: fee-paying, and application) will be blocked,
thereby immediately scuppering whatever I have written? Has this problem
ever arisen for anyone?

Also, is there a good tool for writing database UIs?

 

[Paul Rubin]

Supposing I decide to write a server-side application using something
like corba or pyro.

What's the chance that in big corporations, the client's ports (in
both senses of the word: fee-paying, and application) will be blocked,
thereby immediately scuppering whatever I have written? Has this
problem ever arisen for anyone?

Usually you wouldn't run a public corba or pyro service over the
internet. You'd use something like XMLRPC over HTTP port 80 partly
for the precise purpose of not getting blocked by firewalls.

Also, is there a good tool for writing database UIs?

Yes, quite a few.

 

[Mark Carter]

Usually you wouldn't run a public corba or pyro service over the
internet. You'd use something like XMLRPC over HTTP port 80 partly
for the precise purpose of not getting blocked by firewalls.

Although, when you think about it, it kinda defeats the purposes of
firewalls. Not that I'm criticising you personally, you understand.

Yes, quite a few.

Ah yes, but is there really? For example, I did a search of the TOC of
GTK+ Reference Manual:
http://developer.gnome.org/doc/API/2.0/gtk/index.html
for the word "data", and there's apparently no widget which is
explicitly tied to databases. So in GTKs case, for instance, it looks
like one has to roll one's own solution, rather than just using one out
of the box.

 

[Mark Carter]

Paul Rubin wrote:

I'm not sure if we're talking at cross-purposes here, but the
application isn't intended for public consumption, but for fee-paying
clients.

 

[Diez B. Roggisch]

Usually you wouldn't run a public corba or pyro service over the

internet. You'd use something like XMLRPC over HTTP port 80 partly
for the precise purpose of not getting blocked by firewalls.

What exactly makes sending bytes over port 80 more secure than over any
other port? It has always been my impression that this was to create less
administrative troubles for firewall admins. But its not inherently more
secure. That's a property of the application running.

 

[Grant Edwards]

What exactly makes sending bytes over port 80 more secure than
over any other port?

Nothing.

When has reality had anything to do with the way corporate IT
types configure firewalls?

It has always been my impression that this was to create less
administrative troubles for firewall admins.

It's to give corporate IT types the _illusion_ of security and
relieve them of the need to learn how to configure firewalls.

 

[Ville Vainio]

Mark> I'm not sure if we're talking at cross-purposes here, but
Mark> the application isn't intended for public consumption, but
Mark> for fee-paying clients.

Still, if the consumption happens over the internet there is almost
100% chance of the communication being prevented by firewalls.

This is exactly what "web services" are for.

 

[Steve Holden]

Although, when you think about it, it kinda defeats the purposes of
firewalls. Not that I'm criticising you personally, you understand.

Yet another brilliant Microsoft marketing concept: "Shit, these bloody
firewalls are getting in the way of our new half-baked ideas for
application architectures to replace all that funky not-invented-here
open source stuff we can't charge money for. Let's design something that
completely screws up existing firewall strategies, then we can charge
people extra to firewall the new stuff after we've hooked them all on
yet another inferior execution of existing ideas".

Ah yes, but is there really? For example, I did a search of the TOC of
GTK+ Reference Manual:
http://developer.gnome.org/doc/API/2.0/gtk/index.html
for the word "data", and there's apparently no widget which is
explicitly tied to databases. So in GTKs case, for instance, it looks
like one has to roll one's own solution, rather than just using one out
of the box.

There isn't, IMHO, anything with the polish of (say) Microsoft Access,
or even Microsoft SQL Server's less brilliant interfaces. Some things
Microsoft *can* do well, it's a shame they didn't just stick to the
knitting.

regards
Steve

 

[Steve Holden]

Mark> I'm not sure if we're talking at cross-purposes here, but
Mark> the application isn't intended for public consumption, but
Mark> for fee-paying clients.

Still, if the consumption happens over the internet there is almost
100% chance of the communication being prevented by firewalls.

This is exactly what "web services" are for.

I teach the odd security class, and what you say is far from true. As
long as the service is located behind a firewall which opens up the
correct holes for it, it's most unlikely that corporate firewalls would
disallow client connections to such a remote port.

Web services are for offering services despite the fact that the
corporate firewall managers are valiantly trying to stop unknown
services from presenting to the outside world (and my immediately
preceding post tells you what I think of that idea).

The situation is analogous to connecting to web servers running on
non-standard ports (8000 and 8080 are traditional favorites, but
firewalls very rarely accord them any special treatment).

Most firewall configurations allow fairly unrestricted outgoing
connections, limiting rules to sanity checking of addresses to ensure
nobody inside the firewall is address spoofing. Incoming connections are
usually limited to specific combinations of port number and IP address
known to be legitimate corporate services to the external world.
Firewalling web services effectively is just an additional pain for the
network manager.

regards
Steve

 

[Paul Rubin]

Ah yes, but is there really? For example, I did a search of the TOC of
GTK+ Reference Manual:

Try looking on freshmeat or sourceforge instead.

 

[Ed Leafe]

There isn't, IMHO, anything with the polish of (say) Microsoft Access,
or even Microsoft SQL Server's less brilliant interfaces. Some things
Microsoft *can* do well, it's a shame they didn't just stick to the
knitting.

<shameless plug>Though it's certainly not anywhere near the polish of
Access, you should check out Dabo. It's designed from the ground up to
be a database application framework, and is on its way to achieving
that goal. Right now you still have to do all the UI stuff in code, but
we're just starting to develop the visual UI Designer. Stay
tuned!</shameless plug>

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

 

[Aldo Cortesi]

Thus spake Steve Holden ([email protected]):

I teach the odd security class, and what you say is far
from true. As long as the service is located behind a
firewall which opens up the correct holes for it, it's
most unlikely that corporate firewalls would disallow
client connections to such a remote port.

Don't be too sure about that - most of the well-run
corporate networks I have been involved with block outbound
traffic by default. It is certainly sound security policy to
shunt outbound traffic through intermediary servers (e.g.
SMTP) and proxies (e.g. HTTP and FTP) so that it can be
logged, monitored, tracked, and controlled.

This is the strategy I recommend to my clients - the only
sensible one in a world of spyware, worms, insecure web
browsers and corporate espionage...




Cheers,


Aldo



--
Aldo Cortesi
(e-mail address removed)
http://www.nullcube.com
Off: (02) 9283 1131
Mob: 0419 492 863

 

[Ville Vainio]

Mark> I'm not sure if we're talking at cross-purposes here, but
Mark> the application isn't intended for public consumption, but
Mark> for fee-paying clients.

Steve> I teach the odd security class, and what you say is far
Steve> from true. As long as the service is located behind a
Steve> firewall which opens up the correct holes for it, it's most
Steve> unlikely that corporate firewalls would disallow client
Steve> connections to such a remote port.

Yes, but "clients" might also act as servers, e.g. when they register
a callback object and expect the "server" to invoke something later
on. This is possible (and typical) with CORBA at least. ORBs can use
the same client-initiated connection for all the traffic, but this is
probably somewhere in the gray area.

 

[Mark Carter]

On Jan 10, 2005, at 8:00 PM, Steve Holden wrote:


<shameless plug>Though it's certainly not anywhere near the polish
of Access, you should check out Dabo.

Thanks. I'll look into it.