On Tue January 11 2005 03:06, bogi wrote: > Hi Shawn. > port knocking will only delay a pro for a few hours at best, than they will > authenticate and get the data. Not very useful in your case. Having > mentioned the end users using laptops, this brings up a big (commy) red > flag. What if the laptop is allready stolen ??, browser caches checked, > data and passwords taken. Using a vpn with a single-use-password system > combined with a fully encrypted filesystem on the laptops would be a far > better solution than monkeying around with port knocking and whatnot. > > Cheers > Szemir > > On January 11, 2005 02:09, Shawn wrote: > > Hoping someone can help me out. > > > > A client has a web application that they want to make accessible to their > > employees via the web (of course). The catch is that the app has > > critical business data that CANNOT become available to script kiddies > > and/or the competition. (There is a login routine, via the database, but > > I don't trust that on it's own with this data). > > > > So, the options as I see them are to use a VPN solution only, bring in an > > SSL certificate and use HTTPS (though this doesn't really stop the script > > kiddies - just sniffers), or maybe use port knocking. > > > > When I explained port knocking, the client seemed rather keen (even > > though I told him it's a relatively new technology). The questions I > > have to find out now is what it would take to get this set up, in such a > > way that field users can connect via their laptops. Does anyone have any > > experience with Port Knocking? I know enough to know what it is, but > > that's about it. > > > > Or would this situation be best suited to a VPN?
As Szemir pointed out, there is no one single security product or feature that will make all data/communications secure. Port knocking is more "security through obscurity" than anything. It simply masks the presence of a application with a secret handshake. It would be more crucial, IMHO, to ensure that data stream and communication process was secure first. A VPN creates a secure tunnel to back-end servers (i.e. LAN access over the Internet). Since this is a web app, that's probably overkill (a VPN just for a browser-to-web server transaction). So, yeah, SSL is probably the standard implementation of choice for this scenario (unless I'm missing something). Perhaps others will have some insight into best practices for this type of situation that I lack. A layered security approach is implemented in the various different areas you expose along the way. For instance, you should have your web server in a DMZ. Your web server should be secured according to best practices. Sane firewall rules should be in place (e.g. egress filtering). A general security policy framework should be in place for monitoring, auditing and dealing with security-related events. You might eventually add port knocking in for kicks, but it's only going to complicate matters which increases support. If you've got the rest taken care of already and you want the extra layer of protection (and the resulting trade-off in simplicity/usability), then by all means go ahead. Security is a large, open-ended, constantly changing landscape that requires attention from end-to-end in order to be successful. Frankly, it means a lot of work, and the business decision whether to support it lies in the balance of the investment in time/money/effort/etc. vs. the relative value of the corporate assets at stake, such as corporate data. Sorry to turn this into a small dissertation on Information Security practices, but from my standpoint (as a security/privacy advocate) once you open up the can of worms that is "security", you're forced to deal with all of it (to varying limited degrees). HTH, Curtis S. _______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines (http://clug.ca/ml_guidelines.php) **Please remove these lines when replying
