Re: How can I make the server to call back to client without being blocked by firewall.

From: jeff Lee (jeff-lee@attbi.com)
Date: 10/02/02 

From: "jeff Lee" <jeff-lee@attbi.com>
Date: Wed, 02 Oct 2002 04:36:24 GMT

Thanks a lot Robert and Emil.

Another question though. Since UDP can also be in connection mode even
though it's not exactly
the same with TCP, can client make a UDP connection and keep it open
so that server can send some data back without being blocked by firewall?

Regards,

Jeff

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
news:bea2590e.0210011612.256f376a@posting.google.com...
> "jeff Lee" <jeff-lee@attbi.com> wrote in message
news:<le6m9.1818$aw.1027@sccrnsc03>...
> > Thanks David.
> >
> > Since there are tons of commercial applications available,
> > how can we pick a port which is guaranteed to be usable?
>
>
> Assuming a sane network/firewall administrator:
>
> By default, *no* inbound TCP ports will be open to client machines.
> And they will be loath to open any without darn good reason (the FTP
> data channel is the one semi-common exception, and most firewalls
> special case that anyway).
>
> In shops with a fairly relaxed outlook, clients may be able to
> generally be able to establish outgoing TCP sessions on any port.
> Most, however, are not so liberal, and by default restrict clients to
> only well defined services (eg. HTTP, FTP, etc.). Usually there's not
> too much of an issue getting an outgoing port opened for a specific
> application, especially if there are a restricted number of servers
> (eg. you can tell the firewall administrator that the clients only
> need port 1234 access to the machines at 1.2.3.4 and 1.2.3.5).
> Sometimes, especially in more security conscious environments, you may
> not even be able to get a limited outgoing port opened.
>
> Some shops prevent *all* direct external access by client machines,
> and all must go through a proxy. Usually, it's not too hard to get
> the proxy configured to allow a new outgoing services, again
> especially to a restricted number of hosts, and most proxies support
> SOCKS, so doing that in your application is not too hard. While
> support for a back channel is possible on most proxies (and there's
> specific support in SOCKS), it's rare that anyone will open such a
> thing for any but the most restricted usage.
>
> In short, your odds of getting an inbound TCP connection to a desktop
> at most shops is minimal. And while getting an outgoing connection
> isn't usually too hard, it will often be through a proxy.
>
> The one exception to this is if your central site and the end user's
> site are connected via a VPN of some sort, in which case inbound
> connections may not be too big a deal.
>
> If you have your own server or proxy that you can install on the
> shop's DMZ or service network, getting inbound access to that isn't
> usually too much of a problem, but you'll still have trouble trying to
> get inbound access from that server (having the clients contact the
> server will still be much easier). The big advantage of that
> configuration is that having a fairly rapid poll by the clients isn't
> usually much of problem if the server/proxy is local.
>
> A minimal number of servers on the internal network is usually
> possible if the application is valuable enough, but it'll generally
> require some tight controls on access (only specific source hosts,
> etc.), and often you'll end up with a VPN of some sort anyway.
>
> And a general comment: I don't know what kind of data you moving
> around, but the more security conscious shops will not like
> potentially valuable or confidential data moved over the internet
> without proper encryption and authentication.
>
> I'll also second David's comment about trying to tunnel through and
> existing port or protocol. Yes it's technically possible, and yes
> security administrators will hate you for it. They will view it,
> quite rightly, as a deliberate attempt on your part to subvert their
> companies security policy, the policy that they *personally* are
> responsible for implementing. Keep it simple: a nice, well defined
> outgoing (proxiable) TCP port is usually pretty palatable (perhaps
> requiring encryption). But if your end user in the company can't
> convince their security administrators to permit that kind of access,
> you've stepped into a major political minefield. Annoying the
> security folks by tunneling through their firewall is not likely to
> help your overall prospects at the site. If you do run into that
> situation, it's usually best to approach the security folks directly
> (with your user's permission, of course), and find out what their
> requirements are. This gets pretty technical, and an attempt to
> filter that negotiation through an end user is pretty much doomed.
> Also, the security folks are often more inclined to talk to a polite
> and technically savvy vendor than an end user who views the security
> folks merely as an impediment (and usually lets them know it).
>
> One other thing: if you end up leaving a long standing TCP connection
> from the client open to the server, make sure you kick a byte or two
> of data over it every ten minutes or so. Many firewalls timeout and
> drop idle TCP sessions (for example the Firewall-1 default is 20
> minutes).

Relevant Pages

  • [NEWS] Cisco PIX TCP Connection DoS
    ... Get your security news from a reliable source. ... By crafting a special TCP packet and sending it to a vulnerable Cisco PIX, ... embryonic connection open until the embryonic connection timeout which is ...
    (Securiteam)
  • Re: Socket Programming
    ... > Antony> and the data from two different clients is sent to the appropriate ... above two people regarding the relation between sockets and the TCP ... the server accepts the connection. ... the server gets a new socket bound to a *different port*. ...
    (comp.lang.lisp)
  • Re: How can I make the server to call back to client without being blocked by firewall.
    ... I tend to think you would be on the right track suggesting a single TCP ... the clients have to be logged in to make or receive ... > connection to any one of others via our server. ...
    (comp.security.firewalls)
  • Re: IP aliasing & ephemeral port assignment in FreeBSD
    ... >Basically what I'm trying to understand is how many open TCP ... >connections a single server can support and how the server keeps them ... then let's say each of the 100K clients ... >connects to the server by opening a connection to the server at port ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Connecting Out of Process Servers via COM+
    ... connection, and in fact we can only use one connection because of the way ... years ago when I needed a number of clients to share a single serial ... it would create a Dispatcher-Object first and registers ... > This means, altough COM+ would allow parallel requests, the calls would be ...
    (microsoft.public.vb.com)