MrMintanet
asked on
Could you hack this setup? Could anyone?
If I really wanted to be anonymous and free of worry, I'd do this:
BIOS Password using fingerprint biometrics-> NO HARD DISK INSTALLED -> LiveCD OS -> REMOVABLE USB WiFi to net -> IKE over VPN -> Firewall/Router Filter USB WiFi MAC Address -> TrueCrypt -> Terminal Server -> 128 bit encrypted RAR -> Putty.exe -> Putty SSH over VNC -> FileVault -> Mac OSX Workstation-> FileVault ->Removable USB thumbdrive -> 256 bit AES encrypted -> disk image -> 128bit AES -> Password Protected Archive -> Password protected Microsoft Office documents -> Codes to the nukes
I would also do the following to cause slow the attacker just a tad bit more:
Windows Terminal Server:
Terminal Server will appear to be configured to be something simple, such as a print server that was accidentally broadcast to the internet.
Terminal Server will be setup on a Virtual Machine, and have several other "mock" servers connected as well. These other servers will not trust the "Print Server"
Encrypted Archive containing putty.exe will be stored in a hidden folder that is constantly modified, such as System32 print driver folder
Terminal Server's purpose is so appear as "low hanging fruit that is easy for picking", thus creating the illusion of vulnerability and also an easy method of viewing "hackers" in action.
Terminal Server will not use Administrator as user name and password for the password to ensure the "low fruit" is recognized.
Terminal Server will only open port 3389 will be available. All other ports are closed to the WAN.
Random photo folder (cats being silly, demotivational posters, etc.) will be placed on Terminal Server desktop in last attempt to keep hacker logged on long enough.
Use a minimum of 12 characters per password using special characters only accessible using multiple keys (ie. user name: ÐÆß) This would be Unicode character set.
All archives and images will have the file extension altered to .tmp and marked as hidden.
When I started writing this, I had no intention of making it this long. I guess my creativity started flowing!
BIOS Password using fingerprint biometrics-> NO HARD DISK INSTALLED -> LiveCD OS -> REMOVABLE USB WiFi to net -> IKE over VPN -> Firewall/Router Filter USB WiFi MAC Address -> TrueCrypt -> Terminal Server -> 128 bit encrypted RAR -> Putty.exe -> Putty SSH over VNC -> FileVault -> Mac OSX Workstation-> FileVault ->Removable USB thumbdrive -> 256 bit AES encrypted -> disk image -> 128bit AES -> Password Protected Archive -> Password protected Microsoft Office documents -> Codes to the nukes
I would also do the following to cause slow the attacker just a tad bit more:
Windows Terminal Server:
Terminal Server will appear to be configured to be something simple, such as a print server that was accidentally broadcast to the internet.
Terminal Server will be setup on a Virtual Machine, and have several other "mock" servers connected as well. These other servers will not trust the "Print Server"
Encrypted Archive containing putty.exe will be stored in a hidden folder that is constantly modified, such as System32 print driver folder
Terminal Server's purpose is so appear as "low hanging fruit that is easy for picking", thus creating the illusion of vulnerability and also an easy method of viewing "hackers" in action.
Terminal Server will not use Administrator as user name and password for the password to ensure the "low fruit" is recognized.
Terminal Server will only open port 3389 will be available. All other ports are closed to the WAN.
Random photo folder (cats being silly, demotivational posters, etc.) will be placed on Terminal Server desktop in last attempt to keep hacker logged on long enough.
Use a minimum of 12 characters per password using special characters only accessible using multiple keys (ie. user name: ÐÆß) This would be Unicode character set.
All archives and images will have the file extension altered to .tmp and marked as hidden.
When I started writing this, I had no intention of making it this long. I guess my creativity started flowing!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
using USB wifi instead of an onboard connection will only slow them down by seconds, if any - one simple packet capture from a wifi sniffer would give them the mac address, and mac addresses only matter for the local lan anyhow (no remote node knows or cares what your mac address is, its l2 information, not l3)
you won't have too many packet problems - all the packets are regenerated frequently when they pass though servers, other than the stream encapsulated in VPN - but hopping between different gui remote control protocols - vnc, rdp, pcanywhere, etc etc - causes no end of problems and is to be avoided. just hopping repeatedly and retaining one protocol (rdp say) can cause issues. really, you want to have one gui session, and tunnel only tcp (so the following will work reliably:
IPSEC tunnel - remote site, carries SSH to lan server
SSH tunnel via lan server to unroutable network - connects to SSH endpoint2
SSH tunnel via SSH endpoint2 to VNC or RDP server
remote control session, via tunnel-in-tunnel-in-vpn to actual server that does the work.
the problem here is that the remote endnode itself is unaffected by the security of the access method - if you can get physical access, odds are good you can log onto either the endnode or (if its virtualized) its host environment directly, and access the screen that way. by making the security dependent on booting a truecrypt protected virtual machine, you can compartmentalize that security risk - have the physical access route exposed *only* when the data is unlocked - but you can't eliminate it entirely. If you copy the file to local ram on the local endnode AND you can unlock them there - which for ms office documents means an install of ms office (so, better to have a 7z archive and just use rtf format so you can use open office from the live cd) then you could move the final exposure to the local endnode which you control, but that is not guaranteed to be any better than having a dedicated secure endnode on the final storage server you can use to view and update the files in situ. Terminal endnode physical security is one of the two achillies heels of an extended cryptography chain - the other is "rubber hose cryptoanalysis" :)
you won't have too many packet problems - all the packets are regenerated frequently when they pass though servers, other than the stream encapsulated in VPN - but hopping between different gui remote control protocols - vnc, rdp, pcanywhere, etc etc - causes no end of problems and is to be avoided. just hopping repeatedly and retaining one protocol (rdp say) can cause issues. really, you want to have one gui session, and tunnel only tcp (so the following will work reliably:
IPSEC tunnel - remote site, carries SSH to lan server
SSH tunnel via lan server to unroutable network - connects to SSH endpoint2
SSH tunnel via SSH endpoint2 to VNC or RDP server
remote control session, via tunnel-in-tunnel-in-vpn to actual server that does the work.
the problem here is that the remote endnode itself is unaffected by the security of the access method - if you can get physical access, odds are good you can log onto either the endnode or (if its virtualized) its host environment directly, and access the screen that way. by making the security dependent on booting a truecrypt protected virtual machine, you can compartmentalize that security risk - have the physical access route exposed *only* when the data is unlocked - but you can't eliminate it entirely. If you copy the file to local ram on the local endnode AND you can unlock them there - which for ms office documents means an install of ms office (so, better to have a 7z archive and just use rtf format so you can use open office from the live cd) then you could move the final exposure to the local endnode which you control, but that is not guaranteed to be any better than having a dedicated secure endnode on the final storage server you can use to view and update the files in situ. Terminal endnode physical security is one of the two achillies heels of an extended cryptography chain - the other is "rubber hose cryptoanalysis" :)
ASKER
The MAC address is also used as physical evidence in court.
that would be foolish - I frequently use COTS software that can fake a mac on wifi or wired ethernet in seconds, and most high-end nic drivers (for example, hp servers with dual nics) have that ability built into the normal installed version. I can also throw *any* packet (with any source or destination MAC you choose) onto the LAN using a trivial to operate tool called "nemesis" - holding an actual conversation means changing the MAC on the NIC, using the aforementioned software, or writing my own code against the pcap libraries of course.
no competent prosecution expert would go into court with a mac address as "evidence" and expect it to survive against a competent defence expert.
no competent prosecution expert would go into court with a mac address as "evidence" and expect it to survive against a competent defence expert.
"Could you hack this setup? Could anyone?"
Yes, anything digital can be hacked.
Yes, anything digital can be hacked.
In practical terms, a box is unhackable if it is faster and easier for the attacker to ship you and your loved ones to pakistan and torture you and them until you give them the key. once you reach that point, feel free to stop, as adding more code just makes it more likely they will get curious about what you want to hide so badly...
ASKER
I wish I could give more points than this. Thank you very much for your help and professional insight. Please ignore my "shadow" down near the bottom of the comments. He's been trolling all of my questions. If you ever wanted to chat outside of EE, my contact info: ComputerIdioth AT gmail
ASKER
Easy disposal of a MAC address is the benefit
As for the rest, thanks for the input. Your answer really must have taken a great deal of time to write. My strategy is not only to shut the user down, but give them opportunities to walk down the wrong road and waste their time as well. I find that giving them a bit of direction down the wrong road is a great way to hold them off a bit longer.
I am a complete novice to security, and I hardly consider myself a expert on the subject, but I do feel that my crazed setup would inevitably choke out and get disconnects constantly due to fragmented packets, MTU instability, and time outs. Honestly, I had posted this configuration as a suggestion to a question regarding hard drive encryption. I was being a bit daft about it, but at the same time, I thought it was interesting enough to post as a question in itself.
I am eager to see other people's thoughts on my crazed setup.