fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;

you config should look like this :

http {
.
.
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
.
.
}

restart nginx and fastcgi.

find -type d -empty -delete

As you can see in almost two years Apple has hardly kept its market share and has only grown from %25 to %27. it has happened during the golden age of iPhone 4 ! while Google market share has grown from 5% to 42% ! now you can guess what would happen with current weak embarrassing iPhone 4S ! and this superiority and excellency of Android phones now. I even expect a minus Point Change for Apple market share in next reports.
And I expect some iSheeps send apology letters to me if Google Point Change beats Apple. We will see that happen

a.b.c.d is the host IP
e.f.g.h is the gateway IP
a.b.c.d & e.f.g.h are on different subnets.

by default if you try to set gateway by following command :

route add default gw e.f.g.h

you will get this error :

SIOCADDRT: No such process

the trick is simple , first add a route to default gateway itself and then set the default gateway , like this :

route add e.f.g.h/32 dev eth0
route add default gw e.f.g.h

remember you may need to change eth0 to your device name , it may be eth1 or wlan0 or anything.

How to make these route changes persistent ?

For Debian/Ubuntu :
Add the following lines to /etc/network/interfaces :

post-up route add e.f.g.h/32 dev eth0
post-up route add default gw e.f.g.h

Watch here :
Steve Jobs' 2005 Stanford Commencement Address

The text of speech :
‘You’ve got to find what you love,’ Jobs says

What is MITM attack and how to prevent it ?
MITM stands for Man-In-The-Middle. it simply means someone stands between you and destination and intercepts or modifies your communication. it is quite easy when communication is not encrypted.
SSL protocol is originally invented to address this issue. The idea is that a trusted Authority (CA) authenticates the identity of destination and by using some cryptography protocols your connection to authentic destination becomes encrypted and impossible to intercept or modify.
It has been shown that the cryptography methods like AES or RC4 which are employed to encrypt the data are quite effective and very hard to crack. so the easier solution is to attack the base of trust model, the trusted authorities (CA). In this kind of attacks, hackers break into CA systems and forge valid certificates for themselves so they can impersonate themselves as authentic destinations and intercept the data. this kind of attack is used in both recent incidents, Commodo and DigiNotar.
Although the protocol is almost safe itself, unfortunately many of these CAs are vulnerable themselves making the whole process vulnerable.
The FOX-IT report indicates the DigiNotar systems were using Windows (Which is vulnerable in nature) and passwords has been crackable through brute-force attack. (More on this later)

To understand it better, I have created a diagram of recent MITM attack to Iranian users with the goal of intercepting communications between them and Google. the attackers have been able to gain access to Google accounts of users through this attack :

This diagram is self-explanatory. The attacker in middle impersonates itself as Google and establishes a secure connection to the user which is signed by DigiNotar CA. Although the connection is still secure, but users have a secure connection to the attacker, not real Google. so attacker has access to all information sent by user, including username, passwords, cookies and etc.

Analysis of Report
As I said, I will not go into all details of report as original report is available to download and study. I will only analyse,comment and clarify the crucial points.

The rogue certificate found by Google was issued by the DigiNotar Public CA 2025. The serial number of
the certificate was, however, not found in the CA system’s records. This leads to the conclusion that it is
unknown how many certificates were issued without any record present. In order to identify these
unknown certificates and to prevent them from being used by victims, the OCSP responder requests
were monitored.

As report suggests many of rogue issued certificates are not recorded in CA database make it impossible to revoke them (Although the revocation process is not effective itself and doesn’t resolve the issue). so the resort was to remove the whole DigiNotar certificates from browsers and chain of trust – Make DigiNotar an untrusted firm – these steps have been taken by Microsoft, Mozilla Firefox and Google Chrome immediately except Apple !
So please note if you use Apple products like Safari browser, Apple iPhone, Apple iPad and etc. you are still vulnerable to this attack. All users are urged to stop using Apple products and update their browsers and systems to latest versions. Using Mozilla Firefox or Google chrome is recommended for better security.

Current browsers perform an OCSP check as soon as the browser connects to an SSL protected website
through the https-protocol. The serial number of the certificate presented by the website a user visits is
send to the issuing CA OCSP-responder. The OCSP-responder can only answer either with good,
revoked or unknown. If a certificate serial number is presented to the OCSP-responder and no record of
this serial is found, the normal OCSP-responder answer would be good. The OCSP-responder answer
revoked is only returned when the serial is revoked by the CA. In order to prevent misuse of the
unknown issued serials the OCSP-responder of DigiNotar has been set to answer revoked when
presented any unknown certificate serial it has authority over. This was done on September 1st.

OCSP stands for Online Certificate Status Protocol, it enables CAs to revoke the certificate they have issued before. but OCSP could not be helpful in this case for following reasons :
1.Many browsers still do not support or activate OCSP by default like Apple Safari.
2.OCSP is not enforced for certificate verification. so even if certificate was revoked by CA (which was not) the attacker could simply block the OCSP requests.
3.The certificates were not revoked by OCSP efficiently (Using white-listing policy) until 1 Sept. it means the attackers have had rogue valid certificates in their hands for about 2 months.

A script was found on CA server public 2025. The script was written in a special scripting language only
used to develop PKI software. The purpose of the script was to generate signatures by the CA for
certificates which have been requested before. The script also contains English language which you can
find in Annex 5.3. In the text the hacker left his fingerprint: “Janam Fadaye Rahbar”. The same text was
found in the Comodo hack in March of this year. This breach also resulted in the generation of rogue
certificates.

This is the fingerprint of the hacker “Janam Fadaye Rahbar”, means something like “I will die for my leader” which points to Iranian Supreme Leader Ayattolah Khamenei. This part has nothing technical to discuss, but from ethical point of view, what kind of leader could be that his followers are involved in mass cyber crime activities ? if it was an attack against Pentagon or CIA, may be it was adjustable, but mass interception of users communications without official court order is mass cyber crime comparable to mass destruction weapons. it leaves no space for bragging. anyone involved in this crime should be ashamed and prosecuted by international laws. it shows the true face of hackers. it is cyber terrorism.

We investigated the OCSP responder log files around the time of the *.google.com incident. That incident
was detected on August 27th. The first known public mention was a posting in a google forum. The user
(from Iran) was warned by the Google Chrome browser that there was something wrong with the
certificate. The corresponding rogue certificate was created on July 10th.

It is still unclear to me how Google chrome has detected this certificate is rogue. through OCSP ? if that’s true many users using the same version of chrome should have gotten the same warning message. as report states DigoNotar has employed white-listing OCSP policy on 1 Sept. so the user has got the warning message before that. it is possible that attacker have been intercepting using a revoked certificate.
anyway if user had not notified the community about this incident only god know for how long more those cyber terrorists could continue on their criminal acts and intercept the communications of Iranian users.
This shows the security protocols on web need to be revised and new methods should be employed to protect users privacy. We are on that cyber terrorists

Based on the logging mentioned above from the OCSP responder, we were able to extract the following
information. On August 4th the number of request rose quickly until the certificate was revoked on August
29th at 19:09. Around 300.000 unique requesting IPs to google.com have been identified. Of these IPs
>99% originated from Iran, as illustrated in figure 1

There some very important points here :
1. Around 300.000 unique IP addresses have been identified to use rogue certificate through OCSP responder. but as I mentioned before about OCSP, many browsers do not perform OCSP check and this number doesn’t count the users behind NAT servers using private IP addresses so the number of affected users is far more than 300.000 users. I believe it could be at least 1 million users. anyone in Iran using Google account. may be Google has a more precise statistics.
2. The expansion and scale of attack show only a government having access to infra-structure of Internet and Gateways could perform this attack in such a scale. there is no doubt that Iran government has been involved in this attack. (more proof on this later)

A sample of the IP?s outside of Iran showed mainly to be TOR-exit nodes, proxies and other (VPN)
servers, and almost no direct subscribers.

As Fox-IT report states , some IP addresses outside of Iran have been found to be using rogue certificates. most of them have been TOR-exit nodes. it is clear that the security of Tor network is compromised in Iran. so if you are in Iran , TOR is not safe for you anymore. I am not an expert in TOR , but I believe Iran government is running TOR routers (relayers) itself and intercepts the communication of TOR network inside Iran. TOR project officials are to step in and explain regarding this incident.
The reports also talks about proxies and VPNs, but it is not specific and detailed. what kind of Proxy and VPN ? PPTP ? L2TP ? SSTP ? not clear.
But I hardly believe they have the required knowledge and equipment to compromise all VPN networks. if FOX-IT can hand over a list of outside Iran IP addresses, it is possible to investigate what kind of VPN and services are being run on those IPs and identify the compromised protocols.
For now I only believe TOR is compromised (using fake certs generated for TOR). until more info is available.

We found that the hackers were active for a longer period of time. They used both known hacker tools as
well as software and scripts developed specifically for this task. Some of the software gives an
amateurish impression, while some scripts, on the other hand, are very advanced. In at least one script,
fingerprints from the hacker are left on purpose, which were also found in the Comodo breach
investigation of March 2011. Parts of the log files, which would reveal more about the creation of the
signatures, have been deleted.

The list of domains and the fact that 99% of the users are in Iran suggest that the objective of the
hackers is to intercept private communications in Iran.

The attack to DigiNotar has had two major parts:
I.Gain access to CA infrastructure : As DigiNotar has been using Windows (Most insecure OS) and a weak password for logging into domain of CA servers. it is the part that amateur tools have been used to accomplish. the attackers may be still active finding fool CAs using Windows + weak password.
II.Generate the CAs : When Administrative access is gained. you can do anything on servers. steal the programs, data and etc. It was mentioned in the report that dropbox was used to transfer files , it’s kinda funny. There has been 1 million way to transfer files, but even hackers choose the more convenient way.
I still see nothing that much impressive or mind blowing. when you have administrative access to file system , it is possible to reverse engineer everything. specially for a government with millions of dollars budget and hundreds of programmers working on the project. specially for softwares which are not built to be secure to reverse engineering.
The claim of being an individual hacker behind this is a big lie, it is very clear to security experts and I have discussed it before and responded to it.

The most critical servers contain malicious software that can normally be detected by anti-virus software.
The separation of critical components was not functioning or was not in place. We have strong indications
that the CA-servers, although physically very securely placed in a tempest proof environment, were
accessible over the network from the management LAN.

The network has been severely breached. All CA servers were members of one Windows domain, which
made it possible to access them all using one obtained user/password combination. The password was
not very strong and could easily be brute-forced.

The software installed on the public web servers was outdated and not patched.

No antivirus protection was present on the investigated servers.

An intrusion prevention system is operational. It is not clear at the moment why it didn?t block some of
the outside web server attacks. No secure central network logging is in place.

It is the tragedy part for security experts, in who are we putting our trust ? How many of other CAs like this still exist ?
The following components have facilitated the attack :
I. Use of Windows as CA Servers.
II. Use of Windows Domains and Joining all servers to a single windows domain.
III. Use of a weak password for windows domain.
IV. Lack of security softwares on systems like Anti-Viruses and Firewalls.
V. Use of outdated softwares.
VI. Lack of proper monitoring and notification system.

This list proves exactly who has been behind this attack. In this list you can find the name of Iran regime opposition sites like Balatarin.com and Azadegi.com beside Google, Facebook, Yahoo and etc.
It completely explains the intentions of these hackers and cyber terrorists.

Finally the hackers message left intentionally on server. I have already answered to his claims here :
http://www.adminsehow.com/2011/03/a-response-to-comodohacker/
So there is no need to repeat them. in both incidents the security of CAs are to be blamed.
Also the structure or procedures of trust on web should be revised by security experts.

What should be done now by users ?
1.Always keep your operating system and browser updated.
2.Use Firefox or Chrome for better security.
3.Do not use TOR network until it is clarified how it is compromised.
4.Do not use Apple products like Safari and iPhone and iPad.
5.Always use secure private networks like VPN or SSH Tunnels for accessing all websites. thats another layer of protection.
6.Read this post by Google Security Team : http://googleonlinesecurity.blogspot.com/2011/09/gmail-account-security-in-iran.html

If you have any questions , you may ask in comments.

The stats are very clear , by July 2011, Android is dominating the US market share by 42% compared to 27% Apple. the stats should have become worse for Apple by now.
If you are an iSheep reading this article , I recommend you to turn on your brain and start using it. The start of The End of iPhone has begun and clock is ticking.
Join the wave NOW ! Confess to your Sins and promise you will NEVER ripped off again by fruit company. You will be sent to Android heaven.

Edit : Seems I have had high hopes for iSheeps , there is no way to save them ! here is a response from an iSheep :

Oh I am deeply impressed
I confess to all my sins ( I was innocent but one day when i was sick, a bad doc at hospital told me an Apple a day keeps the doctor away and involved me to this Fu… fruit lovers wave
I declare that I would not trust that doc. I’m regret and i want to apply for that anti fruit wave which you mentioned on your blog.
I give you my word that I will never ever let that fruit company to ripoff me again.
So i won’t buy any fruit company product anymore, down with apple , down with peach , down with Kivi , down with pineapple and banana. (Except watermelon which i’m in love with it, Sorry!)
Long live Pepsi and that anti fruit wave.

apt-get install libapache2-mod-php5
/etc/init.d/apache2 restart

Setting up linux-image-2.6.32-5-amd64 (2.6.32-35squeeze1) ...
Running depmod.
Running update-initramfs.
update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
Searching for GRUB installation directory ... found: /boot/grub
warning: grub-probe can't find drive for /dev/xvda1.
grub-probe: error: cannot find a GRUB drive for /dev/xvda1. Check your device.map.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.32-5-amd64.postinst line 799, line 2.
dpkg: error processing linux-image-2.6.32-5-amd64 (--configure):
subprocess installed post-installation script returned error exit status 2

The solution is :

Run…

echo '(hd0) /dev/xvda' > /boot/grub/device.map
mknod /dev/xvda b 202 0

Edit /usr/sbin/update-grub :
Change…

find_device ()
{
if ! test -e ${device_map} ; then
echo quit | grub --batch --no-floppy --device-map=${device_map} > /dev/null
fi
grub-probe --device-map=${device_map} -t device $1 2> /dev/null
}

to…

find_device ()
{
if ! test -e ${device_map} ; then
echo quit | grub --batch --no-floppy --device-map=${device_map} > /dev/null
fi
#grub-probe --device-map=${device_map} -t device $1 2> /dev/null
echo /dev/xvda
}

Run…

update-grub 0
sed -i "s/xvda/xvda1/g" /boot/grub/menu.lst

Everything should be fixed now.

References :
http://www.sysadmintalk.net/forums/Thread-PyGrub-grub-probe-can-t-find-drive-for-dev-xvda1-error-Debian-Squeeze
http://lists.bitfolk.com/lurker/message/20080529.142153.954fedf4.el.html