Clone a VirtualBox disk

Duplicating a disk for a new VirtualBox VM requires addressing the disk UUID conflict with same value. The following steps address this matter.

1. Start VirtualBox graphical interface (GUI), and edit settings for the VM using the disk we wish to clone. E.g VM name is centos and the virtual disk as centos_hdd.vdi

2. Remove (Do not delete) this disk from the VM.

3. At a command prompt
VBoxManage clonehd centos_hdd.vdi copy_centos_hdd.vdi
VBoxManage internalcommands setvdiuuid copy_centos_hdd.vdi

The first command duplicates the virtual disk. In the second command we assign a new UUID to the new disk (copy_centos_hdd.vdi)

4. Return to VirtualBox GUI and attach back the centos.vdi to the VM.

5. Create a new VM to attach the copy_centos_hdd.vdi

The new virtual machine is ready to use the cloned virtual disk. As a note, why not just make more copies of the disk with new UUIDs in case you need another image.

An Open source software antivirus called ClamAV

The ClamAV is the only OSS implemented on a large scale with a consistenly updated virus database.

It can be used in 3 different ways:

1. Installed on a PC. It can be scheduled to run at specific times or to scan all new storage medium and incoming files.
2. Installed on a server. It is used in conjunction with server services such as email servers, backup and file servers.
3. Application built with the ClamAV library. Customised applications can manage how and when the file scannings are done.

There are lots of cool features that is comparative to proprietary antivirus. As of June, it is rank as the top 10 antivirus in terms of virus detection.

I just ran an update, output as below:

daily.cvd updated (version: 13231, sigs: 130699, f-level: 60, builder: arnaud)
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Current functionality level = 58, recommended = 60
DON'T PANIC! Read http://www.clamav.net/support/faq
bytecode.cvd is up to date (version: 143, sigs: 40, f-level: 60, builder: edwin)
Database updated (976953 signatures) from db.local.clamav.net (IP: 222.124.18.201)

Configuration of the ClamAV installed can be inspected with the command clamconf, and the virus scanner GUI is simple to use.

Linux security checklist

The Anonymous is announcing an attack on www.malaysia.gov.my, which is a central portal to reach all other Malaysian Government portals. This is reported by F-Secure Corporation and theStar, 14 Jun 2011. Makes you wonder why Anonymous would want to do that.

Follow up from my previous post, I realise that many Linux Admins out there do not have a Security Checklist for their web application. I am sharing the following checklist here as it provides a standard security consideration for almost all web application on Linux or LAMP stack. It is by no means the only security guide, please apply all other security concerns specific to your needs and you can then sleep better at night.

Check List for Web Application (deployment)

Category	Item	Notes
Logins
A.1	Operating system -Administrator password is secured and recorded as only accessible by ONE administrator -All login's are done as normal user -Normal users with access to Administrator priviledges are recorded. Access should be via SUDO. -All logins are recorded
A.2	Application -All users to have secured logins -Administrator logins are assigned to specific individuals and listed -Web based self registered user must have email and spam prevention facilities -Lock down on Web server's user/application access -Default access and password for all administrator applications must be secured. This includes the main application, phpmyadmin, firewall.
A.3	Database -Each application to have a specific user and password access. This user cannot access other databases. -Administrator access is with secured password. Assignment to specific individuals must be recorded.
Services
B.1	Disable unnecassary services -Firewalls must be enabled to restrict external access to only the approved application (via port numbers). -Identify every services running. Disable those not in use. -Remote access must be via encrypted protocols -Disable local email server (e.g. sendmail) from runnin/listening continuously. Or use external email server. -Email servers controlled to allow access to specific application and directories. -Anti-virus if implemented, must have patches and pattern updates kept to the most recent.
B.2	Create a base point of security -A penetration test must be carried out. The type and complexity is based on the specific application. -Establish an integrity check point
B.3	Tell them you do not allow access -Place warning messages to all points of access. E.g. motd and issue.net
B.4	Logging -Log activities to separate files for operating system and application. -Make logs available to a centralised log server.
B.5	Backup -Establish a backup plan. -Implement a backup process
B.6	Create a boot disk and rescue of the Linux
B.7	System updates -Disable the automatic system updates. Updates should be installed only after it is verfied working with the application. -Periodically check with security issues, respective application security notices and update as needed.
Physical
C.1	Physical Access -Ensure only authorised personel can access to the server. -A record of physical access is maintained.
C.2	Storage Media -All storage media is tagged. -Storage location and transportation is secure and recorded.
C.3	Security Policy -Ensure the document is readily available to authorised users.

Checklist for Web Application (Deployment) by Nicholas A. Suppiah is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Permissions beyond the scope of this license may be available at http://www.blogger.com/profile/06749525177696246387.

Linux security for organisations

Linux provides a great solution for small and large organisations. Its scalability and reliability have been continuously promoted over the years as reputable organisations keep adopting them.

The recent spate of security breaches at Citibank, USA and Sony Online Entertainment (SOE), Sony Playstation tells us a lot about the amount of importance organisations put on security. In 2009, There were words that Citibank was robbed and in 2011, there was a breach to over 200,000 USA Citibank card holders in the Citigroup. ZDNet in 2011, "Sony security hole exposes another 24.6 million accounts" tells about how over 100 million users can be affected by failures on security. Maybe Sony Certified Security Professional needs to consider a systems security program for Sony (I am joking).

Other security compromised news (hacked) in 2011

• Vendor-sec email list was compromised and this was a discussion on linux vulnerabilities at openwall.com
• Wordpress.com root access was gained to their servers. Nothing else much on extend of damage to users or blogs at wordpress.com
  
• Mobile devices like Android could potentially have user data compromised when using public wifi, says University of Ulm, Germany
• International Monetary Fund (IMF), network break-in sounded like it was blamed to the staff use of internet and emails when read in ZDNET.
• Lockheed Martin, provider of defence technology breach in their remote access via use of tokens affected Pentagon.
• GMail major phishing was traced back to China and Google looks geared up for more changes as spear-phishing becomes a term many would see more often.
• In Malaysia, the newly launched 1Malaysia Pengguna Bijak's portal costing RM1.4 million wasn't built with safe guarding the users information at all. Here the only explaination (NO apology to the rakyat) was that the system was not built to cope with the 3 million hits it received within 2 days of its launching. Over 2,000 1Pengguna user account details were confirmed compromised. I took it as a government initiative but the name www.1pengguna.com made me wonder if its a Malaysian government effort or a private business.
  

Over the years of implementing Linux based solution, there are a few basic things I can share when deploying web applications and other similar systems.

1. Put a security policy in place. This includes security administrators reading emails from public who voluntarily lodge about security flaws.
   
2. Budget to implement these policies
3. Have security checklists (use it, audit with it)
   

If disaster happens, you just need to fix it. There are people's "life" at stake. At the same time get those culprits, if you can.