VPN,home user security & java applets
Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: VPN,home user security & java applets

  1. #1
    Member
    Join Date
    Jun 2004
    Posts
    77

    VPN,home user security & java applets

    hi
    there's a need for our staff to work at home. So we gave them company notebooks, tokens and passwords to connect through VPN to our internal web server where they will use an application
    that requires applet to be downloaded to their notebooks. This applicaiton is in use built web application, but still in applet technology. ok so what security risks can we see from this, considering it's company notebook, that it's token based authentication, and using VPN , except that java applets are needed in order to use the application.
    thanks

  2. #2
    I'd rather be fishing DjM's Avatar
    Join Date
    Aug 2001
    Location
    The Great White North
    Posts
    1,867
    Would putting the "web server" into the "trusted sites" list in IE and lowering the security settings for that site only, be an option?

    Cheers:
    DjM

  3. #3
    THE Bastard Sys***** dinowuff's Avatar
    Join Date
    Jun 2003
    Location
    Third planet from the Sun
    Posts
    1,252
    so what security risks can we see from this, considering it's company notebook, that it's token based authentication, and using VPN
    Kind of depends on the type of VPN and how it's set up. Can you give more details?
    09:F9:11:02:9D:74:E3:5B8:41:56:C5:63:56:88:C0

  4. #4
    Banned
    Join Date
    Apr 2003
    Posts
    1,146
    Yes, the laptops are company owned, but once they leave your organization and managment control, they cannot remain trusted devices for long. Users being users, ya know. What considerations do you have in place for quarrantine of incoming systems on the VPN? Redirect to update sites, AV, Spyware? If the system can connect through the VPN, token-based or no, anything that may be riding on it could come through as well.

    Just my tuppence.

  5. #5
    Senior Member
    Join Date
    Jun 2003
    Posts
    188
    It would be better to restrict things at VPN level itself, secondly put multiple layers
    of security like even with the applet ask for a password etc.

  6. #6
    Senior Member
    Join Date
    Oct 2005
    Posts
    197
    Im no guru here so bare with me. The laptops should have an AV and spyware. Would it be possible to firewall and or restrict physical access on all ports other then the ones needed for the web app? Basicly my train of thought is that if a laptop is lost or stolen and some one other then th e trusted user gets it they should be prompted/forced to login before using anything. So if the only thing they could hit on the VPN was the webserver it would be just that. Correct me if im wrong.
    meh. -ech0.

  7. #7
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,884
    I have a VPN solution deployed that requires ActiveX to fire or, as a backup, the Java runtime engine.

    Things to consider.
    1) Endpoint compliance check - If your VPN isn't capable, dump it fast. This feature allows you to force the user to have certain apps installed and up to date before the tunnel is built. You can even MD5 hash apps so that they can only run a certain version of an app. This also helps out with endpoint compliance check. If the sum is off, the connection can be severed or you can be nice and route them to a VLAN where they can get an explanation of the problem and links to instructions on how to fix the issue(s).

    2) Careful when allowing people to VPN in the first place. I mean this from a legal standpoint. In some cases, if you extend the office to the home, you are required to provide the same safety conditions such as fire extinguishers and such. See your legal dept *before* you just hand out VPN clients.

    3) Use the explicit deny model when constructing ACLs. In other words, if they don't need it, don't give it. Also, you should have a blanket policy on protocols that are not allowed. Your requirements will drive this. In my case, I don't allow many of the Microsoft protocols such as NetBIOS, etc.

    4) Consider two form authentication. This will certainly creep back in the form of legislation. Do it from the start. Going back after the fact is harder and end users generally resist the slightest variation in their normal routine.

    5) Stress test any solution you are considering, but don't let the vendor help you. If you don't have in-house talent, go out and rent some. Many issues come to light when we blackbox test equipment. VPNs are especially fun to break.

    6) Java, in itself is a solid language because it's designed to remove buffer overflows, however, thanks to Microsoft, the IE browser seems to provide endless avenues for java apps to exploit it. It's one of the more dangerous languages because of its ability to harvest information without the end user knowing. This can be said about a number of helper languages but again, I'm focusing on java.

    7) White listing your VPN server while ratcheting down everything else is a decent idea if the end user doesn't have the ability to edit this section of IE. If they are in as an admin user, it will be pretty useless as a bot will surely come along and fix up the security section for you and really screw up the works.

    8) Detailed logging is a must. Do not allow generic accounts and be sure to keep accurate logs. You'll thank me the first time you have to investigate why a file was uploaded at midnight Sunday.

    Anyway, that's off the top of my head. If there is something more you want to know, just ask.

    --TH13
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  8. #8
    Shadow Programmer mmelby's Avatar
    Join Date
    Jul 2002
    Location
    Ft. Myers, FL
    Posts
    291
    We have a similar situation. Here is a list of what we have done to the laptops to help protect ourselves from ourselves 

    Installed AV
    Installed Anti-spyware
    We install a branded version of the Cisco VPN client that is configured to require the built-in firewall to be running and prevent any external connections while the VPN is connected
    We modify the registry to lock down the computer.

    Some of the things that we prevent through registry modification are:

    Restrict MSI installation
    Disable Desktop right click
    No access to Network control panel applet
    No access to dialup control panel applet
    No access to User Manager control panel applet
    No access to system control panel applet
    No access to Add/Remove Programs control panel applet

    I created a program that an administrator can run to turn these things off and on

    There are certainly other things you can do to lock it down more but this is where we started.

    I can provide an example of the program I created if you would like.

    Regards, m2
    Work... Some days it's just not worth chewing through the restraints...

  9. #9
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,884
    Ahhh yes, I almost forgot. In some modes of operation, we do not allow split tunneling. This is only when using an IPSEC tunnel that actually extends the network out to the end user, i.e., from a network perspective they appear to be on the physical network with an IP addy used in our Govt. DHCP pool.
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  10. #10
    Member
    Join Date
    Jun 2004
    Posts
    77
    thanks for replies..very informative. Right now, things get even worse. here's what:
    it is found that the application is client/server based and not java applet. That is, the application have to be installed first into the notebook. then the user will use a token, key in password , and the VPN client to will connect to VPN machine back in office. Once authenticated, the user will launch the application and start using. BUT it is c/s , so the traffic is from notebook directly to the office database .... notebook IP ---> VPN ----> database at port 1234.
    Because the traffic also will pass thru the office firewalls ( after passing VPN) , so the firewall must be opened to like this :
    src: VPN IP address
    dest : database server IP
    port: 1234

    Initally we wanted to use Citrix, but as the application is coded to map to C:\ drive. , Citrix cannot be used. ( Citrix cannot be mapped to C:\ drive as it will crash with the notebook's C:\ drive)
    So no choice now, user is rushing for it, and development for this application is not in the workplan, the only way is to open firewall rules, plus tighten the notebook to allow users to use this PREHISTORIC application..sigh

    I guess i will try to tighten the notebook as much as possible using the information here..as well as setting up firewall on VPN ( if there is a firewall feature)...
    anymore good suggestions on tightening, please enlighten me, thanks

    :-)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •