Arquivos da categoria: Apache

A small Web Hosting with OpenPanel + Ubuntu Server 10.04 LTS + some tricks

Hi,

I’m trying Openpanel, a great new opensource tool that helps developers make a complex server tasks with some mouse clicks.

http://www.openpanel.com/

You can create domains, mail accounts, DNS and other stuff in a “Panel” way. You can create user accounts and allow them to create their own domains, emails and vhosts.

I’m trying it on linode

www.linode.com

With Ubuntu Server 10.04 LTS (You can deploy this image from linode dashboard. You have a virtual machine running after 5 min max)

After a successful OpenPanel install, I need to make my users vhosts run as Apache process of their own user. This way, their php and other apps could write under their directories and make some personal stuff, as also it gets better to my administration tasks.

Unfortunately, this feature is not yet implemented (but it’s on the roadmap), so I need to create the followin “hack”:

  • Install a new MPM apache module:
    sudo apt-get install apache2-mpm-itk
  • Write a script that’s create the directives which makes every vhost runs under it’s owner account and put ir under crontab to run every 10 minutes
    sudo pico /opt/apacheexec.sh
    Put the following content on it:
#!/bin/bash
for sites in /home/*/sites/*
do
    user=`echo "${sites}"|cut -d'/' -f 3`
    site=`echo "${sites}"|cut -d'/' -f 5`
    arquivo=`echo "/etc/apache2/openpanel.d/${site}.inc/mpmitkUser"`
    if [ -f $arquivo ]; then
        true
    else
        echo "<IfModule mpm_itk_module>" > $arquivo
        echo "AssignUserId ${user} ${user}" >> $arquivo
        echo "</IfModule>" >> $arquivo
        exec `/usr/sbin/apache2ctl graceful`
    fi
done
  • Then, make it executable
    chmod a+x /opt/apacheexec.sh
  • Finally, put it to run on crontab
    sudo crontab -e -u root
  • Write it:
    */10 * * * * /opt/apacheexec.sh

And we are done!

Removendo Virus (malware) do WordPress e protegendo seu blogRemoving virus (badware) from WordPress e protecting your blog

Note: não me responsabilizo por danos causados em sua instalação. Utilize essas dicas por sua própria conta e risco 🙂

Estes dias tive dois sites wordpress infectados por malwares! Penei um pouco pra limpar o site e resolvi compartilhar aqui as dicas que fui juntando pelo caminho.

Basicamente, os virus se criam um “backdoor”  se aproveitando de alguma falha de segurança ou bug em sua instalação. Com esse backdoor criado, o virus tem acesso direto ao seu site mesmo após a correção do bug ou atualização do sistema. É como se o virus tivesse criado uma conta de ssh em seu servidor e pudesse executar praticamente qualquer comando lá dentro.

Em um dos casos, o bug que permitiu a instalação do virus estava em um tema que utilizava uma biblioteca chamada timthumb.php. Descobri neste link a falha que esse arquivo continha e segui os passos descritos lá para resolver o problema. Este virus se instalava através do timthumb.php e criava um backdoor. Através do backdoor, outros virus se instalaram no site. Corrigi o arquivo timthumb.php para remover a possibilidade de uma nova invasão.

Estes virus por sua vez, inseriam um iframe na home page do site, fazendo com que o visitante fosse redirecionado para um site com código malicioso. No meu caso, era um iframe para um site chamado wordpress-counter.com

Tive então que remover backdoor antes de remover o gerador de iframe, pois sempre que removia o iframe em si, o mesmo se instaurava novamente após 15 minutos através do backdoor.

Segui as dicas deste post e descobri o backdoor no arquivo wp-config.php. Após o fim do código tradicional do WordPress haviam cerca de 100 linhas em branco e, em seguida, o código nocivo que permitia a executação de scripts php enviados por REQUESTs.

Depois, segui as dicas deste outro post, para eliminar os geradores de iframe.

Finalmente, fiz um congelamento dos arquivos da minha instalação do WordPress. Para isso, acessei a raiz do site através do SSH e realizei os passos abaixo (note que isto impedirá você de atualizar automaticamente o WordPress para versões mais recentes pelo Dashboard):

Para proteger pastas:

find . -type d -exec chmod 755 {} \;

Para proteger arquivos:

find . -type f -exec chmod 644 {} \;

Para impedir que outros usuários enxerguem os dados de seu banco de dados, o que é possível em algumas hospedagens compartilhadas:

chmod 750 wp-config.php

Para impedir que novos ataques modifiquem qualquer arquivo no seu sistema (menos arquivos de plugins e temas):

chmod u-w * -R
chmod u+w wp-content -R

Referencias

http://blog.sucuri.net/2011/08/timthumb-php-security-vulnerability-just-the-tip-of-the-iceberg.html
http://markmaunder.com/2011/08/01/zero-day-vulnerability-in-many-wordpress-themes/
http://cantonbecker.com/work/musings/2009/how-to-search-for-backdoors-in-a-hacked-wordpress-site/
http://blog.unmaskparasites.com/2011/03/02/versatile-cc-attacks/
http://codex.wordpress.org/Hardening_WordPress Note: I’m not responsible for damage to your installation. Use these tips at your own risk:)

These days I have two wordpress sites infected with malware! I suffered a bit to clean the site and decided to share the tips here that I was joining the road.

Basically, viruses create a “backdoor” taking advantage of some security flaw or bug in your installation. With this backdoor created, the virus has direct access to your site even after the bug fix or upgrade the system. It is like as if the virus had established an ssh account on your server and could perform almost any command in there.

In one case, the bug that allowed the installation of the virus was a theme that uses a library called timthumb.php. I Found the failure in this link and follow the steps there to solve the problem. This virus is installed through the timthumb.php and creates a backdoor. Through the backdoor, other viruses have settled on the site. I’ve fixed the file timthumb.php to remove the possibility of a new invasion.

This virus inserted an iframe on the home page of the site, causing the visitor to be redirected to a site with malicious code. In my case it was an iframe to a site called wordpress-counter.com

Then I had to remove the backdoor before removing the iframe code generator, because when removing the iframe itself, it was introduced again after 15 minutes through the backdoor.

Follow the tips this post and discovered the backdoor in the file wp-config.php. After the end of the traditional code of WordPress, it has about 100 blank lines and then the malicious code.

Then follow the tips this other post to eliminate the iframe generators.

Finally, I froze the files of my WordPress instalation. I accessed the site root via SSH and perform the steps below (note that this will block you from WordPress to automatically update the latest versions of the Dashboard):

To protect folders:

 find. -type d -exec chmod 755 {} \; 

To protect files:

 find. -type f -exec chmod 644 {} \; 

To prevent other users to view data from your database, which is possible in some shared hosting:

 chmod 750 wp-config.php 

To prevent further attacks modify any file on your system (files less plugins and themes):

 chmod u-w -R *
chmod u+w -R wp-content

References

http://blog.sucuri.net/2011/08/timthumb-php-security-vulnerability-just-the-tip-of-the-iceberg.html
http://markmaunder.com/2011/08/01/zero-day-vulnerability-in-many-wordpress-themes/
http://cantonbecker.com/work/musings/2009/how-to-search-for-backdoors-in-a-hacked-wordpress-site/
http://blog.unmaskparasites.com/2011/03/02/versatile-cc-attacks/
http://codex.wordpress.org/Hardening_WordPress

Passando informações numa URL utilizando RewriteRules ao invés de QueryStringsSending information through GET Method (URL) using RewriteRules instead of QueryStrings

Um pequeno tutorial para quem faz sistemas que precisam de pretty Urls

Exemplo tosco:

Você tem um formulário de pesquisa que permite ao usuário escolher uma categoria de um livro, o nome do autor e/ou a editora de uma obra.

A URL gerada para uma pesquisa deste form seria algo como:

http://localhost/pesquisa.php?categoria=12&autor=22&editora=12
ou se escolhermos apenas o campo editora:
http://localhost/pesquisa.php?editora=12

Se quisermos transformar o resultado desta pesquisa, num link interpretável pelos mecanismos de busca precisamos utilizar o recurso RewriteRules do Apache.

A URL ficaria assim:
http://localhost/pesquisa/categoria/12/autor/22/editora/12

O arquivo .htaccess precisaria das seguintes diretrizes:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*$ index.php
RewriteRule ^pesquisa pesquisa.php
RewriteRule ^(.+)categoria/([0-9]+)/? pesquisa.php/?categoria=$2 [QSA]
RewriteRule ^(.+)autor/([0-9]+)/? pesquisa.php/?autor=$2 [QSA]
RewriteRule ^(.+)editora/([0-9]+)/? pesquisa.php/?editora=$2 [QSA]
</IfModule>

A flag [QSA] (Query String Append) faz com que o Apache concatene todas as Query Strings tratadas nas regras definidas do arquivo. Desta forma, não importa a ordem que você utiliza para construir a URL. As duas formas abaixo irão funcionar:

http://localhost/pesquisa/categoria/12/autor/22/editora/12
http://localhost/pesquisa/editora/12/autor/22/categoria/12

Um pouco sobre as expressões regulares

Nunca me dei bem com essas benditas RegExp, mas vou tentar explicar as principais que utilizei neste exemplo:

^(.+)categoria/([0-9]+)/?

o ^ indica o início da string, neste caso, a URL do navegador, pra ser mais especifico, tudo o que está entre a primeira barra após o nome do host e a primeira interrogação (inicio da querystring), ou seja, no nosso exemplo de pretty URL, seria:
/pesquisa/categoria/12/autor/22/editora/12

O “.+” indica que 1 ou vários caracteres podem ser encontrados entre o início da string (determinado pelo sinal ^) e a palavra “categoria/”. Estes dois caracteres estão entre parenteses “(.+)” pois desta forma o apache entende que o que for encontrado que corresponda à este expressão regular deve ser armazenado numa variável. Neste caso, por ser o primeiro parenteses, a variável será $1

A expressão [0-9] indica que procuramos caracteres numéricos (de 0 a 9). O sinal “+” após “[0-9]” indica que procuramos um ou mais caracteres desta espécie e os parenteses que envolvem a expressão toda “([0-9]+)” indica que queremos armazenar o resultado encontrado por essa expressão numa variável. Como é o segundo conjunto de parenteses, esta variável será a $2.

Finalmente, a expressão “/?” no fim da string, nos diz que pode haver ou não uma “/” no fim da expressão “categoria/([0-9]+)”. O sinal de interrogação representa 0 ou uma ocorrência da expressão que ele acompanha.

Ufa!Small Pretty URLs tutorial.

Imagine the your app have a search form that allows the user choose a  book category, the author and/or the publisher.

The generated URL in get method for an query example would be something like:

http://localhost/search.php?category=12&author=22&publisher=12
or if we choose only the publisher field:
http://localhost/search.php?publisher=12

We can use Apache Rewrite Rules to transform it into a search engine robot readable link. The URL would be something like this:
http://localhost/search/category/12/author/22/publisher/12

.htaccess file needs these directives:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*$ index.php
RewriteRule ^search search.php
RewriteRule ^(.+)category/([0-9]+)/? search.php/?category=$2 [QSA]
RewriteRule ^(.+)author/([0-9]+)/? search.php/?author=$2 [QSA]
RewriteRule ^(.+)publisher/([0-9]+)/? search.php/?publisher=$2 [QSA]
</IfModule>

[QSA] (Query String Append) is a flag that makes Apache concatenate the Query Strings generated by all rules defined on .htaccess. This make all following queries work, independent of the variables order:

http://localhost/search/category/12/author/22/publisher/12
http://localhost/search/publisher/12/author/22/category/12

Regular Expressions

I’m not expert on Regular Expressions, but I’ll try to explain those I used in the given examples

^(.+)category/([0-9]+)/?

^ indicates the string start, the browser URL in this case or everything after the first slash from host name on and everything before the query string (the interrogation sign). On our example, this is the string:
/pesquisa/categoria/12/autor/22/editora/12

“.+” indicates that one or mor chars can be found from the string’s start and the word “category/”. Both chars are inside a parentheses because we want to indicate that the found result should be assigned to a var, in this case, the var will be $1.

The expression is [0-9] indicates that we search for numbers only. The “+” sign after [0-9] indicates that we look for one ore more numbers, and the parentheses indicates that we want to assign the found result into a next var ($2).

Finally, the expression “/?” in the end of the string, indicates that a slash can be found or not in the end of the string.