home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.dcom.vpn      VPN protocols, clients, awesomeness      2,348 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 2,315 of 2,348   
   FD to jack   
   Re: Need help with remote access solutio   
   23 Feb 10 07:54:36   
   
   From: fd@fd.ods.org   
      
   "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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca