Updates from outubro, 2011 Toggle Comment Threads | Keyboard Shortcuts

  • richieri 11:28 on 26/10/2011 Permalink | Reply
    Tags: 10.04 lts, apache2-mpm-itk, hosting, openpanel, ubuntu server, virtual hosts   

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

    Desculpe-nos, mas este texto esta apenas disponível em English.

     
    • Reinaldo Silva 10:00 on 09/11/2011 Permalink | Reply

      Ronaldo, bom dia.

      Temos um OTRS instalado que usamos para chamados e ITSM changes, estamos precisando de alguas personalizacoes no sistema, voce faz consultoria ? Estamos em Alphaville-SP

      Att

      Reinaldo

      • richieri 9:37 on 02/12/2011 Permalink | Reply

        Reinaldo! Desculpe pela demora em te responder!

        O meu de notificação do teu comentário no meu blog ficou no spam. Só vi hoje!

        Se precisar ainda, faço modificações sim! Hoje inclusive estou em um cliente em Porto Alegre fazendo isso.

        Mas moro aí do ladinho de Alphaville, em Sorocaba.

        Se ainda precisarem de ajuda, podem entrar em contato comigo, ainda hoje. Meus telefones estão abaixo.

        Abraço!

  • richieri 21:25 on 01/09/2011 Permalink | Reply
    Tags: antivirus, badware, cleaning, malware, virus, , wordpress-counter   

    Removendo Virus (malware) do WordPress e protegendo seu 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

     
  • richieri 2:53 on 09/08/2011 Permalink | Reply
    Tags: apache, get, php, querystring, rewirterule, rewrite rules   

    Passando informações numa URL utilizando RewriteRules ao invés de 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!

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Powered by Google Talk Widget