Trajik

That is true. But your single passphrase is double the length of my 2 single ones. Then of course yours will be harder. But what if each one of mine were double the size of your one? Haha we could go around in circles for hours. But i know what your saying, you may aswell use a single pass-phrase just aslong as any mutliples combined for the same security. (But then we could start thinking about the future... what if the program in question used to encrypt, or the algorithym itself is later found to have an exploit of vulnerability, and that is the only method you used to encrypt your single file? You might then wish you had something else inside) And it could be true that once cracking through one container the motivation is there to carry on, it also could be true that it's the straw that breaks the camels back... it took <this long to crack>, they are all excited, only to find... yet another... encrypted volume. ARHHG. Haha interesting topic :)

Well not exactly 'different' crypto. But yeah you have a point. You would use the best method (or most secure) of encryption available to you, then why bother with wrapping anymore with anything less secure? Well i guess you wouldn't, you would use the same. But my point is that a method like that wprks purely for a time constraint point of view. Say you are trying to crack a password... at what point will you give up and say "bad luck, i couldn't crack it"? 1 week? 3 months? A year? If you have a trucrypt volume with say, a 16 character passphrase. Then inside that you have another truecrypt volume (same crypto or not) with a different 20 character passphrase (obviously would have a different hash, was created at a different time), then it WILL make it 'harder' to crack because you have only gotten half way if/once you crack the first container. And how long did that take? Who knows how long the second one will take? Will there be more encrypted containers inside this one? Obviously if you don't want government agencies getting to your stuff, you have a lot of other things to think about than encryption (yes, they probably already have those files archived off somewhere and have a nice meta search cluster at the ready to find anything on you at any time). But i believe that by having multiple encryptped volumes or containers inside each other, all with different (obviously long, random) pass-phrases, and all created with different hashes, the chance of cracking your way through each one will take longer and longer. Not really practical for every day file use like you state. But if you worked on the files maybe a couple of times a week, having to enter a few different passphrases at different levels may be worth while. All depends on where you draw the line from security/usability and is it worth while. --just for fun-- And i guess for tinfoil paranoia fun you could say, have your linux partitions encrypted automaticly, then use an encryption program to do its own full disk encryption, then create a virtual machine on that host. Install an OS with disk encryption. Inside the VM make numerous serpeate encrypted volumes with differernt passphrases, then have your files at the root of it all (inside the containers which are inside the VM). Shut down the VM. Create an encrypted container, move the VM inside that. Then move that container inside a few more containers. Oh and of course, the actual data you are protecting is a stenography file passworded with RAR then residing in a PGP file. Haha i'd actually be curious to see how fucking slow working with that would be :) --maybe not so fun--

Ah ok i'm with you now. I'm not sure re: the bruteforcing. I'm sure you have scoured the interwebz looking for your answer. Did you see this? http://www.tek-tips.com/viewthread.cfm?qid=555357 Looks like there is a couple of options for password recovery. One by a firmware upgrade. Another by using default passwords (they claim it works with 3300). I've never touched 3com so sorry can't be of too much more assistance.

Never tried but the bit rate over a serial modem would be painfully slow. Remember the old days of IT class when they taught you how Serial operated? 1 bit after the other? This would take forever. What are the exact model of switches you need to do password recovery on?

I also agree that Trucrypt is the best option for this. But before everyone gets head over heals, you still need to have long-arse pass phrase otherwise your security is kind of pointless. Have a read of this article before using it. http://www.shortinfosec.net/2009/02/cracki...-container.html Also, bundling it with other crypto methods is a good idea.

In theory this is classless (shit it's been a while since i studied this...). It is still subnetting however. He has two separate class C networks going on here. It doesn't matter what IP's they are, aslong as the hosts fall within that subnet. 1.x /24 is a different subnet from 2.x /24. The /24 bits is what is making the subnet. It doesn't have to be 192.168.x.x. The /24 is the important thing. People find it easier to use 10.x.x.x /24 than 192.x.x.x /24 as it's easier to use, remember and configure devices. Especially in larger organisations when you have a large number of separate subnets and sites.

Sounds like you need a 'real' DMZ. Only because you mentioned other people from outside getting into these VMs. So what you want is basically a different subnet which access control rules to prevent it from speaking to your 'green zone' but allow to speak to your 'red zone' while the green zone still can talk to it. But with using virtual NICs, and not having a physical 'DMZ' port anywhere, things will get retarded with the routing and ACLs. Also, how many NICs do you have in the VM server? Is it possible to get a second? You are trying to use what you have to make a virtual DMZ so to speak, which will work in theory, but won't work for security purposes. It won't actually be a DMZ. It will just be a different subnet, which will mean nothing because if they are attached to the same physical link you won't be able to control the access between the routes properly and thus it won't be a true DMZ (from what i can see anyway). It will just be 2 networks that can communicate. (Which you don't want if you are letting outsiders in) If you had a 2nd NIC in your VM server. And had a 3rd NIC in your firewall. You could make this work. You could make the 3rd NIC on the firewall be on a 10.0.2.x /24 subnet. Plug that directly into one of your dumb switches. Plug Your VM's 2nd NIC into that same switch (or do it directly). Set the 2nd NIC of your VM server to be in the 2.x subnet. While your first remains in 1.x. Set your virtual machines to be 2.x. On the firewall create an ACL which prevents 2.x from speaking to 1.x but allow 1.x to speak to 2.x (i'm assuming your firewall can do this). Then allow 2.x to communicate with everything else and give the VMs a default gateway of your firewalls 3rd NIC. And everything should be hunky dorey. Then just set up your NAT rules to translate from your outside to your inside VMs. The only thing then you have to worry about is the actual security of your VM server and the VMs. VMs are generally great sandboxes and whatever is inside them can't escape to the host machine (your VM server). But i know there are some security risks floating around lately, so you may want to read up on VMware security. But apart from that. Should be good to go and you should be able to serve outsiders into your VM without venturing into your green zone.

Have you actually tried this while you are at home? Can you SSH into it while you are on your LAN? This would be the first thing to test before you try connecting remotely with port forwarding. Also, have you made sure you have no firewall rules blocking incoming connections on your home computer? Windows Firewall or something? You can also test this by port scanning your home PC and seeing if port 443 is open. If all of the above is fine and you can connect while on your LAN. Start looking at your router and your NAT rules. Perhaps try port forwarding a simpler service to test it actually works, like a webserver, ftp or something simple. Good luck.