From: fd@fd.ods.org   
      
   "jack"  schreef in bericht   
   news:55sc57-g7u.ln1@foo.bar...   
   > FD wrote:   
   >> "jack"  schreef in bericht   
   >> news:557757-9iq.ln1@foo.bar...   
   >>> FD wrote:   
   >>>> "jack"  schreef in bericht   
   >>>>> Nice solution, but what makes it different (from a security point of   
   >>>>> view)   
   >>>>> from having a VPN connection into the client's network? The support   
   >>>>> workstation still has full access to anything on the client's network,   
   >>>>> only limited by what the intermediate server allows. And that server   
   >>>>> is   
   >>>>> outside the client's control.   
   >>>>>   
   >>>>> What we normally do is declare all systems that have to be remotely   
   >>>>> accessible for maintenance a separate DMZ, and have a firewall (under   
   >>>>> client's control) between that and the rest of the network. Only what   
   >>>>> is   
   >>>>> absolutely needed for operations is allowed through that firewall.   
   >>>>>   
   >>>>> Remote access can be via a modem, via a VPN into the DMZ, or by any   
   >>>>> other   
   >>>>> means. Most IT departments are quite comfortable with that; some of   
   >>>>> the   
   >>>>> more paranoid ones have the incoming VPN connection set up so that   
   >>>>> only   
   >>>>> certain IP addresses are reachable through the VPN.   
   >>>>>   
   >>>> The Remote Support Server/Client have to be configured for each   
   >>>> individual   
   >>>> protocol and device that needs to be accessable.   
   >>>> To create a connection the helpdesk needs a special application with   
   >>>> username/password for setting up a connection with the Server and being   
   >>>> switched to the Remote Support Client.   
   >>>> This is the only way to make connections. No other devices in the   
   >>>> customers   
   >>>> network are accessable, which is the case with a VPN.   
   >>>> The customer has an overview of all connections that the installed   
   >>>> Remote   
   >>>> Support Client supports.   
   >>>>   
   >>>> VPN connections can be restricted via DMZ, but most IT departments and   
   >>>> even   
   >>>> VPN suppliers have problems implementing it properly. In larger   
   >>>> companies it   
   >>>> is very difficult to get any approval to modify a router, let alone a   
   >>>> firewall, so we cannot touch existing security systems.   
   >>>> I have experiences where VPN and firewall suppliers did not believe our   
   >>>> system works, because their security was so good. How ignorant and dumb   
   >>>> can they be?   
   >>>>   
   >>>> This system requires no computer, network or firewall modifications.   
   >>>> Just a black-box at the customer and an 1MB application at the   
   >>>> helpdesk. It is not only used for remote support applications, but also   
   >>>> for remote access like Microsoft's Remote Desktop (RDP). Several   
   >>>> agencies use this to add an extra layers of security upon RDP: extra   
   >>>> encryption and compression, extra authorization layer with access   
   >>>> restrictions and most appreciated: Windows Servers need no incoming   
   >>>> internet connections so they are less vunerable to attacks.   
   >>>>   
   >>>> Our application has extensive security measures located at the Remote   
   >>>> Support Server. They are not based on IP addresses (that can be spoofed   
   >>>> or   
   >>>> are not fixed by load-balancing). We use two forms of encryption and a   
   >>>> custom negotiation protocol to establish a connection, followed by   
   >>>> authorization of user (helpdesk) and hardware (Remote Support Client).   
   >>>>   
   >>>> Frank   
   >>>>   
   >>>>   
   >>> Thanks, that's how I interpreted the diagram you posted. In other words,   
   >>> no need for the 'support server', the same functionality can be built   
   >>> using just a simple black-box running some minimal Linux or BSD distro.   
   >>> Place the box inside the client's LAN, make it accessible from the   
   >>> outside through certificate-authenticated VPN, and give it strict   
   >>> outgoing firewall rules.   
   >>>   
   >>> The client has to trust that the ruleset that is shown to him is   
   >>> actually the ruleset that the box implements. And as soon as the ruleset   
   >>> includes even one RDP or VNC link to an internal server, all bets are   
   >>> off anyway and anybody with the support password/cert can use that as a   
   >>> stepping stone to other systems.   
   >>>   
   >>> j.   
   >>   
   >> You are not getting it completely. Still just thinking about VPN's, huh?   
   >> It's better to think about 3 proxy servers for which you do not know the   
   >> communication protocol for.   
   >>   
   >> The Remote Support Server is only required when incoming connections at   
   >> the customer are not allowed. Either because of corporate policy, third   
   >> party firewalls/routers that cannot be touched or missing coorporation of   
   >> an IT department. Otherwise the helpdesk could connect directly to the   
   >> Remote Support Client, which only requires a single TCP port forwarded in   
   >> the customer's firewall.   
   >> Nobody knows how to setup a connection to the Remote Support Client. It   
   >> has a non-standard communication protocol with multiple encryption and   
   >> negotiation methods. A small program is required to setup a connection,   
   >> that will act as a proxy server and starts the client software at the   
   >> helpdesk. User authorization only gives access to the Remote Support   
   >> Client. Usually devices at the customer have additional security methods,   
   >> like encryption and authorization.   
   >>   
   >>   
   > OK, I get it. Security by Obscurity. Thanks but no thanks.   
   >   
   > j.   
      
   We gave the source code of the helpdesk program to 3 hackers and they did   
   not manage to establish an authorized connection to the Remote Support   
   Client via the Remote Support Server. So obscure is a much better word than   
   obscurity.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)