Digital Patch - Linux, Open Source & Technologies Tutorials

Implementing Singleton Design Pattern with PHP 5 (only-one persistent object in Session, MVC approach, etc.)

2011-09-26T11:27:00.000-07:00

(Draft version, It could be improved or modified)

Introduction

In this article I'll explain you how to implement an application based on Singleton design pattern by using object oriented PHP 5.x.

Before starting, You must know some concepts for understanding the whole article.

Please, read the paragraph below before continue.

Requirements

You need to know:

1) The concepts about "static" methods and properties of a Php Class

2) What is a MVC (Model / View / Controller ) paradigma and how it works

3) What are "sessions" in Php and how they works

4) Obviously you need to know the "Design Patterns" concepts and in particular what is a "Singleton"

Let's start

Before starting, I think that is important to specify that every time you call a PHP script, all the variables, handlers, etc. will "born" when the script is called (request) and they will be "destroyed" when the script ends.

Indeed for the Php engine, every script is considered a stand alone "entity" althought it is part of an application (Shared Nothing Architecture); each script must be considered "unlinked" from the status of the other scripts(... and itself if you call it one more time...);

This means that every time you need to process something in different scripts (e.g. database, files, variables, objects, etc.) you need to re-open a connection to a databases, re-instantiate and object, etc.

If you need to pass internal information between scripts (eg. a value, a correct users authentication, permissions, etc.) you need to use "sessions".

By using "session", you can store values (or sometimes entire objects) and passing them between scripts; by using this method you can "simulate" a persistence of data in your "application" and a "connection" between scripts(in a similar way of Java).

Note that:

1) Php resources (like db connection or files handlers) cannot be stored into session, so you need to reopen them in EVERY script.
2) The session allows the developer to store information for each single user, so information cannot be "shared" between users

Some notes about the implementation of the singleton design pattern with PHP

What I wrote previously is very important according to the "Singleton" concepts (when applied to Php).
Singleton-model based class indeed requires that its "status" must "survive" in the whole application and not on a single script, so the only way to satisfy this concept is the use of Php Sessions.

Another important thing, because Sessions cannot be shared between users the application cannot have a single istance of a Singleton class, but a the developer had to create an "indipendent" singleton class for each user.

A pratical example of Singleton design pattern

When you read about Singleton on blogs, books, magazine you'll find that it is usually used for storing the "status" of the actions made by one or more users into an "application". In other words they talks about "logging".

The code that you'll find in this page, will show you how to keep track of clicks on one or more php pages by using a only one object (which implements singleton) that will be "passed" between scripts.

As required by the singleton design pattern, only one object will we created by using PHP static members and properties. Before the end of the excecution of a script, the object is serialized and stored in session so it'll survive to the "garbage collector" of the Php engine.

The Code

In the example, I use a separation between business logic and view (html pages) so it's more easily to describe code and make the things "clean".

If you don't know this coding approach on Php, I suggest you to take a look to Model/View/Controller (MVC) concepts by googling around.

Anyway, files involved into the example are:

header.html - This file will be included in view scripts for generating a valid "header" for xhtml document (page1.php, page2.php, clear.php, print.php)

footer.html - This file will be included in view scripts for generating a valid "footer" for xhtml document (page1.php, page2.php, clear.php, print.php). It also displays a set of links for calling every page of the "application".

controller.php - This file is the "controller" for the MVC model, it receives the parameter "func" by GET method and selects the correct action. When no parameter are passed, it'll will call the print.php script that shows the content of the "log" stored into the singleton object

singleton.class.php - The implementation of a very simple class based on the Singleton design pattern.

page1.php - When you click on the link for page1 (showed by footer.html), the controller.php will be called, it will store on the log (by using singleton object) a "track" of the page calling than it will show page1.php. This page represents one of the "view" side of the application.

page2.php - Same as page1.php

clear.php - It'll clear all the log entries

print.php - When you click on the link for page1 (showed by footer.html), the controller.php will be called, than the content of the log will be showed on the browser (taken from Singleton object)

The aim of the whole application is to show how the singleton object will be inherit one time only and, because it's stored on session, it'll survive to garbage collecting of the Php Engine. Indeed it's status (log lines) is not lost.
For details about how every file works, see comments inside code.

Note: All the code inside is released under GNU/GPL license version 2.1

The singleton class (singleton.class.php)

The controller (controller.php)

<?phpsession_start();require "singleton.class.php";// Get parameter for controllerif(isset($_GET["func"])) $func=(int)$_GET["func"]; else $func=0;// Persistence of singleton object by using web server session if(isset($_SESSION["my_singleton"])) {// When the singleton object is serialized/unserialized// for passing it via $_SESSION// the value of static variables of the object will be lost// so you need to re-assign to the static $instance// the object by using restore_instance member (setter function)// after getting it from the $_SESSION  $singleton=unserialize($_SESSION["my_singleton"]);   $singleton->restore_instance($singleton);  }else  { $singleton=singleton_class::get_singleton(); $singleton->add_log_line("Logging start at:\n "); }switch ($func){ case 1:  $singleton->add_log_line("PAGE1 ");  require("page1.php");  break; case 2:  $singleton->add_log_line("PAGE2");  require("page2.php");  break; case 3:  $singleton->LogReset();  $singleton->add_log_line("Log reset ");  require("clear.php");  break; default:  $singleton->GetLog();  require("print.php");  break;}$_SESSION["my_singleton"]=serialize($singleton);?>

The Page1 view (page1.php)

The Page2 view (page2.php)

The Print log view (print.php)

The log reset view (clear.php)

The "header" and "footer" template files

Filename: header.html

Filename: footer.html

Some "Screenshots"

Example1 - controller.php called without parameters

Actions logged

Line 0: Logging start at: logged at 2011-09-26 16:09:54

Main page | Page 1 | Page 2 | Clear Log

Example2 - controller.php called with parameter func=1

(The page1 is "visited", so a line in the log is stored)

PAGE1 LOGGED

Main page | Page 1 | Page 2 | Clear Log

Example3 - controller.php called without parameters but the with 1 event in the log

Actions logged

Line 0: Logging start at: logged at 2011-09-26 16:09:54
Line 1: PAGE1 logged at 2011-09-26 16:09:18

Main page | Page 1 | Page 2 | Clear Log

Notes

I hope my code will help you! Let me know! ;)

See you, sincerely

Angelo Fonzeca

Digital Patch Posts by Angelo Fonzeca are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.

How-to: Harden a Linux Web Server (Overview)

2010-10-15T07:14:00.000-07:00

Introduction

Last weeks on "System administrators" group on Linkedin, the members talked about how to harden a GNU/Linux web server for an hacking contest.
Because I think it was born an intersting "to do" list about the argument during a post of mine, I have taken the decision to report in this article the ideas and my vision of the problem.

The following words are what I wrote...

Hardening Linux step-by-step

If you need to protect a server with in mind an high level of security, I suggest you to think to three level of hardening.

High level (client side web services)

You should consider what type of “services” will run “inside” your daemons.

For example: a “LAMP application”, CMS or “simple html pages”

In the first two cases you should harden every service like Linux Kernel(see next), Apache web server (and its modules), Mysql and Php.

One of the best solution for Apache, as told previously, is mod_security. It allows to deny some types of escalation by blocking some possible attack techniques. This also helps to improve the strength of the whole services, because potentially could block issues relative to some technologies (e.g. Php bug/Exploit) not fixed yet by the O.S. Vendor. Mod security also logs every attack.

You should also:

write your php software (and configure mysql) to deny, for example, sql injection
modify php.ini properly and use some solutions like “Suhosin”

If you use only “html”, you could use only mod_security.

Mid level ( System services – Mailserver, OpenSSH, etc.)

If an attacker will pass the previous protections, you should give to your system service a second possibility to “survive” and/or block priviledges escalation.

A good start is isolatating every service by using chroot. Postfix, for example, supports natively chroot environments. Apache and other services can be used in chroot without problems by following how-tos around the web.

Low Level

If the attacker will pass the previous two levels... He is skilled and smart! :)

So, if you want to really improve the strength of your system... you should use patched kernel and MAC (Mandatory Access Control) to limitate damages and (maybe) it could prevent root escalation.

If an attacker will pass ALL the previous protections, he will win the contest! (No good thing... I think )

Last but not least...

Many daemons can be hardened to prevent attacks in easily manner by using their internal configuration. Indeed all the services you use on your system could introduce security issues. But for each one there is a solution ;)

In particular in the past - on my blog - I wrote a set of articles regarding the hardening of OpenSSH (if you need to have access to your system remotely):

* OpenSSH daemon hardening - Modify the configuration file

http://digitalpatch.blogspot.com/2010/02/introducing-openssh-openssh-is-deamon.html

* How to use RSA/DSA Keys

http://digitalpatch.blogspot.com/2010/02/openssh-hardening-part-2-how-to-use-rsa.html

* Setup a chroot environment on CentOS 5 with JailKit

http://digitalpatch.blogspot.com/2010/03/openssh-daemon-hardening-part-3-setup.html

* File Integrity Checkers and Rootkit Revealers for Gnu/Linux (incomplete)

http://digitalpatch.blogspot.com/2010/04/file-integrity-check-and-rootkit.html

As told previously for the Apache webserver you should use "mod_security", a sort of "firewall" for the http protocol (it is useful for preventing attacks to php apps and/or unsecure modules of Apache or bugs not fixed yet). You will find other info at http://www.modsecurity.org/

For preventing brute force attacks to OpenSSH (e.g. password guessing) you could use fail2ban. See

http://www.fail2ban.org/wiki/index.php/Main_Page

If you are "paranoic" (read: high level of security for critical server) you should use:

Grsecurity - http://grsecurity.net/

SELinux - http://it.wikipedia.org/wiki/Security-Enhanced_Linux

All the above "fixes" will help you to prevent the escalation of priviledges to attackers at many levels.

Finally:

Keep your distro updated (apt-get, yum, etc) and check logs
Turn off the running services that aren't important for the aims of your server and keep secure your polices.
Don't give your users the option to choose "stupid" (not too much complex) password

One more suggestion!

If you are interested in IT Security, join us at "GNU/Linux Security & Hardening" group on Linkedin

Thank you.

Bye

Your

Angelo F.

Digital Patch Posts by Angelo F. are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.

Based on a work at digitalpatch.blogspot.com.

GStreamer Introduction (Draft Version)

2010-09-27T06:48:00.000-07:00

Introduction

In this post, I'll give you an "introduction" to the "GStreamer Framework", which allows easily manipulation/transformation of digital "media" like audio, video, etc. under GNU/Linux and Windows.

What is GStreamer?

GStreamer is a framework, specifically a set of libraries written in C language, which allows a developer (you) to manage/manipulate/transform multimedia content through a standard programming approach which can be applied to sound and/or video data.

Key concepts of the tools are the use of elements concatenation, each with a very specific function, and the so-called "pipeline".

The correct approach is to view "elements" and "pipelines" as a sort of "blackboxes" which are linked together using special "Links".

This allows to pass the content (e.g. mp3 file), produced by a single element, to another element - by using the pipeline - thanks to the use of Input / Output "ports" (Called pad sink / source pad).

Thus an information can be introduced into the pipeline cascade process, so it will pass between multiple

"stages" to be manipulated, transformed, then it can be stored and/or played.

A classical example is the need to convert a media file in the format "x" into a media file in the format "y".

If this operation is made from scratch by a programmer, it is required in-depth knowledge of both formats and the necessary expertise to treat them, interpret and make the appropriate conversions.

What happens if is it necessary to convert the file to another format "z"?

It would be necessary to modify most part of the software for interpreting information and convert and adapt it appropriately to the new format.

This structure will be particularly rigid and it not will be easy exchange "direction" between source and destination (eg. convert "z" format "x" format) unless start defining standards for interfacing and makes interchangeable the various stages( e. g. random concatenation of the stages )

The approach of the GStreamer framework is an 'extremims' of this concept.

It basically uses 'black box' with specific functions (manipulation of audio or video) and the possibility to create a concatenation - in an arbitrary manner - between them (pipeline) so the developer can easily solve all problems exposed in the previous example.

The following is a brief definition of the elements that are part of "Gstreamer" with the specific methods for operate with them.

Elements

The main concept of the framework is the 'element' (also called plug-in). It's a sort of 'black box' that against a number of inputs and outputs "ports" - called "pads" - is able to manipulate (modify or transform) an information (eg Convert an information in "x" format into an information of "y" format).

There are three types of elements, namely:

● Source elements, these elements are able to 'introduce' data into the pipeline flow. Consider, for example, an element capable of reading information sampled and digitized through a sound card in your PC and turn it into inside the pipeline in a very specific format (e.g. raw samples)

● Sink elements, these elements - placed at the end of the chain in the pipeline - allow to store/redirect a manipulated "data flow" to a destination such as a file or an hardware device (eg. soundcard audio output)

● Filter elements are those 'black boxes' that have one or more inputs and one or more outputs and essentially allow the manipulation of information (e.g. raising the volume of a sound of a certain percentage, add delay effect, chorus effect, etc.)

The elements are connected by the "links'" by using special inputs or outputs ports - called pads - which allows the "communication" between "black box(elements)".

Link pads, caps

A 'link' represents a connection between the output of an element to the input of another, which allows of enriching the content between "black boxes" connected in series. The inputs and the outputs ports are called "source pads" and "sink pads"; pads can be connected to each other only if there is a "compatibility" between them.

For example, you can connect two elements that manipulate sounds with pads that are "compatible" with data processed (e.g. use of sounds with 16bit format, 44.1kHz sampling, in raw form by both).

To determine if a pad "output" is compatible with a pad "input", each of them has an associated information called "capabilities" (Caps) that can provide if an "element"can be properly connected.

It is also possible to set the elements for using a particular format, according with requirements (of course if they provides multiple formats).

By analogy with reality, you could consider a sound system that consists of an electric guitar, a "distortion" effect and an amplifier.

In this case the guitar is the "source element" , thanks to its output jack connector (Source pad) and its cable (link) carries the sound into a distortion effect (filter element) that with it's input port transforms (distort) the sound and put it out (Source pad) - by another cable (link) - to the amplifier that reproduces the sound (sink element).

The caps in this "real" case represent the physical specifications of the connectors of each device, the currents involved, the impedence, and the electrical signals that every device can receive and emit.

Thread, State, and Signal Bus GStreamer

Once the developer has defined the pipeline and properly set the link between the pads of each element involved, it is easy to start the processing of multimedia data.

This is done by setting the value of the "state" of the pipeline and its elements.

The states where a pipeline can be (or be forced to be) are different and they are described below:

1) GST_STATE_NULL "Default state" - Resources are not allocated and are de-allocated if comes from a different state

2) GST_STATE_READY - Resources are allocated and ready for use

3) GST_STATE_PAUSE - The resources are setting up but currently "paused"

4) GST_STATE_PLAYING - Resources are processed by the elements in the pipeline

Once a pipiline is set to the status of 'Playing', It will start a separate threads (a part of code that runs as 'individual' and in 'parallel' respecting to main program) managed directly by the framework.

When in "playing" state, the process above takes the flow of multimedia data from the source pad and gradually pass it between the various "stages" (elements) of the pipeline.

Each one will makes its appropriate data processing and then pass the result through its sinkpad.

However, this thread is totally separate from the user control which cannot act directly during the whole process.

For this reason GStreamer manages the so called 'signals' and uses the concept of 'bus'.

Basically the information signals are sent to the various elements by the programmer in order to allow the intervention on the data flow in "real time".

These signals "pass" through the "bus". The bus can be constantly questioned (polls) or, if specific signals are present, it is possible to call special functions connected to them.

Usually the signals are intercepted asynchronously. They are placed in a "queue" and none can known when the framework will examine the signal flow.

However, with proper precautions, you can force the interception of synchronous signals, so you can check and control the pipeline in "real time" manner, when an event occurs.

As discussed below, in fact, sometimes it is appropriate to intercept signals synchronously when a specific characteristics is changing 'in progress' and in the exact moment when a 'signal' is issued.

What's next?

In a future post I'll show you how to use GStreamer with C language(under GNU/Linux) starting from a real "case" of audio manipulation.

Stay tuned!

Digital Patch Posts by Angelo F. are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.

Based on a work at digitalpatch.blogspot.com.

How to survive to OpenSuse 11.3 upgrade on PCs with NVIDIA Video Cards

2010-07-18T01:40:00.000-07:00

Introduction

In my opinion OpenSuse is one of the best GNU/Linux distribution... It is stable, it has maniac precision for the particulars, "branded" desktop... so you are REALLY productive since the first login and It's cool!

Another invaluable feature is th "YAST2 tool", a very fast, smart and useful control panel for services and system.

Anyway, I use this OS in my production PCs... OpenSuse never disappointed me!

On 15/07/2010 the 11.3 release has been published! I was excited to upgrade my systems (usually I never made upgrade of my OS as soon as a distribution is released, but I trust in Novell/OpenSuse quality of service, so I upgraded).

According to my upgrade experience, in this guide I'll show you how to

Upgrade the system easily (from 11.2)
How to prevent a xorg start failure after the first reboot ( if you have an NVIDIA card )

Requirements

1) Patience
2) Fast Connection (if you have not too much patience)
3) A recent backup of you home directory and important files
4) 8gb free space on your /
5) .........Patience ;)

First step! (Only if you have a NVIDIA card)

Go to http://www.nvidia.it/Download/index5.aspx?lang=en
Select your operating system (Linux 64bit or 32bit) and your language
Accept agreement if you like it, then click on buttons for download.
Download the file NVIDIA-Linux-x86_64-256.35.run (or newer)
Save it into your home directory!
Connect your pc to UPS!

Step two!

Briefly, go to your terminal console, become "root" and follow these steps (full description here):

1) Run

zypper modifyrepo --enable repo-update

2) Add the update repository

zypper addrepo --check --name 'openSUSE-11.2-Update' http://download.opensuse.org/update/11.2/ repo-update

3) Update the system

zypper refresh
zypper update

4) Install your kernel source (will be used later...)

zypper install kernel-source

Step three! It's time to upgrade

Disable old repositories

zypper modifyrepo --all --disable

And set the 11.3 repositories

zypper addrepo --name "openSUSE-11.3 OSS" http://download.opensuse.org/distribution/11.3/repo/oss/ repo-11.3-oss
 zypper addrepo --name "openSUSE-11.3 Non-OSS" http://download.opensuse.org/distribution/11.3/repo/non-oss/ repo-11.3-non-oss
 zypper addrepo --name "openSUSE-11.3 Updates" http://download.opensuse.org/update/11.3/ repo-11.3-update

Then write

zypper ref

Finally write

zypper dup --download "in-advance"

The previous command downloads all the packages before upgrading (more and more secure procedure). Go away from your system and come back... the next day...

Step four! Many hours later... (Keep attention! Before rebooting make the following modify! )

With your favourite editor (eg. vi, nano, etc), edit the following

/boot/grub/menu.lst

Search for:

###Don't change this comment - YaST2 identifier: Original name: linux###
title Desktop -- openSUSE 11.3 - 2.6.34-12
    root (hd0,6)
    kernel /boot/vmlinuz-2.6.34-12-desktop root=/dev/disk/by-id/ata-xxxxxxxx resume=/dev/disk/by-id/ata-yyyyyyyyy splash=silent quiet showopts vga=0x314

(note: root and resume parameter could be different)

After vga=0x314 option add the following

nomodeset

So the line will be like this:

###Don't change this comment - YaST2 identifier: Original name: linux###
title Desktop -- openSUSE 11.3 - 2.6.34-12
    root (hd0,6)
    kernel /boot/vmlinuz-2.6.34-12-desktop root=/dev/disk/by-id/ata-xxxxxxxx resume=/dev/disk/by-id/ata-yyyyyyyyy splash=silent quiet showopts vga=0x314 nomodeset

Step five! Reboot and fix!

It's time to restart the system! If you haven't NVIDIA card your system will start normally, else follow these steps:

1) With NVIDIA cards.... if all has been done well... the xorg won't run! ;) No panic! Login with your usual account, then become root.

2) Go to the your home directory, change runlevel and run your NVIDIA card driver setup with

telinit 2

sh ./NVIDIA-Linux-x86_64-256.35.run

3) Follow the NVIDIA setup steps

4) Reboot your system

5) Now it should be ok else... write me!

Enjoy with your new OpenSuse 11.3 and NVIDIA Cards! :)

A>ngelo F.

Update

if you use the command

zypper dup --download "in-advance"

you could interrupt the download as you like (ctrl-c)

when you restart the command above the system will download starting from the last package retreived.

Digital Patch Posts by Angelo F. are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Based on a work at digitalpatch.blogspot.com.

How to run and test Android 2.2 Froyo SDK on OpenSuse 11.2

2010-06-05T11:29:00.000-07:00

What is Android?

Android - in my opinion - is one of the best O.S. for smartphones; anyway it could be interesting to run it on your PC because it could help you to test software before installing on your real device, for developing purpose or... Just For Fun!

There are two solutions to reach this aim:

1) The first option is to use Android on real or virtualized hardware by download Android X86. Currently you can run only the 1.6 or 2.0 old version. (But it supports EEEPC too).

2) The second option (explained in this tutorial), is "emulating" the Android 2.2 Froyo environment by using the SDK from Google (Usually used for development purposes....)

Ok, we have chosen the option two! Another requirement is that we want to install the platform on Linux/OpenSuse 11.2... How can we do it?

The answer is... follow these steps ;)

Note for mobile lovers: Android is a powerful GNU/Linux based OS and it has many web2.0 oriented application easy to install by using the appliance "Android Market", so I suggest you to give it a try if you make the decision to buy a new smartphone! You will love it! (Note for readers: Android Market doesn't works on SDK Version...)

Step 1- Download and install the Android SDK for GNU/Linux

Get it from http://developer.android.com/sdk/index.html

after the download, open the terminal and unpack the SDK by using:

tar zxvf android-sdk_r06-linux_86.tgz

now go to Android directory by typing:

cd android-sdk-linux_86

and write:

tools/android update sdk

{followed by enter key...}

After that, a GUI will be started...

Now, unselect all platform - by double clicking on title - but not:

1) SDK Android 2.2 and Samples for API

2) Click on "Accept" and then on "Install"

3) Wait for platform download

It could take a long time... Take a cup of tea ;)

When the download is finished, click on "CLOSE" button

You should be in the situation showed on the following snapshot:

Now go to "Virtual Devices" option and click on "New" button.

On the popup window write as title "Froyo", and select as target "Android 2.2 - Api Level 8".
Then choose "Size" for sd card (e.g. 900MB); now select your resolution as showed in the following picture:

then click "Create AVD" button.

Exit from GUI and from the command line
write:

tools/android

{followed by enter key...}

Now click go to "Virtual Device", select "Froyo" and click on "Start"... Wait... Now you have an Android 2.2 test system on your PC! ;)

Let me know! Enjoy! Bye

Digital Patch Posts by Angelo F. are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Based on a work at digitalpatch.blogspot.com.

How to easily setup VNC Server on Windows Clients in LAN Enterprises Environments

2010-05-06T02:16:00.000-07:00

Introduction

How many time during your administration of many Pc Windows Clients do you say "If I was there..."... and the second thought is "...I could use UltraVNC for remote managing but it's too difficult to install for that user..."

A good compromise in this situation is creating and share UltraVnc in Lan in a customized and simplified form (very easy to prepare).

So, according to this article, you can easily improve the user vnc setup experience (and you needn't to take away from you nice office chair... ;) )

It's simple

1) Make a folder (eg. _VNC)
2) Download latest version of VNC setup from http://www.uvnc.com and save it in the new folder
3) Rename the setup file to "UltraVNC.exe"
4) Create setup.bat script (if you use Linux remember to call unix2dos after making the file) with this lines inside:

net use v: /del
; REMEMBER change the following line with the path of you share folder on lan....
net use v: \\share\utility\_VNC
c:
cd \
"%PROGRAMFILES%\realvnc\vnc4\unins000.exe" /silent
net stop uvnc_service
sc delete uvnc_service
start /w v:\UltraVNC.exe /verysilent /loadinf=v:\ultravnc.inf
net stop uvnc_service
xcopy v:\ultravnc.ini "c:\UltraVNC\" /R /Y
net start uvnc_service
net use v: /del

5) Save it into your folder (eg. _VNC)
6) Make a simple ultravnc.inf file with this lines inside:

[Setup]
Lang=en
Dir=c:\UltraVNC
Group=UltraVNC
NoIcons=0
SetupType=server
Components=ultravnc_server
Tasks=installservice,properties

7) Save it into your folder (eg _VNC)

8) Now you should have in your _VNC directory:

UltraVNC.exe

ultravnc.inf

setup.bat

9) If it's all ok, copy the _VNC folder to your shared folder and test by running setup.bat

10) This procedure installs a very basic UltraVNC server

11) Call the user that needs your help in LAN, and guide him to start the simplified setup

12) If you like, you could improve ultravnc.inf for having DSM plugin or others functionalities into setup... Please refer to this article for further details.

Have a nice day!

Sincerely
AngeloF.

Digital Patch Posts by Angelo F. are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Based on a work at digitalpatch.blogspot.com.

File Integrity Checkers and Rootkit Revealers for Gnu/Linux - Part 1

2010-04-12T09:25:00.000-07:00

Introduction

Are you afraid that your system has been compromised by an unauthorized access?

Have you got discovered abnormal network activities and/or do you suspect that your system has been infected by trojans or rootkit?

Is this your nightmare? ;)

No problem, there are some solutions which help system administrators to check their servers, so they can be more serene about security of their machines.

Two types of "tools" can be used to search anomalies into the system.

The first ones are called "File Integrity Checkers" (FIC) and can be used to check if a set of files has been changed during time.

For example, if you keep track of changing of the executables into folders like "/bin", "/sbin", etc. you can see if "someone" has changed "something". In this case, FIC will notify you about that.

Obiviously changes on executable could be normal (e.g. system updates), in this case you can notify your "File Integrity checker" (FIC) that changes are authorized.

On the other hand, your system could be compromised, so if you haven't done any upgrade or manual modifies to the system, the FIC can give evidence of changes.

This type of software, may be considered one of the solutions available for discovering something wrong.

The second type of "checkers" is called "rootkit revealers" and/or "antivirus". This can be considered "similar" to the windows security tools available today like Comodo, Avast, Norton, Spybot, etc.

Usually these tools are not "realtime" like MS Windows products so they must be run using cron daemon.

For the best protection of your GNU/Linux systems, you should consider the use of MAC (Mandatory Access Control) or RBAC.

For example, GRsecurity/Pax or Selinux add this feature to GNU/Linux (by patching the kernel).

I will discuss about them in my future posts.

Anyway, "rootkit revealers" and "antivirus" software should help you to identify which kind of "enemy" has compromised your system.

File Integrity Checkers (FIC)

There are many FIC software around, one of the most famous in the Unix environments is "Tripwire". By the way, I prefer "Afick" a FIC that is totally free and more simple to install and use.

Afick, as many other FIC solution, works by making md5 signs of "set" of files, that you will indicate into the configuration file the first time you use it.

For example, if you want keep track of the modifies of the /bin directory, Afick will generate a databases of all the md5 sign of each file contained into that directory.

The next time you will run Afick, it will check if the md5 sum of each file are the same of its database, if not it will notify you.

If you modify or update the system, you can notify Afick to update its database without producing warning alerts.

FICs are very simple and smart but they have some limitations.

1) You must keep track of each operation of the system that could modify your files and "notify" afick about modify

2) If the system will be compromised and some executable and/or file used by FIC software will be modified too, it will give you false "negatives".

So, if you suspect that something is wrong into your system, it's usefull running FIC software by starting your system from a bootable CD (e.g. Knoppix) and check it.

What are the rootkits?

A good point of start for defining what "rootkits" are is Wikipedia. It describes them as "A rootkit is software that enables continued privileged access to a computer while actively hiding its presence from administrators by subverting standard operating system functionality or other applications. The term rootkit is a concatenation of "root" (the traditional name of the privileged account on Unix operating systems) and the word "kit" (which refers to the software components that implement the tool). The term "rootkit" has negative connotations through its association with malware.^[1]"

In other words, a rookit is software that allows someone to control or have priviledges on your system... and you (the administrator) you don't know... It's a terrible thing!

Think for a minute how many crazy people are outside there... software pirates, black hats, irc bots installers, script-kiddies, etc...
All of these men, can use your system for bad purpouses.. And you'll pay for them, if they makes illegal things...

What we need to do? There are some tools called "rootkits revealers"... In the second part of this article I'll explain you how to use them. But remember, the first rules is... be "proactive" and harden your system!

Virus/Trojan threats

Virus and Trojans are software that compromize the correct functionalities of a machine.
Virus are spreaded on Windows enviroments, so there are a large number of "antivirus" for protecting these systems.
GNU/Linux Distros usually are not subject to viruses, but the services offered by the O.S. could be "the way" to spread a desease. (E.g. An infected file shared by Samba could infect a windows machine).

So GNU/Linux has many antivirus to detect virus and block them! In the second part we I'll talk about them

One more suggestion!

If you are interested in IT Security, join us at "GNU/Linux Security & Hardening" group on Linkedin

Last update: 7 Dic 2010

Digital Patch Posts by Angelo F. are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Based on a work at digitalpatch.blogspot.com.

OpenSSH daemon hardening ( Part 3 ) - Setup a chroot enviroment on CentOS 5 with JailKit

2010-03-02T08:19:00.000-08:00

[Note: This is a draft version of the post; it'll be revised as soon as possible]

Introduction - What is a chroot?

"A chroot on Unix operating systems is an operation that changes the apparent disk root directory
for the current running process and its children. A program that is
re-rooted to another directory cannot access or name files outside that
directory, and the directory is called a "chroot jail" or (less commonly) a "chroot prison". The term "chroot" may refer to the chroot(2) system call or the chroot(8) wrapper program."

(Definition from Wikipedia, the free encyclopedia)

A system administrator can use "chrooted" environments for improving the strength of a Unix system, by limiting logged users to use a small environment with few/basic functionalities.
Chroot can also be used for "running inside" Unix daemons, so services are "entrapped" into the jail and they can "see" only a limited part of the filesystem.

In this post we will create a chroot environment for giving access to users with sftp/ssh protocol and/or basic shell access.

Note: The chroot environments don't assure "security", but in combination with others hardening tricks (see my other posts) may improve the strength of the system and put "on the way" more obstacles to the attackers.

Indeed a chroot-jail can be break... for example visit chroot break page

Let's start installing!

Step 1 - Download JailKit from

$ wget http://olivier.sessink.nl/jailkit/jailkit-2.11.tar.bz2

Step 2 - Uncompress and install

$ tar jxvf jailkit-2.11.tar.bz2

With a non root user launch:

$ cd jailkit-2.11
$ ./configure
$ make

then

$ su
# make install

Step 3 - Modify the ini file

If you use 64bit version of Debian or other distros (e.g. CentOS) you must change some paths.

Check the jk_init.ini and verify that paths of the sections you are interested in, are correct.

For example:

# vi /etc/jailkit/jk_init.ini

On CentOS 5 we need to change the "paths" parameter with

paths=/usr/libexec/openssh/sftp-server

on Utuntu 8.04 Lts (64Bit) with

paths=/usr/lib/openssh/sftp-server

under the [sftp] section

(save the conf with [escape]:wq)

Step 4 - Let's create the chroot Jail

# su -

# jk_init -v -j /WEBJAIL2 basicshell ssh sftp

The above command creates a jail (called WEBJAIL2) with "basicshell" commands, ssh and sftp support.

Take a look to jk_init.ini for various options available or consult the JailKit manual at http://olivier.sessink.nl/jailkit/jailkit.8.html

Step 5 - Create users

Create with the adduser command a new users as usual.

For example

# adduser sftptest
# passwd sftptest

Step 6 - Put the user into the cage

In CentOS 5 setup, an error occurred if I do not copy first jk_lsh to jail; so I use:

# jk_cp -j /WEBJAIL2 /usr/sbin/jk_lsh

then i can "import" the user to the jail with:

# jk_jailuser -m -j /WEBJAIL2/ sftptest

Step 6a - Sftp/SCP access ONLY

If you want that your server users can have access to the Sftp/SCP only, after the previous steps, you must edit jk_lsh.ini in the jail.

If the jailkit directory doesn't exist, use:

# mkdir -p /jail/etc/jailkit

Now you can authorize jk_lsh command to execute sftp

(If you use jk_lsh "shell" you must specify which command can be executed, indeed jk_lsh is not an interactive shell but it allows the access only via ssh for executing commands in chroot jail)

# vi /WEBJAIL2/etc/jailkit/jk_lsh.ini

An example of jk_lsh.ini for CentOS 5 could be:

[sftptest]
paths = /usr/libexec/openssh/
executables = /usr/libexec/openssh/sftp-server
allow_word_expansion = 0

An example of jk_lsh.ini for Ubuntu 8.04 Lts could be:

[sftptest]
paths = /usr/lib/openssh/
executables = /usr/lib/openssh/sftp-server
allow_word_expansion = 0

Step 6b - Full SSH Access by using Bash as shell

Modify as follow the /etc/passwd into the chrooted environment for example:

vi /WEBJAIL2/etc/passwd

change

sftptest:x:505:506::/home/devel01:/usr/sbin/jk_lsh

with

sftptest:x:505:506::/home/devel01:/bin/bash

then copy .bashrc from your "real" user to the chrooted one. For example

cp /home/sftptest/.bashrc /WEBJAIL2/home/sftptest/

Step 7 - Verify if all is done

Try to view if in /etc/passwd the shell and the path of the chrooted user has been changed:

# cat /etc/passwd | grep sftptest
# sftptest:x:505:506::/WEBJAIL2/./home/sftptest:/usr/sbin/jk_chrootsh

Try if the home directory has been created on the jail

# ls -ld /WEBJAIL2/home/sftptest

If all is ok, then try to connect to the system with

# ssh sftptest@yourserver.net
(if you had used "Step 6b" option)
# sftp sftptest@yourserver.net
(if you had used "Step 6a" option)

If you are logged in, you can browse the jail filesystem; you will see that you can do only simple operation on it

Step 8 - Check the Jail

When you update your system (e.g. by using YUM), it's important to upgrade the files into the jail too; in this way you can avoid security issues.

You need to modify the jk_check.ini file one time with:

# vi /etc/jailkit/jk_check.ini

A very basic content of the file could be:

[/WEBJAIL2]

ignorepathoncompare = /WEBJAIL2/home/, /WEBJAIL2/etc/
ignorewritableforgroup = /WEBJAIL2/home/
ignorewritableforothers = /WEBJAIL2/home/tmp/

# jk_check tests for setuid root and setgid root files
# if you deliberately have such files specify them here
#ignoresetuidexecuteforuser = /home/testchroot/usr/bin/smbmnt, /home/testchroot/usr/bin/smbumount
#ignoresetuidexecuteforgroup = /home/testchroot/usr/bin/smbmnt, /home/testchroot/usr/bin/smbumount
#ignoresetuidexecuteforothers =

I suggest you to run jk_check as soon as possible your distro update procedure is done.

Last trick! See the jk_check command manual for further details about the meaning of the parameters.

One more suggestion!

If you are interested in IT Security, join us at "GNU/Linux Security & Hardening" group on Linkedin

Reference and Links

http://olivier.sessink.nl/jailkit/howtos_chroot_shell.html
http://olivier.sessink.nl/jailkit/howtos_sftp_scp_only.html
http://en.wikipedia.org/wiki/Chroot
http://www.bpfh.net/simes/computing/chroot-break.html

NOTE

Digital Patch Posts by Angelo F. are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Based on a work at digitalpatch.blogspot.com.

OpenSSH daemon hardening ( Part 2 ) - How to use RSA/DSA Keys

2010-02-26T11:39:00.000-08:00

[Note: This is a draft version of the post; it'll be revised as soon as possible]

Introduction

In my previous post, I explained you how to configure OpenSSH for improving its security. By the way, if your SSH service is available on the Internet and accessible by any IP address (e.g. You connect your client on the internet with a dynamic IP address and/or you want reach your server from anywhere...), it can be more exposed to brute force attacks! So a new "hardening procedure" is necessary!

In this case, a good idea is the use of RSA/DSA Keys, instead of a couple of "username/password".

RSA/DSA Keys may be considered a sort of "long and complex" password, which replace the classical "login", and identify in unique manner the owner of the credential.

I talk about DSA/RSA because the setup procedure is the same, but you have the oppurtunity to choose two different types of key generation algorithm with OpenSSH:

RSA ( http://en.wikipedia.org/wiki/Rsa )

DSA ( http://en.wikipedia.org/wiki/Digital_Signature_Algorithm )

How does the RSA/DSA keys authentication method works?

RSA/DSA Keys authentication scheme follows this logic:

1) The sysadmin (You...) generates a pair of RSA/DSA Keys on his system (one is the "private key" and the other one is the "public key")
2) After that, his public RSA/DSA key will be published (copied) to the home directory of the remote server account that will be used for RSA/DSA authentication (The system admin will repeats this step for each server he wants to manage/access)
3) Only the owner of a private key (the sysadmin) can have access to systems containing his public rsa/dsa key
4) If the sysadmin connects to a server specifying on his pc client the rsa keys path, he will have "direct" access to the called system without inserting any password. Indeed his openssh client will search the private key of the sysadmin and uses it for accessing the remote server in the same manner of the classical login... But in the case... the machines handshake (client with server) will be done automatically by using keys.

Why this method is better than username/password login?

The answer is simple...

1) No brute force attacks with dictionary can be done (no passwords...)

2) The RSA/DSA keys are complex by themselves, no needs to create/remember/store complex password

3) The Private and Public key can be carried on a pendrive (protect them by encryptation and passphrase!!!)

4) It is possible to automatize exchange of data between servers via SSH (by using two couples of RSA/DSA Keys) without "human" intervention

The negative aspect...

One and only one... If you loose your private key you are fired!!! (Back up them on CDROM)

In this case... The only way to access to the system is by doing a login using the physical keyboard of the real system... Than you can change the rsa public key...

Let's Start!

In real world... Follow these steps:

1) Go into your client GNU/Linux console and login with the user you usually use. On the command prompt write:

ssh-keygen -t dsa

Note: If a passphrase is required, if you press enter you don't need to insert an "unlock" password before have access to your keys. If you choose to use passphrase you must write that every time you need to connect with RSA authentication method to a remote system. (Replace "dsa" word with "rsa" if you want to use RSA algorithm.)

Anyway, if you have installed your GNU/Linux system on a PenDrive, for security reason it is important to insert the passphrase.

2) A pair of dsa_keys will be generated. One public and one private. It will be called id_dsa.pub and id_dsa rispectively and you will find them into the .ssh hidden directory (inside your home directory...)

3) Now it's time to copy your public key to the home directory of the user you have access on the remote server. Use the scp command to do that.

scp /home/youruser/.ssh/id_dsa.pub yourremoteuser@server:/home/yourremoteuser

For example:

scp /home/angel/.ssh/id_dsa.pub admin@testserver.net:/home/admin

4) Now you must connect to your remote server (with your account on that machine) and add the RSA/DSA key to authorized_keys2 file (a sort of rsa/dsa keys wallet)

For example:

ssh admin@testserver.net
(insert the password)

when you're logged in write:

cat /home/admin/id_dsa.pub >>/home/admin/.ssh/authorized_keys2

and then

chmod 700 .ssh
chmod 600 .ssh/authorized_keys2

(Replace "admin" with your user on remote server...)

5) Logout from the server

6) If you have followed correctly the instructions above you can connect to your server without insert any password (only a passphrase if you've inserted one during key creation).

On the command line of the client write:

ssh -i /home/yourusername/.ssh/id_dsa username@yourserver.com

Note: add the option "-p port" if the remove server ssh daemon answer to a port different from 22

For example (for the user "admin") you could use:

ssh -p1138 -i /home/angel/.ssh/id_dsa admin@testserver.net

It'll connect the user "angel" to the remote system "testserver.net" with user "admin" by using dsa authentication. The server also uses the port 1138 for the SSH service, so we have got specified the "-p" option.

Another step for improving hardening...

If your remote system is configured for using both authentication method (user/password and rsa keys...), you can force the openssh daemon to accept only rsa authentication.

To do that, change the PasswordAuthentication parameter to no into the /etc/sshd_config file!

One more suggestion!

If you are interested in IT Security, join us at "GNU/Linux Security & Hardening" group on Linkedin

That's all! See you! (If you like my posts, I'll be pleased if you became a follower of my blog and my Twitter!)

Have a nice day!
Angelo Fonzeca

Digital Patch Posts by Angelo F. are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Based on a work at digitalpatch.blogspot.com.

OpenSSH daemon hardening ( Part 1 ) - Modify the configuration file

2010-02-22T07:01:00.000-08:00

Introduction

OpenSSH is a daemon (a "service" in Unix environments) which helps system administrators to manage server remotely.

The SSH daemon is "similar" to "telnet" in the sense that it provides a remote shell for accessing Unix or GNU/Linux systems.

The main difference is that the latter doesn't use encryptation during the session, so it's easily to intercept the content of the communication between two machines (typically a client/server communication) by using a "man-in-the-middle" attack.

On the contrary, OpenSSH allows encrypted communication between two "points" so it's more difficult to intercept information for third subjects.

The service also supports "tunneling" so it's easily to interact with other services on machine in addition to SSH, by using a secure tunnel and port-forwarding created by the ssh connection itself.

For example, if you have your lan behind a Linux Based Firewall which offers only a SSH access from the internet to itself, by connecting a client via SSH you will have access to the Firewall BUT you could have also access to an intranet db behind the firewall (e.g. Mysql). That's why OpenSSH can also forward communication to a destination port on another machine.

This feature helps system administrators to provide services without having to open (expose to attack) all the daemons(on the same or other machines) directly to the Internet. (It's ok, VPN could be implemented for intranets... but this is another story).

Another feature of OpenSSH is that it allows secure FTP. It is a sort of FTP but the communications are encrypted.

There is another type of attack called "brute force attack"... It consists of sending - by using a particular software - passwords taken from a dictionary associated with common usernames (eg. root, admin, test, ecc.) of your server.

If the users of the server have not set good password, the attacker could "guess" it so he/she had access to the system.

In the next paragraph, I'll show you how to harden OpenSSH (make more robust) by modifying its basic configuration and, if it's possible, by activating access via RSA keys method so you can by-pass many of the problems described above.

These improvements are very important, especially if you need to expose your OpenSSH service to the Internet for reaching your server from anywhere and you can't limit the access from specific static IP Addresses (e.g. you connect yourself to the server by using a smartphone and you have a dynamic IP...).

Anyway, always follow these rules:

1) The most important action you can do to deny attacks to SSH... is upgrading your service as soon as possible when bug fixes are available

2) Set the system to require complex passwords when a user set it

3) Analyze logs and cast a glance to "strange" access

4) Limit the access to few users only (if you can) and limit the access to the server from well-know IP addresses (if you access with static IP address) by using your firewall, iptables on GNU/Linux or by limiting them using the OpenSSH configuration files.

Why an attack could be possible?

You know... All software are subject to "bugs" (errors in the code). Bugs are used by the attackers ( people who wants to have access to your private data ) for introducing themselves illegally into a system.

For example, if you have a bug into your OpenSSH daemon it could cause a "vulnerability" which could allow attackers to penetrate your system and steal your data. Indeed, they use "exploit" software that utilize a vulnerability to "broke" the daemon and have privilege escalation.

If you need more information about this aspect, take a look to:

http://en.wikipedia.org/wiki/Exploit_(computer_security)

Anyway... To avoid some of these problems, there are some parameters of the configuration file that allows the system administrator ( that's you! ) making more "robust" the daemon setup.
In the next paragraph, you will see some "tricks" regarding OpenSSH.

Step 1 - Modify the SSH daemon configuration file

OpenSSH can be configured by modifying the configuration file located into /etc/ssh/sshd_config.

These are a very basic set of parameters which can improve the security of the service. Anyway, for further information, study the man pages of sshd_config

Open /etc/sshd_config by using your favorite editor (nano, vi, emacs, krita, etc.) and modify the parameters as follow:

"Protocol"

Description: Set the protocol to accept connection only with the protocol 2 version (more robust)

Set to: Protocol 2

"PermitRootLogin"

Description: This parameter disables authentication from root. You must define a "common" user (use "strange" names like adminXZT) allowed to access the system and then acquire root privileges by using "su" command or by putting your user into "/etc/sudoers" list.

Set to: PermitRootLogin no

"PasswordAuthentication"

Description: This option allows connecting to the service by using username/password. The alternative is to use the "RSA authentication" only, by disabling this option (it will described in another post).

Set to: PasswordAuthentication yes

"X11Forwarding"

Description: Disables port forwarding for the xserver

Set to: X11Forwarding no

"AllowUser" and "AllowGroups"

Description: As previously described, another import parameter is AllowUsers followed by the list of the users that can access the system via ssh. This limits "brute force attacks" because if the system allows all users and if one of the user has a simple password that could be "guessed", the system may be unsecured.

If you decide which users can access to the system, you can easily have much more control on their access.

Set to(for example): AllowUser AdminTWZ MrSecureAbC etc.

If you need to give access to many users you could use "AllowGroups" option. (see notes)

Set to(for example): AllowGroups Admins Users

(use spaces for items separation)

Note

As described in sshd_config man page, these are other options you can use:

"AllowUsers - This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login is allowed only for user names that match one of the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts. The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups." (See man sshd_config for further details...)

PermitEmptyPasswords

Description: Self explained option

Set to: PermitEmptyPasswords no

Port

Description: OpenSSH server "answers" on port 22; many brute force dictionary-based-attacks are done by sending a pair of username/password on that port.

For example, If you see a typical webserver log, you could find many failed login with strange and/or common names. To reduce this type of attacks change the default port to an higher value (for example 13243).

Set to(for example): Port 13243

Note

Your firewall MUST be re-configured to give access (forwarding) to the new port specified

UsePrivilegeSeparation

Description (from man of "sshd_config"): "Specifies whether sshd(8) separates privileges by creating an unprivileged child process to deal with incoming network traffic. After successful authentication, another process will be created that has the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes. The default is “yes”."

Set to: UsePrivilegeSeparation Yes

If you need more information and options for OpenSSH, use man sshd_config from your Gnu/Linux command line.

One more suggestion!

If you are interested in IT Security, join us at "GNU/Linux Security & Hardening" group on Linkedin

Digital Patch Posts by Angelo F. are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Based on a work at digitalpatch.blogspot.com.

2009-06-29T10:59:00.000-07:00

The Story...

In the last few days, I choose to upgrade my Asus EEEPC 900 to EEEBUNTU NBR 3.0 (based on Ubuntu 9.04 Desktop Jaunty).

After the installation, it was unbelievable how it worked badly...

The mouse pointer was tilting (as the mouse ball was unclean since 1990... Amiga like style!)...

Anyway all the system was very very very SLOOOOWWWWWWwwwww.

Oh My God!!!!!

Well, the solution was behind the corner... as far as 2-3 hours of googling!!! (Sigh!) Here it is!!!

The problem was the EEEPC 900 i915 video card related to the driver included into Jaunty!

If you like, you can find more info here: https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance

Here we go... The solution!!!

It was Very Very simple! I need to revert to 2.4 Intel driver according to https://wiki.ubuntu.com/ReinhardTartler/X/RevertingIntelDriverTo2.4 !

How to... Step by step!

Press Alt+F2 and write xterm then the following:

1) sudo su (...and insert your password)

2) vi /etc/apt/sources.list

3) (copy&paste the following into the file, than press ESC key and write :wq)

deb http://ppa.launchpad.net/siretart/ppa/ubuntu jaunty main

deb-src http://ppa.launchpad.net/siretart/ppa/ubuntu jaunty main

4) sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xce90d8983e731f79
5) sudo apt-get update && sudo apt-get install xserver-xorg-video-intel-2.4

Reboot the system! (you can write reboot into the console)

Last reccomendation!

Before rebooting upgrade to 2.6.29-1 Kernel by typing:

apt-get install linux-headers-2.6.29-1-netbook linux-image-2.6.29-1-netbook

Anyway If you need some help, write me! :)

Links

http://www.eeebuntu.org/index.php?page=nbr
https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
https://wiki.ubuntu.com/ReinhardTartler/X/RevertingIntelDriverTo2.4