Regarding this article I am not posting it as a security incident or news at all. It contains wealth of information about bandwidth and throughput and how we perceive them. It also illustrates how network monitoring and measurement should take place.
Enjoy!!!
--------------------------------------------------------------------------------------------------------------------------
Side-channel attack on high-frequency trading networks could net a hacker millions of dollars in seconds -- and leave everyone else much poorer
High-frequency trading networks, which complete stock market transactions in microseconds, are vulnerable to manipulation by hackers who can inject tiny amounts of latency into them. By doing so, they can subtly change the course of trading and pocket profits of millions of dollars in just a few seconds, says Rony Kay, a former IBM research fellow and founder of cPacket Networks, a Silicon Valley firm that develops chips and technologies for network monitoring and traffic analysis.
Kay, an Israeli-born computer scientist and one-time Intel engineering manager, says the root of the problem is the increasing speed of networks; as they get faster and faster, our ability to actually understand events taking place within them isn't keeping up. Network monitoring technology can detect perturbations in network traffic happening in milliseconds, but when changes occur in microseconds, they're not visible, he says.
[ For the key tech news of the day, sign up for InfoWorld's Tech Headlines Wrap-Up newsletter. | Learn how to greatly reduce the threat of malicious attacks with InfoWorld's Insider Threat Deep Dive PDF special report. ]
cPacket has developed a proof of concept showing that these side-channel attacks can be used to create tiny delays in the transmission of market data and trades. By manipulating specific trading activities by several microseconds, an attacker could gain unfair trading advantage. And because the operation occurs outside the range of monitoring technology, it would remain invisible. "We believe that such techniques pose a substantial risk of creating unfair trading, if used by the wrong people," Kay says.
(A side-channel attacker looks at indirect information related to the computer -- the electromagnetic emanations from screens or keyboards, for example -- to determine what is going on in the machine. )
Latency threatens other applications as well
The lack of visibility into high-speed networks is of concern to more than the financial community. Managing traffic on today's 10Gbps and faster networks is becoming difficult, resulting in degradations of performance, particularly to virtualized systems. "It's difficult to take corrective actions when you can't really see what's taking place," Kay says. "If you cannot measure network latency, you cannot control it and cannot improve it."
In a PDF whitepaper on latency, Kay wrote, "Traditionally, applications that have latency requirements include: VoIP and interactive video conferencing, network gaming, high-performance computing, cloud computing, and automatic algorithmic trading. For example, one-way latency for VoIP telephony should generally not exceed 150 milliseconds (0.15 seconds) to enable good conversation quality, while interactive games typically require latencies between 100 and 1,000 milliseconds. However, the requirements for automated algorithmic trading are much more strict. A few extra milliseconds, or even a few extra microseconds, can enable trades to execute ahead of the competition, thereby increasing profits."
Indeed, latency, even at the very highest speeds, is so concerning that researchers at MIT recommended any organization dealing in complicated time-sensitive global interactions should take a hard look at where they locate their data centers.
The MIT researchers even suggested that financial firms could gain some advantage by taking advantage of limitations posed by the speed of light. For example, it typically takes about 50 milliseconds to send a message from New York to London. Placing a server between the two could cut the speed of communication in half, they said, which may be enough time to take advantage of some momentary pricing discrepancy. Trading on that discrepancy is known as arbitrage, and it's becoming increasingly common.
Lessons of the "flash crash"
The vulnerability of markets in which high-frequency trading is common became all too evident last May, when exchanges experienced a "flash crash" that drove the Dow Jones down about 600 points in just five minutes. The incident was not the result of deliberate manipulation, but it shows just how dependant the financial world is on technology it doesn't really understand.
"Financial institutions and exchanges with [high-frequency trading] are spending millions to improve latency by microseconds and at the same time can't measure the data at that resolution in real time. It's disturbing," Kay says.
A side-channel attack on a high-frequency trading network is analogous to a denial-of-service attack. In a typical DoS attack, bots flood a target website with enormous numbers of hits, often causing a crash. A side-channel attack would be infinitely more subtle, but it would still function by adding extraneous packets to a legitimate data stream. Those extra packets slow the data just enough to give someone else a chance to move first in the market.
Kay says he does not know if anyone has yet launched a side-channel attack against a high-frequency trading network -- but it worries him. And it worries me. Financial markets are supposed to be a level playing field. They're not, of course. Small players, like the millions of us who invest for our 401(k)s and other retirement accounts, are at an immense disadvantage even when everything is kosher. But the proliferation of high-frequency trading widens the gap even more. If someone can really take advantage of a weakness in those networks, we're all really in trouble. And that's just another reason why more -- not less -- regulation is required in the financial markets.
I welcome your comments, tips, and suggestions. Post them here so that all our readers can share them, or reach me at bill.snyder@sbcglobal.net. Follow me on Twitter at BSnyderSF.
This article, "Hackers find a new way to cheat on Wall Street -- to everyone's peril," was originally published by InfoWorld.com. Read more of Bill Snyder's Tech's Bottom Line blog and follow the latest technology business developments at InfoWorld.com.
Friday, January 7, 2011
Thursday, January 6, 2011
How to secure your Linux system
Are you running Linux just because you think it's safer than Windows? Think again. Sure, security is a built-in (and not a bolt-on) feature and extends right from the Linux kernel to the desktop, but it still leaves enough room to let someone muck about with your /home folder.
Linux might be impervious to viruses and worms written for Windows, but that's just a small subset of the larger issue.
Attackers have various tricks up their sleeves to get to those precious bits and bytes that make up everything from your mugshot to your credit card details.
Computers that connect to the internet are the ones most exposed to attackers, although computers that never get to see online action are just as vulnerable.
Think of that ageing laptop or that old hard disk you just chucked away without a second thought. Bad move.
With the kind of data recovery tools available today (many as a free download) it doesn't matter what OS was installed on the disk.
If it holds data – corrupted or otherwise – it can be retrieved, bank accounts recreated, chat transcripts reconstructed, images restitched.
But don't be scared. Don't stop using the computer.
While it's virtually impossible to make a machine connected to the internet impenetrable to attacks, you can make an attacker's task difficult and also ensure they have nothing to learn from a compromised system.
Best of all, with Linux, and some pieces of open source software, it doesn't take much effort to secure your Linux installation.
There is no golden rule for security that applies in every single case, and even if there were it would have been cracked already.
Security is something that needs to be worked upon, and personalised. Follow the tips and tools in this tutorial as we show you how to adapt them to your very own Linux installation.
Follow these six tips to get a safer computer the easy way
1. Keep up with security updates
All mainstream Linux desktop distros (such as Debian, Ubuntu, Fedora, etc) have security teams that work with the package teams to make sure you stay on top of any security vulnerabilities.
Generally these teams work with each other to make sure that security patches are available as soon as a vulnerability is discovered.
Your distro will have a repository solely dedicated to security updates.
All you have to do is make sure the security specific repository is enabled (chances are it will be, by default), and choose whether you'd like to install the updates automatically or manually at the press of a button.
For example, under Ubuntu, head over to System > Administration > Software Sources. Here, under the Updates tab, specify how frequently the distro should ping the security repository for updates, and whether you'd like to install them without confirmation, or just be notified about the updates.
The latter is a better option, because it lets you review the updates before installing them. But chances are they'll be fine, and you can save yourself some time by having your distro install them automatically.
In addition to the updates, distros also have a security mailing list to announce vulnerabilities, and also share packages to fix them.
It's generally a good idea to keep an eye on the security list for your distro, and look out for any security updates to packages that are critical to you.
There's a small lag between the announcement and the package being pushed to the repository; the security mailing lists guide the impatient on how to grab and install the updates manually.
2. Disable unnecessary services
A Linux desktop distro starts a number of services to be of use to as many people as possible. But one really doesn't need all these services.
For example, do you really need Samba for sharing files over the network on your secure server, or the Bluetooth service to connect to Bluetooth devices on a computer that doesn't have a Bluetooth adapter?
All distros let you control the services that run on your Linux installation, and you should make full use of this customization feature.
Under Ubuntu, head to System > Preferences > Startup Applications. Here you can remove check marks next to the services you wish to disable.
But be careful when turning off services. Some applications might stop functioning because you decided to disable a service on which they rely.
For example, many server applications rely on databases, so before you turn off MySQL or PostgreSQL you should make sure you aren't running any applications that rely on them.
3. Restrict root access
Most distros these days don't allow you to login as root at boot time, which is good. When you have to execute a task that requires super user privileges you'll be prompted for a password.
It might be a little irritating but it goes a long way to making sure that admin tasks are isolated from the user.
You can restrict access privileges for a user from under System > Administration > Users and Groups.
Here you can broadly categorise a user as a desktop user or a system administrator or customise access privileges manually.
By default, users are created as with 'Desktop user' permissions and can't install software or change settings that affect other users.
On the command line, the su command (on Fedora, and the like) lets normal users switch to the root account, while the sudo command (on Debian, Ubuntu, etc) grants more privileges to the user.
The usage of these commands can be limited to a particular group, which prevents any user from administering the system. sudo is also the more secure of the two, and it keeps an access log under /var/log/auth.log.
Make a habit of regularly scanning the log for failed and successful sudo attempts.
4. Don't auto-mount devices
If you're really concerned about security, you need to lean on the customisation feature of the Users And Groups settings. One of the areas to look at is auto-mounting devices.
Most distros auto-mount USB drives and CDs as soon as they are inserted. It's convenient, but allows anybody to just walk up to your machine, plug in a USB disk and copy all your data.
To avoid such a situation, go to to System > Administration > Users and Groups, select your user and head to the Advanced Settings > User Privileges tab.
Make sure you uncheck the boxes corresponding to the Access External Storage Devices Automatically option, the Mount Userspace Filesystems, and Use CD-ROM Drives option.
When unchecked, these options will prompt the user for a password before giving them access to these devices.
You might also want to disable sharing files on the network, as well as require the user to enter a password before connecting to the Ethernet and wireless devices.
By disabling access to configure printers you prevent important data from being printed.
5. Don't stay on the bleeding edge
Packages included in a desktop Linux distribution are updated regularly. Besides the official repositories, there are custom repositories for third-party software.
While developers do take care to scan the packages for vulnerabilities before pushing them on to the repository, it's almost inevitable that some updates with defects do get through.
While it's good to keep the system updated, from a security point of view, not all updates are good for the system.
Some updates conflict with existing installed package or may even pull in new dependencies that may make the system more prone to attack. All this is why you should only update packages if you have to.
Scan the updates and look for updates to packages that are critical to you. Most package managers also make it possible to check an update and display its changelog and a brief description of the changes.
UI changes can safely be ignored or delayed until a package has been thoroughly tested. Instead, look out for and grab updates that offer a fix to existing issues with packages.
6. Don't upgrade every six months
Most major desktop Linux distributions make a new release every six months, but you don't have to install every last upgrade just because it's there.
Debian, for example, offers three distributions to choose from based on the extent of the stability of the software available in it. After Debian 6.0, stable releases will be made every two years.
Other distros take a different approach to guarantee secure releases. Ubuntu marks certain releases as LTS (or Long Term Support).
A desktop release of the LTS version is supported for three years, and a server release is supported for five years, which is a lot longer than the 18 months for a standard Ubuntu release.
Although not up to date, these releases are much more secure from a security point of view, with packages that are a lot more stable and more thoroughly tested than their latest versions.
If running a secure system is your goal, you should think of sticking to one of these long-term stable releases and avoid the temptation to upgrade as soon as the latest version of your becomes available.
Out of the box, a Linux installation is much more secure than other operating systems. That is, until you connect to the internet. Once online, a desktop Linux installation, in its bid to be of use to as many users as possible, leaves enough room to be exposed to attacks and intrusions.
Don't sweat though. Help is only a terminal away.
All Linux distros ship with Iptables, which is a part of the kernel that enables sysadmins to filter network packets.
Configuring it manually is impossible for all but the elite, but in the true spirit of open source the community offers a number of graphical front-ends that make setting up a firewall a walk in the park. One such graphical firewall is Firestarter.
We didn't start the fire
Firestarter simplifies the process of configuring the settings for a firewall. It can limit access on ports that are running services that might be prone to outside attacks, and you can also use it to glance at the network traffic passing across the machine you're running it on.
Most distros bundle Firestarter in their repos, so installing it shouldn't be a problem. When you start it for the first time, the firewall launches a simple configuration wizard that prompts you to select the network interface on which it will be active.
If you have multiple devices with one connecting to the internal network, Firestarter can act as gateway and share the internet connection with the rest of the network.
By default, Firestarter only filters through connections that are in response to connection requests from the firewall host.
The advantage of doing things this way is that it blocks access to services like Telnet, which can be exploited to gain access to your machine without your knowledge.
Tweaking the firewall doesn't take much effort either. If you have an app that requires access on certain ports, such as a Torrent client, you need to punch holes in your firewall to allow incoming connections. That's easily done from under the Policy tab.
Right-click inside the space under Allow Service and select Add Rule. From the pull-down menu, select the service you want to allow, say Samba, select the source IP (anyone opens the port to all) and you're done.
To restrict outgoing traffic, select Outbound Traffic Policy from the drop-down list. Now you can select either the Permissive or the Restrictive option.
If you select the Permissive option, you'll have to add the hosts you want to block in a blacklist.
Restrictive is the opposite, and only allows connections from the listed hosts, denying the rest.
When running in restrictive mode, Firestarter will log all connection refusals under the Events tab. As you spot a connection you want to allow for your users, right-click on the entry and select the option to either allow the connection for everyone or just when it originates from a particular source.
You can also monitor active connections to the firewall from Firestarter's main interface. It shows you the status of the service, gives you a summary of inbound and outbound connections, and the amount of data that has passed through an interface.
In addition to listing the source and destination of the traffic, it'll also tell you the port the data is travelling through, the service running on that port and the program that's calling the shots.
Encrypt your filesystem
If you really want to keep others from reading your files, user passwords won't cut it. For instance, there's very little to stop a user with higher access permissions, like the root user, from gawking at stuff under your home directory.
What you need is to encrypt your data so that it's unintelligible to people without the means to decrypt it.
The smart way to do this is to encrypt the whole filesystem, which would automatically encrypt any data kept on it. This is where TrueCrypt shines.
It lets you carve a virtual slice out of your Linux partition that will act as a standalone encrypted filesystem.
You then mount it, use it to store and read files as you would from a normal partition, then unmount it, and Bob's your uncle.
When it isn't mounted, the encrypted filesystem appears to be a random jumble of bits.
TrueCrypt isn't available in any distribution's repository due to licensing issues, but installing it is a trivial affair.
Grab it from its website, extract the Tar archive, and install it via the graphical setup. Just make sure your distro has the Fuse library, and the device mapper tools.
Create an encrypted volume
Before you can use TrueCrypt you'll have to create an encrypted volume to store files on, so launch the app and click on the Create Volume button.
This will launch the Volume Creation Wizard, which lets you either create a virtual encrypted disk within a file or an encrypted volume within an entire partition, or even a disk such as a removable USB drive.
If you select the first option to create a virtual disk, TrueCrypt will ask you to point it to a file on the disk that'll be the encrypted volume.
If the file exists, TrueCrypt will recreate it, using one of the eight encryption algorithms.
Next, specify the size of the encrypted volume and format it as an FAT filesystem, which makes it accessible from other operating systems as well as Linux.
Finally, choose a password to mount the encrypted volume.
To store files on the volume you'll have to mount it. Select the file that's your encrypted volume from the TrueCrypt main interface, and press the Mount button.
The app will prompt for the password of the volume before it can be mounted. You also get the option to mount the volume as read-only, if all you have to do is read files from it.
By default, TrueCrypt chooses not to remember the name of the file that's your encrypted volume. This is a security feature, and adds another roadblock in the path of an intruder.
If you ask the app to remember the name of the file, anyone with physical access to the computer can select the file from a pull-down menu and mount the encrypted volume.
They'll still have to get past your password though.
Once the encrypted volume is mounted you can save files to it just like you do with a normal volume.
TrueCrypt uses your modern hardware at its disposal to encrypt and decrypt files on the fly; which is to say it minimises the lag due to the overhead of converting unreadable bitstream into meaningful data that can be read by your text editor or played by your media player.
When you're through, unmount the volume with the Dismount button within the program.
Think formatting a disk is enough? Think again
Removing a file from the disk seems like a simple operation: just right-click on the file and send it to the trash.
Command line users may use the rm command do do the same thing.
Unfortunately, none of these methods actually deletes a file or a folder. They just hypnotise the filesystem to forget where a file is located in the disk.
These newly liberated disk locations are then added to the filesystem's pool of free address, and can point to new files.
That works in theory, but in practice the humongous size of partitions means that the disk locations that hold the deleted file may actually harbour them long enough for recovery tools to reconstruct them.
That's where shred comes in. Shred overwrites a file's space on the disk to make sure the space contains only garbage.
You might also want to use the --remove option to make sure it deletes the original file as well.
Shredding a file can be a lengthy affair, as it overwrites the location 25 times.
You can manipulate the number of rewrites with the -n switch, like this:
$ shred --remove -n 5 -v top-secret.txt
shred: top-secret.txt: pass 1/5 (random)...
shred: top-secret.txt: pass 2/5 (ffffff)...
shred: top-secret.txt: pass 3/5 (random)...
shred: top-secret.txt: pass 4/5 (000000)...
shred: top-secret.txt: pass 5/5 (random)...
shred: top-secret.txt: removing
shred: top-secret.txt: renamed to 0000
shred: 0000: renamed to 000
shred: 000: renamed to 00
shred: 00: renamed to 0
shred: top-secret.txt: removed
Shred works well on devices like /dev/sdb, which negates the use of the --remove switch, because you wouldn't want to remove the device.
There's a caveat here. Shred assumes the filesystem rewrites the file in place. This would render it useless on modern journalled filesystems such as ext3.
Shred also fails to wipe traces of the data being deleted in several places, such as the swap, RAM, and the filesystem journal.
An effective and secure deletion strategy requires the secure delete tools.
Secure-delete
The secure-delete tools include srm to securely remove the files, smem and sswap to wipe traces of data from the physical and SWAP memory, and sfill to ensure the free space on the disk doesn't point to old deleted files.
The tools make use of cryptographic algorithms especially designed to make sure deleted files are unrecoverable.
Once it's installed, make sure you remove the file or a directory with:
$ srm -v ../the-hole/eicar.com.txt
Using /dev/urandom for random input.
Wipe mode is secure (38 special passes)
Wiping ../the-hole/eicar.com.txt *********************************** *** Removed file ../the-hole/eicar.com.txt ... Done
Add the -r switch to recursively delete a directory. When you're done, make sure you wipe off residual traces from your RAM with smem, which may take a considerable amount of time depending on the size of the physical memory it has to wipe.
You can speed up the process with the -l switch, which reduces the number of rewrite passes (this is less secure).
Top off the process by disabling swap with swapoff, wiping it clean with sswap , and then re-enabling it with swapon.
The sfill command comes in handy when you are discarding a disk. Use it from a live CD on an unmounted partition to wipe the free space.
Remove junk
They might not be as bad as the other operating system, but all Linux distros tend to accumulate a lot of crud over a period of time. But why blame Linux?
The junk files are the legacy of the plethora of apps you have running on top of your kernel. You can pin their habit of collecting fluff to of the way the applications are configured to give you a better user experience.
And not only do all those log files, the temporary internet files and the various app caches accumulate to take up a considerable amount of disk space, they pose a great threat to your privacy.
Instead of trolling through the filesystem and emptying the various tmp/ directories, use BleachBit. It's a one-stop shop for removing all the crud that the apps have preserved.
BleachBit has a set of about 70 pre-defined cleaners, each of which works on a particular app such as Firefox, Google Chrome, Adobe Reader, OpenOffice.org and more.
The cleaners are tuned to wipe the dead weight off the applications and give them a performance boost.
The lightweight BleachBit is available in the repositories of all major distributions, though you might want to grab the latest build from its website. The project also releases bonus cleaner packs for older versions.
The BleachBit GUI is divided into two frames. On the left-hand side you select the apps that you wish to clean; this expands to give you more options specific to that app. In the right-hand frame, you get a brief explanation of each of these checkable options.
Get cleaning
To clean an area, such as Firefox's cache, simply click on the checkbox next to it. Some cleanup operations require you to trawl through a large location and involve more than a simple delete operation.
BleachBit will warn you when selecting such a task that might take up a considerable amount of time, for example, wiping the swap memory.
Before you ask BleachBit to zap the useless files in the apps you've selected, use the Preview button to review the list of files it'll delete.
If you encounter a file that you don't want to delete, such as the cache of a particular Firefox user, you can add it to a whitelist.
This is a list of files that BleachBit will not touch, even if the broader cleaner that they come under has marked them for removal.
You can specify any files or folders to bypass under the Whitelist tab under Edit > Preferences.
BleachBit also has a command line interface. For example, the following command cleans cookies under Firefox and Google Chrome:
$ bleachbit --delete firefox.cookies google_chrome.cookies
Use the --preview switch to get a list of files before removal. The CLI makes BleachBit scriptable for automated daily runs.
To add a cron job to nuke regularly created files, such as rotated logs and cookies daily at 2.00 am, edit the crontab with crontab -e and add the following line:
0 2 * * * bleachbit --delete firefox.cookies google_chrome. cookies system.rotated_logs
If daily sounds too frequent, you should at least run the app before creating backups. You can also use BleachBit to speed up certain apps, house clean the distro by fixing broken shortcuts, delete language packs and empty physical RAM and swap memory.
Browse anonymously
Pull a Keyser Soze on the internet – make it think you don't exist…
On the internet, sometimes the best form of privacy is being anonymous. It's difficult for an attacker to get to you if they can't pinpoint you on the network. And no one covers your tracks better than the combination of Privoxy and Tor.
Tor protects privacy via a distributed network of relays run by volunteers spread across the world. This helps prevent anybody monitoring your internet connections from learning what sites you visit.
Tor works with web browsers, instant messaging programs and many other TCP-based apps. But the various app protocols and associated programs can be coaxed into revealing information about the user, which is where Privoxy comes into the picture.
Tor depends on Privoxy and its filtering capabilities to enhance privacy.
Begin by pulling Privoxy from your distro repositories, then head into your browser's advanced settings where you can change its proxy settings.
Here just fill in 127.0.0.1 for the HTTP proxy, and specify 8118 as the port.
That's all there's to it.
When you're done, start the Privoxy daemon with /etc/ init.d/privoxy start. You can now access Privoxy's interface from http://config.privoxy.org or http://p.p.
To hook up Privoxy with Tor, you first need to set up Tor's package repository. This is easily done by adding the following line to your Ubuntu or Debian installation:
deb http://deb.torproject.org/torproject.org main
Replace with the name for your distro, like karmic, or sid. Then add the GPG key used to sign the packages by running the following:
gpg --keyserver keys.gnupg.net --recv 886DDD89 gpg --export A3C4F0F979CAA22CDBA8 F512EE8CBC9E886DDD89 | sudo apt-key add -
If you use Yum, create a torproject.repo under /etc/ yum/repos.d with the following content:
[torproject]
name=Tor and Vidalia
enabled=1
autorefresh=0
baseurl=http://deb.torproject.org/torproject.org/rpm/
DISTRIBUTION/
type=rpm-md gpgcheck=1
gpgkey=http://deb.torproject.org/torproject.org/rpm/RPMGPG- KEY-torproject.org
Again replace DISTRIBUTION with the name of your Fedora or CentOS release, such as centos5 or fc13.
Now fetch Tor via the package manager, which will also pull in additional packages like the Vidalia Tor GUI controller.
Make sure you don't install the Polipo web proxy app, since we are using Privoxy and the two might conflict because they operate on the same port.
The last step is to get Privoxy and Tor to talk to each other. For this just edit the Privoxy config file under /etc/privoxy and uncomment the following line:
# forward-socks4a / 127.0.0.1:9050
Also uncomment the following lines to make sure the local network is still reachable:
# forward 192.168.*.*/ .
# forward 10.*.*.*/ .
# forward 127.*.*.*/
Presto!
Now all our internet traffic that passes through the Tor and Privoxy proxies is masked.
Linux might be impervious to viruses and worms written for Windows, but that's just a small subset of the larger issue.
Attackers have various tricks up their sleeves to get to those precious bits and bytes that make up everything from your mugshot to your credit card details.
Computers that connect to the internet are the ones most exposed to attackers, although computers that never get to see online action are just as vulnerable.
Think of that ageing laptop or that old hard disk you just chucked away without a second thought. Bad move.
With the kind of data recovery tools available today (many as a free download) it doesn't matter what OS was installed on the disk.
If it holds data – corrupted or otherwise – it can be retrieved, bank accounts recreated, chat transcripts reconstructed, images restitched.
But don't be scared. Don't stop using the computer.
While it's virtually impossible to make a machine connected to the internet impenetrable to attacks, you can make an attacker's task difficult and also ensure they have nothing to learn from a compromised system.
Best of all, with Linux, and some pieces of open source software, it doesn't take much effort to secure your Linux installation.
There is no golden rule for security that applies in every single case, and even if there were it would have been cracked already.
Security is something that needs to be worked upon, and personalised. Follow the tips and tools in this tutorial as we show you how to adapt them to your very own Linux installation.
Follow these six tips to get a safer computer the easy way
1. Keep up with security updates
All mainstream Linux desktop distros (such as Debian, Ubuntu, Fedora, etc) have security teams that work with the package teams to make sure you stay on top of any security vulnerabilities.
Generally these teams work with each other to make sure that security patches are available as soon as a vulnerability is discovered.
Your distro will have a repository solely dedicated to security updates.
All you have to do is make sure the security specific repository is enabled (chances are it will be, by default), and choose whether you'd like to install the updates automatically or manually at the press of a button.
For example, under Ubuntu, head over to System > Administration > Software Sources. Here, under the Updates tab, specify how frequently the distro should ping the security repository for updates, and whether you'd like to install them without confirmation, or just be notified about the updates.
The latter is a better option, because it lets you review the updates before installing them. But chances are they'll be fine, and you can save yourself some time by having your distro install them automatically.
In addition to the updates, distros also have a security mailing list to announce vulnerabilities, and also share packages to fix them.
It's generally a good idea to keep an eye on the security list for your distro, and look out for any security updates to packages that are critical to you.
There's a small lag between the announcement and the package being pushed to the repository; the security mailing lists guide the impatient on how to grab and install the updates manually.
2. Disable unnecessary services
A Linux desktop distro starts a number of services to be of use to as many people as possible. But one really doesn't need all these services.
For example, do you really need Samba for sharing files over the network on your secure server, or the Bluetooth service to connect to Bluetooth devices on a computer that doesn't have a Bluetooth adapter?
All distros let you control the services that run on your Linux installation, and you should make full use of this customization feature.
Under Ubuntu, head to System > Preferences > Startup Applications. Here you can remove check marks next to the services you wish to disable.
But be careful when turning off services. Some applications might stop functioning because you decided to disable a service on which they rely.
For example, many server applications rely on databases, so before you turn off MySQL or PostgreSQL you should make sure you aren't running any applications that rely on them.
3. Restrict root access
Most distros these days don't allow you to login as root at boot time, which is good. When you have to execute a task that requires super user privileges you'll be prompted for a password.
It might be a little irritating but it goes a long way to making sure that admin tasks are isolated from the user.
You can restrict access privileges for a user from under System > Administration > Users and Groups.
Here you can broadly categorise a user as a desktop user or a system administrator or customise access privileges manually.
By default, users are created as with 'Desktop user' permissions and can't install software or change settings that affect other users.
On the command line, the su command (on Fedora, and the like) lets normal users switch to the root account, while the sudo command (on Debian, Ubuntu, etc) grants more privileges to the user.
The usage of these commands can be limited to a particular group, which prevents any user from administering the system. sudo is also the more secure of the two, and it keeps an access log under /var/log/auth.log.
Make a habit of regularly scanning the log for failed and successful sudo attempts.
4. Don't auto-mount devices
If you're really concerned about security, you need to lean on the customisation feature of the Users And Groups settings. One of the areas to look at is auto-mounting devices.
Most distros auto-mount USB drives and CDs as soon as they are inserted. It's convenient, but allows anybody to just walk up to your machine, plug in a USB disk and copy all your data.
To avoid such a situation, go to to System > Administration > Users and Groups, select your user and head to the Advanced Settings > User Privileges tab.
Make sure you uncheck the boxes corresponding to the Access External Storage Devices Automatically option, the Mount Userspace Filesystems, and Use CD-ROM Drives option.
When unchecked, these options will prompt the user for a password before giving them access to these devices.
You might also want to disable sharing files on the network, as well as require the user to enter a password before connecting to the Ethernet and wireless devices.
By disabling access to configure printers you prevent important data from being printed.
5. Don't stay on the bleeding edge
Packages included in a desktop Linux distribution are updated regularly. Besides the official repositories, there are custom repositories for third-party software.
While developers do take care to scan the packages for vulnerabilities before pushing them on to the repository, it's almost inevitable that some updates with defects do get through.
While it's good to keep the system updated, from a security point of view, not all updates are good for the system.
Some updates conflict with existing installed package or may even pull in new dependencies that may make the system more prone to attack. All this is why you should only update packages if you have to.
Scan the updates and look for updates to packages that are critical to you. Most package managers also make it possible to check an update and display its changelog and a brief description of the changes.
UI changes can safely be ignored or delayed until a package has been thoroughly tested. Instead, look out for and grab updates that offer a fix to existing issues with packages.
6. Don't upgrade every six months
Most major desktop Linux distributions make a new release every six months, but you don't have to install every last upgrade just because it's there.
Debian, for example, offers three distributions to choose from based on the extent of the stability of the software available in it. After Debian 6.0, stable releases will be made every two years.
Other distros take a different approach to guarantee secure releases. Ubuntu marks certain releases as LTS (or Long Term Support).
A desktop release of the LTS version is supported for three years, and a server release is supported for five years, which is a lot longer than the 18 months for a standard Ubuntu release.
Although not up to date, these releases are much more secure from a security point of view, with packages that are a lot more stable and more thoroughly tested than their latest versions.
If running a secure system is your goal, you should think of sticking to one of these long-term stable releases and avoid the temptation to upgrade as soon as the latest version of your becomes available.
Out of the box, a Linux installation is much more secure than other operating systems. That is, until you connect to the internet. Once online, a desktop Linux installation, in its bid to be of use to as many users as possible, leaves enough room to be exposed to attacks and intrusions.
Don't sweat though. Help is only a terminal away.
All Linux distros ship with Iptables, which is a part of the kernel that enables sysadmins to filter network packets.
Configuring it manually is impossible for all but the elite, but in the true spirit of open source the community offers a number of graphical front-ends that make setting up a firewall a walk in the park. One such graphical firewall is Firestarter.
We didn't start the fire
Firestarter simplifies the process of configuring the settings for a firewall. It can limit access on ports that are running services that might be prone to outside attacks, and you can also use it to glance at the network traffic passing across the machine you're running it on.
Most distros bundle Firestarter in their repos, so installing it shouldn't be a problem. When you start it for the first time, the firewall launches a simple configuration wizard that prompts you to select the network interface on which it will be active.
If you have multiple devices with one connecting to the internal network, Firestarter can act as gateway and share the internet connection with the rest of the network.
By default, Firestarter only filters through connections that are in response to connection requests from the firewall host.
The advantage of doing things this way is that it blocks access to services like Telnet, which can be exploited to gain access to your machine without your knowledge.
Tweaking the firewall doesn't take much effort either. If you have an app that requires access on certain ports, such as a Torrent client, you need to punch holes in your firewall to allow incoming connections. That's easily done from under the Policy tab.
Right-click inside the space under Allow Service and select Add Rule. From the pull-down menu, select the service you want to allow, say Samba, select the source IP (anyone opens the port to all) and you're done.
To restrict outgoing traffic, select Outbound Traffic Policy from the drop-down list. Now you can select either the Permissive or the Restrictive option.
If you select the Permissive option, you'll have to add the hosts you want to block in a blacklist.
Restrictive is the opposite, and only allows connections from the listed hosts, denying the rest.
When running in restrictive mode, Firestarter will log all connection refusals under the Events tab. As you spot a connection you want to allow for your users, right-click on the entry and select the option to either allow the connection for everyone or just when it originates from a particular source.
You can also monitor active connections to the firewall from Firestarter's main interface. It shows you the status of the service, gives you a summary of inbound and outbound connections, and the amount of data that has passed through an interface.
In addition to listing the source and destination of the traffic, it'll also tell you the port the data is travelling through, the service running on that port and the program that's calling the shots.
Encrypt your filesystem
If you really want to keep others from reading your files, user passwords won't cut it. For instance, there's very little to stop a user with higher access permissions, like the root user, from gawking at stuff under your home directory.
What you need is to encrypt your data so that it's unintelligible to people without the means to decrypt it.
The smart way to do this is to encrypt the whole filesystem, which would automatically encrypt any data kept on it. This is where TrueCrypt shines.
It lets you carve a virtual slice out of your Linux partition that will act as a standalone encrypted filesystem.
You then mount it, use it to store and read files as you would from a normal partition, then unmount it, and Bob's your uncle.
When it isn't mounted, the encrypted filesystem appears to be a random jumble of bits.
TrueCrypt isn't available in any distribution's repository due to licensing issues, but installing it is a trivial affair.
Grab it from its website, extract the Tar archive, and install it via the graphical setup. Just make sure your distro has the Fuse library, and the device mapper tools.
Create an encrypted volume
Before you can use TrueCrypt you'll have to create an encrypted volume to store files on, so launch the app and click on the Create Volume button.
This will launch the Volume Creation Wizard, which lets you either create a virtual encrypted disk within a file or an encrypted volume within an entire partition, or even a disk such as a removable USB drive.
If you select the first option to create a virtual disk, TrueCrypt will ask you to point it to a file on the disk that'll be the encrypted volume.
If the file exists, TrueCrypt will recreate it, using one of the eight encryption algorithms.
Next, specify the size of the encrypted volume and format it as an FAT filesystem, which makes it accessible from other operating systems as well as Linux.
Finally, choose a password to mount the encrypted volume.
To store files on the volume you'll have to mount it. Select the file that's your encrypted volume from the TrueCrypt main interface, and press the Mount button.
The app will prompt for the password of the volume before it can be mounted. You also get the option to mount the volume as read-only, if all you have to do is read files from it.
By default, TrueCrypt chooses not to remember the name of the file that's your encrypted volume. This is a security feature, and adds another roadblock in the path of an intruder.
If you ask the app to remember the name of the file, anyone with physical access to the computer can select the file from a pull-down menu and mount the encrypted volume.
They'll still have to get past your password though.
Once the encrypted volume is mounted you can save files to it just like you do with a normal volume.
TrueCrypt uses your modern hardware at its disposal to encrypt and decrypt files on the fly; which is to say it minimises the lag due to the overhead of converting unreadable bitstream into meaningful data that can be read by your text editor or played by your media player.
When you're through, unmount the volume with the Dismount button within the program.
Think formatting a disk is enough? Think again
Removing a file from the disk seems like a simple operation: just right-click on the file and send it to the trash.
Command line users may use the rm command do do the same thing.
Unfortunately, none of these methods actually deletes a file or a folder. They just hypnotise the filesystem to forget where a file is located in the disk.
These newly liberated disk locations are then added to the filesystem's pool of free address, and can point to new files.
That works in theory, but in practice the humongous size of partitions means that the disk locations that hold the deleted file may actually harbour them long enough for recovery tools to reconstruct them.
That's where shred comes in. Shred overwrites a file's space on the disk to make sure the space contains only garbage.
You might also want to use the --remove option to make sure it deletes the original file as well.
Shredding a file can be a lengthy affair, as it overwrites the location 25 times.
You can manipulate the number of rewrites with the -n switch, like this:
$ shred --remove -n 5 -v top-secret.txt
shred: top-secret.txt: pass 1/5 (random)...
shred: top-secret.txt: pass 2/5 (ffffff)...
shred: top-secret.txt: pass 3/5 (random)...
shred: top-secret.txt: pass 4/5 (000000)...
shred: top-secret.txt: pass 5/5 (random)...
shred: top-secret.txt: removing
shred: top-secret.txt: renamed to 0000
shred: 0000: renamed to 000
shred: 000: renamed to 00
shred: 00: renamed to 0
shred: top-secret.txt: removed
Shred works well on devices like /dev/sdb, which negates the use of the --remove switch, because you wouldn't want to remove the device.
There's a caveat here. Shred assumes the filesystem rewrites the file in place. This would render it useless on modern journalled filesystems such as ext3.
Shred also fails to wipe traces of the data being deleted in several places, such as the swap, RAM, and the filesystem journal.
An effective and secure deletion strategy requires the secure delete tools.
Secure-delete
The secure-delete tools include srm to securely remove the files, smem and sswap to wipe traces of data from the physical and SWAP memory, and sfill to ensure the free space on the disk doesn't point to old deleted files.
The tools make use of cryptographic algorithms especially designed to make sure deleted files are unrecoverable.
Once it's installed, make sure you remove the file or a directory with:
$ srm -v ../the-hole/eicar.com.txt
Using /dev/urandom for random input.
Wipe mode is secure (38 special passes)
Wiping ../the-hole/eicar.com.txt *********************************** *** Removed file ../the-hole/eicar.com.txt ... Done
Add the -r switch to recursively delete a directory. When you're done, make sure you wipe off residual traces from your RAM with smem, which may take a considerable amount of time depending on the size of the physical memory it has to wipe.
You can speed up the process with the -l switch, which reduces the number of rewrite passes (this is less secure).
Top off the process by disabling swap with swapoff
The sfill command comes in handy when you are discarding a disk. Use it from a live CD on an unmounted partition to wipe the free space.
Remove junk
They might not be as bad as the other operating system, but all Linux distros tend to accumulate a lot of crud over a period of time. But why blame Linux?
The junk files are the legacy of the plethora of apps you have running on top of your kernel. You can pin their habit of collecting fluff to of the way the applications are configured to give you a better user experience.
And not only do all those log files, the temporary internet files and the various app caches accumulate to take up a considerable amount of disk space, they pose a great threat to your privacy.
Instead of trolling through the filesystem and emptying the various tmp/ directories, use BleachBit. It's a one-stop shop for removing all the crud that the apps have preserved.
BleachBit has a set of about 70 pre-defined cleaners, each of which works on a particular app such as Firefox, Google Chrome, Adobe Reader, OpenOffice.org and more.
The cleaners are tuned to wipe the dead weight off the applications and give them a performance boost.
The lightweight BleachBit is available in the repositories of all major distributions, though you might want to grab the latest build from its website. The project also releases bonus cleaner packs for older versions.
The BleachBit GUI is divided into two frames. On the left-hand side you select the apps that you wish to clean; this expands to give you more options specific to that app. In the right-hand frame, you get a brief explanation of each of these checkable options.
Get cleaning
To clean an area, such as Firefox's cache, simply click on the checkbox next to it. Some cleanup operations require you to trawl through a large location and involve more than a simple delete operation.
BleachBit will warn you when selecting such a task that might take up a considerable amount of time, for example, wiping the swap memory.
Before you ask BleachBit to zap the useless files in the apps you've selected, use the Preview button to review the list of files it'll delete.
If you encounter a file that you don't want to delete, such as the cache of a particular Firefox user, you can add it to a whitelist.
This is a list of files that BleachBit will not touch, even if the broader cleaner that they come under has marked them for removal.
You can specify any files or folders to bypass under the Whitelist tab under Edit > Preferences.
BleachBit also has a command line interface. For example, the following command cleans cookies under Firefox and Google Chrome:
$ bleachbit --delete firefox.cookies google_chrome.cookies
Use the --preview switch to get a list of files before removal. The CLI makes BleachBit scriptable for automated daily runs.
To add a cron job to nuke regularly created files, such as rotated logs and cookies daily at 2.00 am, edit the crontab with crontab -e and add the following line:
0 2 * * * bleachbit --delete firefox.cookies google_chrome. cookies system.rotated_logs
If daily sounds too frequent, you should at least run the app before creating backups. You can also use BleachBit to speed up certain apps, house clean the distro by fixing broken shortcuts, delete language packs and empty physical RAM and swap memory.
Browse anonymously
Pull a Keyser Soze on the internet – make it think you don't exist…
On the internet, sometimes the best form of privacy is being anonymous. It's difficult for an attacker to get to you if they can't pinpoint you on the network. And no one covers your tracks better than the combination of Privoxy and Tor.
Tor protects privacy via a distributed network of relays run by volunteers spread across the world. This helps prevent anybody monitoring your internet connections from learning what sites you visit.
Tor works with web browsers, instant messaging programs and many other TCP-based apps. But the various app protocols and associated programs can be coaxed into revealing information about the user, which is where Privoxy comes into the picture.
Tor depends on Privoxy and its filtering capabilities to enhance privacy.
Begin by pulling Privoxy from your distro repositories, then head into your browser's advanced settings where you can change its proxy settings.
Here just fill in 127.0.0.1 for the HTTP proxy, and specify 8118 as the port.
That's all there's to it.
When you're done, start the Privoxy daemon with /etc/ init.d/privoxy start. You can now access Privoxy's interface from http://config.privoxy.org or http://p.p.
To hook up Privoxy with Tor, you first need to set up Tor's package repository. This is easily done by adding the following line to your Ubuntu or Debian installation:
deb http://deb.torproject.org/torproject.org
Replace
gpg --keyserver keys.gnupg.net --recv 886DDD89 gpg --export A3C4F0F979CAA22CDBA8 F512EE8CBC9E886DDD89 | sudo apt-key add -
If you use Yum, create a torproject.repo under /etc/ yum/repos.d with the following content:
[torproject]
name=Tor and Vidalia
enabled=1
autorefresh=0
baseurl=http://deb.torproject.org/torproject.org/rpm/
DISTRIBUTION/
type=rpm-md gpgcheck=1
gpgkey=http://deb.torproject.org/torproject.org/rpm/RPMGPG- KEY-torproject.org
Again replace DISTRIBUTION with the name of your Fedora or CentOS release, such as centos5 or fc13.
Now fetch Tor via the package manager, which will also pull in additional packages like the Vidalia Tor GUI controller.
Make sure you don't install the Polipo web proxy app, since we are using Privoxy and the two might conflict because they operate on the same port.
The last step is to get Privoxy and Tor to talk to each other. For this just edit the Privoxy config file under /etc/privoxy and uncomment the following line:
# forward-socks4a / 127.0.0.1:9050
Also uncomment the following lines to make sure the local network is still reachable:
# forward 192.168.*.*/ .
# forward 10.*.*.*/ .
# forward 127.*.*.*/
Presto!
Now all our internet traffic that passes through the Tor and Privoxy proxies is masked.
Recording User Activity with a Script
Using Variables in Scripts
The purpose of this script is to log the commands and output of a user so you have an accurate record of all activity. One problem that you find if you depend upon logs with users and sudo is that sudo will not log the stdout nor the stderr.
keystroke.sh
#!/bin/bash
# Capture keystrokes of a user and log
TIMESTAMP=$(date +%m%d%y%H%M%S)
HOST=$(hostname|cut -f1 -d.)
LOGDIR=/var/log/user
LOGFILE=${HOST}.${LOGNAME}.${TIMESTAMP}
touch $LOGDIR/$LOGFILE
# Set Prompt
export PS1=”[$LOGNAME:$HOST]@”‘$PWD> ‘
chown $LOGNAME ${LOGDIR}/${LOGFILE}
chmod 600 ${LOGDIR}/${LOGFILE}
script ${LOGDIR}/${LOGFILE}
chmod 400 ${LOGDIR}/${LOGFILE}
Analysis of the Script
#!/bin/bash
The bash shell is the shell to use with this script.
TIMESTAMP=$(date +%m%d%y%H%M%S)
This line creates a variable (the date followed by month,day,year,hour,minute,second). Variables are symbolic names for memory in which you can assign values, as well as read the contents or manipulate the contents.
The advantage of a variable is that once it is assigned you can use it over and over. When you create variables it is important not to place spaces around the “=” sign.
It is important to start and end your variables so the shell can tell where the variable ends, that is why you see examples of variable with ( ).
Note there must be a space after “date”.
Here is the name of the log, note the time stamp on the end.
m67.root.070909025935
HOST=$(hostname|cut -f1 -d.)
HOST is a variable that is created to indicate the machine logs that will be accessed. It is created by two commands with the output of one piped into the second command.
The command hostname will print out the hostname of the computer the user is on. That hostname could be a single hostname or it could be a Fully Qualified Domain Name (FQDN).
hostname
m67
or
hostname
m67.example.com
The hostname is piped into a second command with the “|” symbol which takes the output of one command and sends it to the second command.
So when you create the variable HOST the command is run and sent to the second command cut. cut, as the name implies, is used to cut and display selected information from a text file or text input.
Think of it as something that will take a vertical slice of a text file, and send it to the output of your choice.
There are two ways to specify where you want to begin and end the slice. You can specify it either by a starting and an ending character, or by fields.
To specify your “slice” by fields, you’ll need to use both the -d and -f switches. The -d switch will specify the delimiter, the character that separates the fields, in this case a dot.
That’s so that cut will know where each field begins and ends. The -f switch will specify which fields you want to look at.
So the command you see with cut will take the first field and separate it from the other information that will be appended by a “.”.
m67.
If you wanted the see the first three fields of the hostname, FQDN, the script would be written like this:
HOST=$(hostname|cut -f1-3 -d.)
m67.example.com.
LOGDIR=/var/log/user
The variable $LOGDIR is created by determining the location of the log file after the “=”. You can place the log wherever it is convenient.
LOGFILE=${HOST}.${LOGNAME}.${TIMESTAMP}
Here the $LOGFILE variable is created by using three previously created variables, separated by a “.”, note the brackets.
touch $LOGDIR/$LOGFILE
The command touch creates an empty file that can be used by the information that is recorded. The “/” separates the two variables which have been determined by the text above in the script.
export PS1=”[$LOGNAME:$HOST]@”‘$PWD> ‘
The purpose of this script is to log the commands and output of a user so you have an accurate record of all activity. One problem that you find if you depend upon logs with users and sudo is that sudo will not log the stdout nor the stderr.
keystroke.sh
#!/bin/bash
# Capture keystrokes of a user and log
TIMESTAMP=$(date +%m%d%y%H%M%S)
HOST=$(hostname|cut -f1 -d.)
LOGDIR=/var/log/user
LOGFILE=${HOST}.${LOGNAME}.${TIMESTAMP}
touch $LOGDIR/$LOGFILE
# Set Prompt
export PS1=”[$LOGNAME:$HOST]@”‘$PWD> ‘
chown $LOGNAME ${LOGDIR}/${LOGFILE}
chmod 600 ${LOGDIR}/${LOGFILE}
script ${LOGDIR}/${LOGFILE}
chmod 400 ${LOGDIR}/${LOGFILE}
Analysis of the Script
#!/bin/bash
The bash shell is the shell to use with this script.
TIMESTAMP=$(date +%m%d%y%H%M%S)
This line creates a variable (the date followed by month,day,year,hour,minute,second). Variables are symbolic names for memory in which you can assign values, as well as read the contents or manipulate the contents.
The advantage of a variable is that once it is assigned you can use it over and over. When you create variables it is important not to place spaces around the “=” sign.
It is important to start and end your variables so the shell can tell where the variable ends, that is why you see examples of variable with ( ).
Note there must be a space after “date”.
Here is the name of the log, note the time stamp on the end.
m67.root.070909025935
HOST=$(hostname|cut -f1 -d.)
HOST is a variable that is created to indicate the machine logs that will be accessed. It is created by two commands with the output of one piped into the second command.
The command hostname will print out the hostname of the computer the user is on. That hostname could be a single hostname or it could be a Fully Qualified Domain Name (FQDN).
hostname
m67
or
hostname
m67.example.com
The hostname is piped into a second command with the “|” symbol which takes the output of one command and sends it to the second command.
So when you create the variable HOST the command is run and sent to the second command cut. cut, as the name implies, is used to cut and display selected information from a text file or text input.
Think of it as something that will take a vertical slice of a text file, and send it to the output of your choice.
There are two ways to specify where you want to begin and end the slice. You can specify it either by a starting and an ending character, or by fields.
To specify your “slice” by fields, you’ll need to use both the -d and -f switches. The -d switch will specify the delimiter, the character that separates the fields, in this case a dot.
That’s so that cut will know where each field begins and ends. The -f switch will specify which fields you want to look at.
So the command you see with cut will take the first field and separate it from the other information that will be appended by a “.”.
m67.
If you wanted the see the first three fields of the hostname, FQDN, the script would be written like this:
HOST=$(hostname|cut -f1-3 -d.)
m67.example.com.
LOGDIR=/var/log/user
The variable $LOGDIR is created by determining the location of the log file after the “=”. You can place the log wherever it is convenient.
LOGFILE=${HOST}.${LOGNAME}.${TIMESTAMP}
Here the $LOGFILE variable is created by using three previously created variables, separated by a “.”, note the brackets.
touch $LOGDIR/$LOGFILE
The command touch creates an empty file that can be used by the information that is recorded. The “/” separates the two variables which have been determined by the text above in the script.
export PS1=”[$LOGNAME:$HOST]@”‘$PWD> ‘
Thursday, December 23, 2010
OpenBSD is under code auditing due to FBI's IPSec backdoor injection
It was just last week that Theo de Raadt, OpenBSD founder and developer, posted an email that claimed the Federal Bureau of Investigations paid OpenBSD developers to leave backdoors in its IPSEC network security stack.
Since then early audits have found some questionable code, contributors denied any wrongdoing, and the original source reaffirmed his allegations.
When the original post hit the mailing list December 14, journalists attempted to contact those named in the allegation.
Brian Proffitt, FOSS journalist at ITWorld, contacted two individuals by the name given in the original email as participating in the deception and received denials from both.
Another named in the email, Jason Wright, answered the posting from de Raadt saying,
de Raadt told iTWire's Sam Varghese that "Until 2 days ago I had no idea that both Jason and Angelos (Keromytis) in the past did work for a company that does that business. And it is true, wow, that company really was in that business! Now they (the company) belong to Verizon."
Sam Varghese spoke with Perry who defended his claims saying, "I have absolutely, positively nothing to gain from making those statements to Theo, and only did so to encourage a source code audit of the OpenBSD Project based upon the expiry of my NDA with the FBI.
Being in any limelight is not my bag at all. If I had this to do over again, I would have sent an anonymous postcard to WikiLeaks."
It'll take time to go through all the code but de Raadt said "two bugs in our cryptographic code" have already been found. "We are assessing the impact. We are also assessing the 'archeological' aspects of this," he added.
No further information on the nature or significance of these bugs was given, but the scope of the allegations have far reaching implications for OpenBSD and Open Source in general.
OpenBSD is used in many commercial solutions based on its reputation of being very secure. If security risks of this magnitude are found it could undermine this long earned reputation and call into question the very concept of "many eyes." de Raadt said that the many eyes concept is very real, but the Open Source working relationship is greatly based on trust and not every commit is reviewed.
The wide sweeping effects of any deliberate security holes found in OpenBSD could very well be less trust and more review within Open Source projects across the board.
UPDATE: In further developments, de Raadt said yesterday that Angelos had worked on the cypto stack in question for four years when accepting a contract at NETSEC.
Angelos "wrote the crypto layer that permits our ipsec stack to hand-off requests to the drivers that Jason worked on.
That crypto layer ontained the half-assed insecure idea of half-IV that the US govt was pushing at that time. Soon after his contract was over this was ripped out."
de Raadt further said, "I believe that NETSEC was probably contracted to write backdoors as alleged.
If those were written, I don't believe they made it into our tree. They might have been deployed as their own product.
If such NETSEC projects exists, I don't know if Jason, Angelos or others knew or participated in such NETSEC projects."
So, it appears the original allegations that developers working on OpenBSD networking code could have worked on backdoors but there is no proof and had opportunity to add them to OpenBSD but they probably didn't. And if they did, it was probably pulled out long ago anyway. The bugs previously mentioned were not found to backdoor code.
Audits and overall basic cleanup of code continues.
Since then early audits have found some questionable code, contributors denied any wrongdoing, and the original source reaffirmed his allegations.
When the original post hit the mailing list December 14, journalists attempted to contact those named in the allegation.
Brian Proffitt, FOSS journalist at ITWorld, contacted two individuals by the name given in the original email as participating in the deception and received denials from both.
Another named in the email, Jason Wright, answered the posting from de Raadt saying,
Every urban lengend is made more real by the inclusion of real names, dates, and times. I will state clearly that I did not add backdoors to the OpenBSD operating system or the OpenBSD crypto framework (OCF). The code I touched during that work relates mostly to device drivers to support the framework. I don't believe I ever touched isakmpd or photurisd (userland key management programs), and I rarely touched the ipsec internals (cryptodev and cryptosoft, yes). However, I welcome an audit of everything I committed to OpenBSD's tree. I demand an apology.Gregory Perry, original source of de Raadt's information, suggested a review of all the code committed by "Jason Wright and several other developers he worked with originating from NETSEC."
de Raadt told iTWire's Sam Varghese that "Until 2 days ago I had no idea that both Jason and Angelos (Keromytis) in the past did work for a company that does that business. And it is true, wow, that company really was in that business! Now they (the company) belong to Verizon."
Sam Varghese spoke with Perry who defended his claims saying, "I have absolutely, positively nothing to gain from making those statements to Theo, and only did so to encourage a source code audit of the OpenBSD Project based upon the expiry of my NDA with the FBI.
Being in any limelight is not my bag at all. If I had this to do over again, I would have sent an anonymous postcard to WikiLeaks."
It'll take time to go through all the code but de Raadt said "two bugs in our cryptographic code" have already been found. "We are assessing the impact. We are also assessing the 'archeological' aspects of this," he added.
No further information on the nature or significance of these bugs was given, but the scope of the allegations have far reaching implications for OpenBSD and Open Source in general.
OpenBSD is used in many commercial solutions based on its reputation of being very secure. If security risks of this magnitude are found it could undermine this long earned reputation and call into question the very concept of "many eyes." de Raadt said that the many eyes concept is very real, but the Open Source working relationship is greatly based on trust and not every commit is reviewed.
The wide sweeping effects of any deliberate security holes found in OpenBSD could very well be less trust and more review within Open Source projects across the board.
UPDATE: In further developments, de Raadt said yesterday that Angelos had worked on the cypto stack in question for four years when accepting a contract at NETSEC.
Angelos "wrote the crypto layer that permits our ipsec stack to hand-off requests to the drivers that Jason worked on.
That crypto layer ontained the half-assed insecure idea of half-IV that the US govt was pushing at that time. Soon after his contract was over this was ripped out."
de Raadt further said, "I believe that NETSEC was probably contracted to write backdoors as alleged.
If those were written, I don't believe they made it into our tree. They might have been deployed as their own product.
If such NETSEC projects exists, I don't know if Jason, Angelos or others knew or participated in such NETSEC projects."
So, it appears the original allegations that developers working on OpenBSD networking code could have worked on backdoors but there is no proof and had opportunity to add them to OpenBSD but they probably didn't. And if they did, it was probably pulled out long ago anyway. The bugs previously mentioned were not found to backdoor code.
Audits and overall basic cleanup of code continues.
Wednesday, December 22, 2010
Group Publishes Database of Embedded Private SSL Keys
A new project has produced a large and growing list of the private SSL keys that are hard-coded into many embedded devices, such as consumer home routers. The LittleBlackBox Project comprises a list of more than 2,000 private keys right now, each of which can be associated with the public key of a given router, making it a simple matter for an attacker to decrypt the traffic passing through the device.
Published by a group called /dev/ttyS0, the LittleBlackBox database of private keys gives users the ability to find the key for a specific router in several different ways, including by searching for a known public key, looking up a device's model name, manufacturer or firmware version or even giving it a network capture, from which the program will extract the device's public certificate and then find the associated private SSL key.
Craig Heffner, a member of the group who developed the project, posted a link to the database on Saturday on the Full Disclosure mailing list. Users can download the LittleBlackBox code from Google Code. The fact that encryption keys were hard-coded into many embedded devices has been known for some time, but extracting the key and then finding a router that's using it has been a challenge until now.
Recommended Reads
"Here’s where it gets fun: many of these devices use hard-coded SSL keys that are baked into the firmware. That means that if Alice and Bob are both using the same router with the same firmware version, then both of their routers have the same SSL keys. All Eve needs to do in order to decrypt their traffic is to download the firmware from the vendor’s Web site and extract the SSL private key from the firmware image," the group said in a blog post accompanying the code release. "Currently LittleBlackBox has over 2,000 unique private SSL keys and growing, primarily belonging to routers and VPNs. Although at the moment the vast majority of the keys belong to various DD-WRT firmware, there are keys from Cisco, Linksys, D-Link and Netgear as well."
SSL is the default standard for encryption on the Web and is used to secure most transactions online, including e-commerce and online banking.
Thursday, December 16, 2010
Using Powertop to Lower System Power Usage
Ever wonder what's sucking the life out of your Linux laptop's battery or contributing to higher electric bills in the server room?
Check out Powertop, a tool for profiling a system to see what is using the most power.
Powertop was developed a few years ago to help profile systems and see what could be done to make Linux better at power savings.
It was aimed primarily at laptops, as many folks would install Linux on a laptop and then find out that battery performance was far worse under Linux than Windows.
You don't even need to run Powertop to benefit from it. Some of the most common power-gulping culprits are listed on the LessWatts.org website.
Many of these have been fixed in the upstream projects that caused unnecessary wakeups (like ntp waking up every second, or Pidgin checking every 5 seconds to check on idle time). Something as simple as a blinking cursor can cause a wake up every few seconds, and additional power consumption.
Check out Powertop, a tool for profiling a system to see what is using the most power.
Powertop was developed a few years ago to help profile systems and see what could be done to make Linux better at power savings.
It was aimed primarily at laptops, as many folks would install Linux on a laptop and then find out that battery performance was far worse under Linux than Windows.
You don't even need to run Powertop to benefit from it. Some of the most common power-gulping culprits are listed on the LessWatts.org website.
Many of these have been fixed in the upstream projects that caused unnecessary wakeups (like ntp waking up every second, or Pidgin checking every 5 seconds to check on idle time). Something as simple as a blinking cursor can cause a wake up every few seconds, and additional power consumption.
 |
| Screenshot of Powertop But you might want to get a look at what's going on under your system's hood specifically. Powertop should be packaged for all major Linux distros, though it might not be installed by default. After installing Powertop, start it up as root (or using sudo) by running powertop. Now you'll see an output that's very similar to top but showing the top causes for wakeups.It also displays the ACPI estimate for power usage; at the bottom of the output, it will show suggestions (if any) to improve power performance -- or it will notify you of processes preventing the disk from going into powersave mode. |
Sunday, December 5, 2010
طرق جديدة لسرقه السيارات
أبلغني بعض الزملاء بتعرضهم وبعض معارفهم إلى حوادث مثيله وانطلاقا من حرصنا على رفع الوعي الأمني الذاتي لكم ولتجنيبكم مثل هذه المواقف فقد رأيت انه لزاما على إن أحيطكم علما بها للأستفاده و درأ للخطر الذي يحيق بنا من كل جانب وهي كالاتى ..
· أحد الزملاء كان يستقل سيارته وتوقف وغادر سيارته تاركا زوجته و أبنائه لشراء بعض الاحتياجات من احد المحال و فوجئت زوجته بتوقف عربه بجوارهم و نزل منها شخص ابلغها باندلاع حريق بالسيارة من الخلف وألح عليها بسرعة مغادره السيارة مع أطفالها فورا ولكنها شكت في الأمر و اتصلت بزوجها الذي حضر مسرعا وعندما شاهدوه استقلوا سيارتهم و فروا هاربين
· - أحد الزملاء ابلغني أنه أثناء تواجده بشارع عباس العقاد شاهد أحد الأشخاص يقود سيارة و بجواره سيده تصرخ و تستغيث بالمارة ثم توقف فجأة ودفع السيدة خارج السيارة و أنطلق بها مسرعا وبعد تجمع المارة تبين أن السيدة و زوجها و أبنها قد توقفوا ونزل زوجها و أبنها لقضاء بعض الاحتياجات و فوجئت بركوب شخص غريب بجوارها حيث قام بتشغيل محرك السيارة وأمرها بمغادرتها وعندما رفضت تحرك بالسيارة مسرعا وعندما تعالى صراخها توقف ودفعها خارج السيارة وفر بها هاربا .
· أحد الزملاء كان له قريب يمتلك سيارة مرسيدس وأثناء إعادة المليء بالوقود بأحد محطات البنزين بالقاهرة فوجئ بركوب أحد الأشخاص بسيارته وفر بها هارباً وأضطر لمطاردته مستقلاً سيارة أجرة ولكن لم يفلح باللحاق به وقد عثر علي سيارته بعد حوالي أربعه أشهر بالأسكندريه بعد تغيير لونها و اختفاء بعض أجزائها وفي حالة سيئة جداً.
· أحد الزملاء ابلغه صديقه بسرقة سيارته ماركة هيونداي ألنترا من أمام منزله وبسؤاله عن تفاصيل الحادث تبين أن مالك السيارة أثناء مغادرته منزله وإستعدادة لركوب سيارته لاحظ أن شنطة السيارة مفتوحة وبعد تفقدها اكتشف سرقة الإطار الاحتياطي ومفتاح العجل والكوريك كما لاحظ فقد كالون قفل غطاء الشنطه ..ثم ترك سيارته وصعد إلي شقته ونزل بعد فترة وجيزة فوجئ بسرقة السيارة كلها .. ويتضح أن الجاني قام بفك قفل الشنطة وتصنيع مفتاح للسيارة المصنوع بنظام الماستر وبالتالي تمكن من فتح السيارة وتشغيلها أيضا .
· أحدى الزميلات كانت تسير بسيارتها و برفقتها والدتها وأثناء سيرها بإحدى المناطق الشعبية فوجئت باصطدام أحد الأشخاص بسيارتها من الجانب و عندما توقفت تجمع المارة حولها و حضر أحد الأشخاص و أوهمها بإصابتها لأحد الأشخاص و طلب منها مغادره السيارة لعلاجه ولم ينقذها من هذا المأزق سوى إصرارها على عدم مغادره السيارة و حضور أحد الأشخاص الذي شعر بحدوث حاله احتيال و نصب حيث قام بفض الموقف و السماح لها بالانصراف .
· إحدى الزميلات كانت تسير بسيارتها و فوجئت بسائق تاكسي يشير إليها بالتوقف فوراً لوجود عطل شديد بالسيارة وعندما توقفت أشار عليها بترك السيارة في الطريق والذهاب معه لإحضار ميكانيكي لإصلاح السيارة وعندما شكت في الأمر لم تلتفت إليه واستمرت في السير وعند عودتها من نفس الطريق فوجئت بنفس الشخص وهو يشير الي احدي السيارات لتكرار نفس المحاولة.
· أحد الأشخاص إثناء جلوسه بشرفة منزله ليلاً شاهد احدي السيارات المجهزة لرفع السيارات تقف أمام سيارته ونزل شخصاً حيث قام برفع سيارته وأنطلق بها ولم يستطع اللحاق بهم
· أثناء سيرى بطريق النصر بمنطقه منشيه ناصر شاهدت أحد الأشخاص يهجم على السيارة التي أمامي و يخطف موبيل من يد سيده أثناء حديثها فيه وبجوارها زوجها ويسرع بالهرب في اتجاه المدافن.
الزملاء الأعزاء
بالتحليل الأمني لهذه الحوادث يمكن الخروج ببعض الاحتياطات الأمنية الآتية :
· ضرورة تركيب أجهزة إنذار حديثة مرتفعة الحساسية لإعطاء الإنذار المبكر عند محاولة اقتحام السيارة كما يمكن الاستعانة بقفل الدر يكسون لزيادة التأمين.
· السيارات التي تستخدم مفاتيح مزودة بدائرة الكترونية مؤمنة يستحيل تشغيل محركها بدون المفتاح الأصلي.
· ضرورة غلق أبواب السيارة ورفع الزجاج أثناء السير أو عند التوقف اللحظي بإشارات المرور الضوئية.
· الحرص الشديد على عدم ترك مفتاح التشغيل داخل السيارة لأي سبب من الأسباب حتى لو بداخلها أحد .
· عدم ترك أشياء ثمينة أو حقائب أو تليفونات بطريقة ظاهرة تلفت الأنظار أليها داخل السيارة بما يشجع على اقتحامها لسرقة ما بها .
· عند وقوعك في أي مأزق يجب مراعاة عدم التسرع في مغادرة سيارتك وتمالك أعصابك وحاول الاتصال بأقرب شخص لنجدتك أو الاستعانة بأقرب تواجد أمنى بالمنطقة.
· الحرص على اختيار المكان الآمن لمبيت سيارتك بما يعيق جرها أو سحبها أو العبث بها.
· اليقظة و الانتباه أثناء التواجد داخل محطات البنزين أو الجراجات والحرص على عدم ترك السيارة بدون تأمينها مع ملاحظة تواجد
· أي أشخاص غرباء حولك بدون أسباب واضحة.
· عدم التهاون في التأمين على سيارتك لدى شركات التأمين ضد المخاطر المحتملة .
· تفادى وتجنب الانشغال في أى أحداث خارجية قد تفقدك تركيزك عن القيادة .
أعلم جيدا أن اللص أو النصاب يختار وينتقى ضحاياه بعناية شديدة وينتهز اى فرصه أو سهو أو نسيان أو هفوة بسيطة لاستغلالها للهجوم عليك الأمر الذي يستلزم عليك توخي الحيطة و الحذر مع سد أي ثغره قد تمكنه من تهديدك أو السطو على ممتلكاتك .
تمنيات بحياة آمنه سعيدة ,,,,
عميد / نشأت عبد الستار
Subscribe to:
Posts (Atom)