January 5th, 2011 § § permalink
I have found a little OpenSSH switch to be one of my best friends. If I am at a strange client network, cafe, or conference I use “-D” to make me feel warm and fuzzy all over. In OpenSSH if you use this switch you create an SSH SOCKS proxy on the port you specify. Thus encrypting your traffic to the SSH server you specify. In my case I connect to my home computer using a free DYNDNS (http://www.dyndns.com/) dynamic DNS name mapped to my home computer that stays on.
$ssh -D 6666 username@ip-address-of–your-ssh-server
Then you simply point your browser or other programs like IM to that port (in example 6666) on localhost and you can browse from your home computer free of snooping or any potential malicious users.
Another handy tool is ProxyChains (http://proxychains.sourceforge.net/) which I know works on Linux and might compile for you Mac people too.
December 17th, 2010 § § permalink
April 28th, 2010 § § permalink
A French group of security researchers have come up with some very interesting results in terms of the level of privacy one can expect and the simplicity of which someone can monitor BitTorrent traffic. Which is kinda scary for everyone using it especially those who like to download large amounts of music and movies. Even those using Tor may not be safe from this type of monitoring.
We argue that it is possible to continuously monitor from a single machine most BitTorrent users and to identify the content providers (also called initial seeds). This is a major privacy threat as it is possible for anybody in the Internet to reconstruct all the download and upload history of most BitTorrent users.
To circumvent this kind of monitoring, BitTorrent users are increasingly using anonymizing networks such as Tor to hide their IP address from the tracker and, possibly, from other peers. However, we showed that it is possible to retrieve the IP address for more than 70% of BitTorrent users on top of Tor [LMC_POST10]. Moreover, once the IP address of a peer is retrieved, it is possible to link to the IP address other applications used by this peer on top of Tor.
Read more (off site)
March 6th, 2009 § § permalink
SC has a good write up on cloud computing security:
Cloud computing, as least as a concept, is being driven largely by economics. It is generally less costly to run applications, add capacity and increase storage in the cloud, rather than investing in new hardware and software, and bringing on additional staff and beefing up networking.
“Cloud computing will happen because it has too much of an economic incentive and developer support – applications can be quickly added and developers can have a single place to maintain source code,” says Vatsal Sonecha, VP, business development & product management at TriCipher.
Overall, incentives include application-deployment speed, lower costs and fast prototyping. These are strong drivers. So much so that Gartner predicts that by 2012, 80 percent of Fortune 1000 companies will pay for some cloud computing service, and 30 percent of them will pay for a cloud computing infrastructure.
That is not to say that entire data centers will be moving to the cloud, at least in the largest companies. But for certain solutions, the cost benefits are hard to ignore.
Read More. . . (off site)
March 2nd, 2009 § § permalink
I wanted to touch briefly on the security concerns for having Scalr accessible via the Internet. If you are running your own install of Scalr this is an important factor before even adding the first farm. For my own sake I will not getting into my exact setup, but instead talk about a few approaches to locking down access to Scalr.
Possibly the best approach is to limit access to Scalr interface to internal network requiring users to use OpenVPN or some other VPN solution to access internal resources which would include Scalr. If you are hosting Scalr on an AWS instance be sure to set the security group to only allow the port you are running for VPN. You can find a quick and dirty howto for OpenVPN on an EC2 instance at Google Books.
Another option is to use SSL and mod_access (Apache 1.3) or its renamed equivalent in Apache 2.2 mod_authz_host to limit those who have access to Scalr interface. You should for sure at least use SSL to access Scalr. You can also add a layer of authentication for good measure using Apache Basic Authentication.
Being that Scalr controls the rest of your AWS setup it is by far the one thing you want to lock down as much as possible.