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

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:

Quote:

---

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?

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.

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.

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.

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

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

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.

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

:-)

Quote:

---

the only way is to open firewall rules

---

This isn't unique, in fact, unless you allow the VPN to listen in the first place, there is no way for people outside of your perimeter to hit the VPN.

Word to the wise:

1) Only open the ports necessary for the VPN to operate. In my case, only port 443 is exposed.

2) Select an architecture that will suit growth. There are 3 major VPN architectures. Parallel, In-line and toaster. Each has its advantages and disadvantages. Again, requirements will steer you towards the appropriate choice. In my case, I have a toaster mode setup.

Anyway, I'd draw the pictures of each but google can do that for you much quicker.