BlogBlogs.Com.Br

Bacula: Gestão de Backup Distribuida – Conceitos

March 16, 2010 by alexos · 1 Comment 

De acordo com a norma NBR ISO/IEC 17799:2005:

12.1.3 Salvaguarda de registros organizacionais

Convém que registros importantes de uma organização sejam protegidos contra perda, destruição e falsificação. Alguns registros podem precisar ser retidos de forma segura para atender a requisitos estatutários ou regulamentações, assim como para apoiar as atividades essenciais do negócio…

Para atender este controle da norma torna-se imprescindível a implantação de um sistema de backup. Existem vários sistemas pontos para realizar está tarefa dentre vários posso citar algumas estrelas do mundo proprietário:

* ArcServe
* BackupEXEC

Porém posso destacar dentro da vasta lista de ferramentas livres o Bacula. Ele anda lado a lado com os softwares citados anteriormente sem dever nada ( veja Current State). As poucas “limitações” encontradas são:

* Não possuir agentes para banco de dados. Porém antecipo que isso não venha a ser uma grande limitação como mostrarei mais tarde.
* Sua configuração é um pouco complicada para quem não tem muita experiência.

Porém depois de configurado o Bacula mostra que não deve nada a ninguém, ele da conta do recado e sobra em funcionalidades.

Veja um comparativo entre os diversos softwares de backup

Antes de apresentar um completo how-to sobre o Bacula preciso falar sobre alguns conceitos importantes para o bom entendimento não só da ferramenta, mas de todo o conceito por trás da arte de manter cópias de segurança do seus dados.

Estratégias

O básico de tudo é entender as possíveis estratégias de backup, a melhor estratégia é aquela que atende suas necessidades. Alguns itens que ajudarão na escolha são:

* O que irei guardar?
* Qual o tamanho dos dados que serão guardados?
* Qual tipo de mídia utilizar? Fita, CD, DVD, HD?
* Os dados serão mantidos por quanto tempo?
* De acordo com o valor da informação qual o tempo de recuperação ideal?

Após responder estes e outros questionamentos você estará habilitado a definir a melhor estratégia

Backup Completo ( Full )

Faz um backup completo dos dados. Uso recomendado na inexistência de uma política de backup. A grande desvantagem é a quantidade de espaço ocupado, consequentemente os dados não serão mantidos por muito tempo. Dependendo do volume de dados a rotatividade máxima será semanal.

Backup Diferencial

Este tipo de estratégia é bastante interessante para quem ainda não confia em suas estrutura de backup. Aqui é gerado um backup full e vários backups diferenciais. O backup diferencial é o somatório do que foi alterado após o full, isto significa que para recuperar os dados somente são necessários o full e o último backup diferencial. A grande vantagem é a diminuição da quantidade de volumes e o restore não necessita de todos os diferenciais gerados.

Backup Incremental

Nesta estratégia após o backup full serão gerados backups incrementais. Para fazer o restore serão necessários os volumes full e todos os volumes incrementais. Ela se aplica a uma estrutura totalmente confiável de backup pois se qualquer volume estiver danificado o restore não será realizado.

Seus backups poderão seguir as rotações diárias ( full ), semanais e mensais. Para reduzir os custos com mídia o ideal é fazer a reciclagem dos volumes.

Exemplo de rotação semanal:

Dom – Backup Full
Seg a sexta-feira – Backups Diferenciais
Reciclagem – Semanal ou Quinzenal

Como informei anteriormente a melhor estratégia é aquela que une eficiência e menor custo. Na conclusão do segundo post apresentarei a minha experiência com o Bacula na Colivre

Post to Twitter Tweet This Post

Bacula: Gestão de Backup Distribuida – Prática

March 16, 2010 by alexos · Leave a Comment 

Termos

Existe uma vasta terminologia usada no Bacula para maiores informações acesse Terminology

Ele é um sistema totalmente distribuido sendo formado por 3 daemons ( Director, Storage e FileDaemon ). Os 2 primeiros não necessariamente precisam estar em máquinas separadas, enquanto que o FD precisa ser instalado em todas as máquinas clientes.

Bacula Director

Responsável por supervisionar todas as operações de backup, restauração, verificação e as operações dos arquivos.

Bacula Storage

Responsável pelo armazenamento, leitura e escrita em fita ou outros meios de armazenamento, por exemplo arquivos.

Bacula File Daemon

Este é o cliente do Bacula.

Instalação e Configuração Básica

Agora apresentarei de uma forma bem simples a instalação e configuração do Bacula, recomendo uma profunda leitura da documentação. O bom entendimento de sua infra-estrutura e da política adotada facilitará muito na configuração e manutenção da rotina de backup.

No Debian a instalação desta ferramenta é bastante simples. Execute o comando abaixo para instalar todos os daemons:

aptitude install bacula-director bacula-sd bacula-fd

Configurando o Bacula Director

Edite o arquivo /etc/bacula/bacula-dir.conf

Director { # define myself
Name = backup-dir
DIRport = 9101 # where we listen for UA connections
QueryFile = “/etc/bacula/scripts/query.sql”
WorkingDirectory = “/var/lib/bacula”
PidDirectory = “/var/run/bacula”
Password = “Console/iA6pwbPuT2zUt/hbyE2123123132123″ # Console password
Messages = Daemon
DirAddress = 123.123.123.123
}

## Clients

Job {
Name = “Job-server-01″
Client = server-01-fd
Type = Backup
FileSet = “Server 01 Set”
Schedule = “PeriodicidadeSemanal”
Messages = Standard
Pool = Default
Full Backup Pool = “Full_server-01″
Differential Backup Pool = “Diff_server-01″
Write Bootstrap = “/var/lib/bacula/server-01_new.bsr”
}

## Backup Catalog

Job {
Name = “BackupCatalog”
Client = server-2-fd
Type = Backup
FileSet=”Catalog”
Schedule = “PeriodicidadeSemanalCatalog”
Messages = Standard
Storage = Storage-Server2
Pool = “Catalog_Backup”
RunBeforeJob = “/etc/bacula/scripts/make_catalog_backup bacula”
RunAfterJob = “/etc/bacula/scripts/delete_catalog_backup”
Write Bootstrap = “/var/lib/bacula/BackupCatalog_new.bsr”
}

## Restore Job

Job {
Name = “Server-01_Restore”
Type = Restore
Client = server-01-fd
FileSet = “Server 01 Set”
Pool = Default
Messages = Standard
Where = “/var/bacula/restore/b_server-01″
Bootstrap = “/var/lib/bacula/server-01_new.bsr”
}

# Backup Files

FileSet {
Name = “Server 01 Set”
Include {
Options {
signature = MD5
compression = GZIP
}
File = /etc
File = /var/bkpdb
}
Exclude {
File = /tmp
}
}

#Schedules

Schedule {
Name = “PeriodicidadeSemanal”
Run = Level=Full on sun at 23:00
Run = Level=Differential on mon-sat at 23:00
}

Schedule {
Name = “PeriodicidadeSemanalCatalog”
Run = Level=Full on sun at 07:00
Run = Level=Differential on mon-sat at 07:00
}

# Clients FD

Client {
Name = Server-1-fd
Address = 123.123.123.123
FDPort = 9102
Catalog = MyCatalog
Password = “Nlw2vp555z4vepasdasdasddasdda”
File Retention = 30 days
Job Retention = 30 days
Autoprune = yes
}

#Storage

Storage {
Name = Storage-Server2
Address = 123.13.12.3123 # N.B. Use a fully qualified name here
SDPort = 9103
Password = “Nlw2vp555z4veqweqweqweqwY”
Device = FileStorage
Media Type = File
}

#Pool Server 01

Pool {
Name = Full_Server-01
Pool Type = Backup
Storage = FullStorage
Maximum Volume Jobs = 1
Maximum Volume Bytes = 6g
Recycle = yes
AutoPrune = yes
Volume Retention = 2 weeks
Maximum Volumes = 5
LabelFormat = “F_server-01_${Year}-${Month}-${Day}_${Hour}.${Minute}.${Second}”
}

Pool {
Name = Diff_server-01
Pool Type = Backup
Storage = DiffStorage
Maximum Volume Jobs = 1
Maximum Volume Bytes = 6g
Recycle = yes
AutoPrune = yes
Volume Retention = 2 weeks
Maximum Volumes = 7
LabelFormat = “D_server-01_${Month}-${Day}”
}

Post to Twitter Tweet This Post

Bacula: Gestão de Backup Distribuida – Prática ( cont. )

March 16, 2010 by alexos · Leave a Comment 

Agora iremos configurar o Bacula Storage e o File Daemon

Edite o arquivo /etc/bacula/bacula-sd.conf

Storage { # definition of myself
Name = backup-sd
SDPort = 9103 # Director’s port
WorkingDirectory = “/var/lib/bacula”
Pid Directory = “/var/run/bacula”
SDAddress = 123.122.123.123
}

# List Directors who are permitted to contact Storage daemon

Director {
Name = backup-dir
Password = “Nlw2vp555z4vep0dasdads”
}

# Restricted Director, used by tray-monitor to get the
# status of the storage daemon

Director {
Name = backup-mon
Password = “Mon/GxVW6dfndasdasdsadasd”
Monitor = yes
}

# Devices supported by this Storage daemon
# To connect, the Director’s bacula-dir.conf must have the
# same Name and MediaType.

Device {
Name = FileStorage
Device Type = File
Media Type = File
Archive Device = /backup2/storage
}

Edite o arquivo /etc/bacula/bacula-fd

# List Directors who are permitted to contact this File daemon

Director {
Name = “backup-dir”
Password = “Nlw2vp555z4vep0viaBpeAsdads”
}

# Restricted Director, used by tray-monitor to get the
# status of the file daemon

Director {
Name = “backup-mon”
Password = “Mon/GxVW6dfnO+EVBPpkdasdsaP”
Monitor = yes
}

# “Global” File daemon configuration specifications

FileDaemon { # this is me
Name = Server-2-fd
FDport = 9102 # where we listen for the director
WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run/bacula
Maximum Concurrent Jobs = 20
FDAddress = 123.123.123.123
Heartbeat Interval = 15 seconds
}

# Send all messages except skipped files back to Director
Messages {
Name = Standard
director = backup-dir = all, !skipped, !restored

Com todos os arquivos devidamente configurados inicie os serviços

invoke-rc.d bacula-director restart

invoke-rc.d bacula-sd restart

invoke-rc.d bacula-fd restart

E conecte-se ao Bacula Console

bconsole

Connecting to Director 123.123.123.123:9101
1000 OK: backup-dir Version: 2.4.4 (28 December 2008)
Enter a period to cancel a command.
*

Aparecendo a tela acima tudo está funcionando perfeitamente. Para obter informações sobre os comandos digite help.

Existe uma gama de ferramentas gráficas para gestão do bacula, posso citar o bacula-console-qt. Para ser sincero eu não utilizo ferramentas gráficas. O Bacula Console me atende muito bem nas tarefas diárias.

Backup dos SGBDs

Como informei anteriormente existe uma limitação do Bacula para fazer cópias de segurança de SGBDs porém não recomendo o backup “a quente” das bases. Todos os SGBDs do mercado possuem ferramentas que geram o dump do banco sem afetar a integridade dos dados. Seguem 02 scripts que utilizo para gerar as cópias tanto do Postgresql quanto do MySQL:

MySQL

Este script é de autoria do meu colega Marcelo Dultra, analista de segurança da FTC.

O arquivo de configuração /etc/bkpmysql.cfg contém as infomações necessárias para a realização do backup

Nome do Job:Nome do dump:Diretório destino:Usuário do banco:senha:Arquivo log:email envio alerta

Esse é o script

#!/bin/bash

##########################################################################
# Definicao de Variaveis #################################################
##########################################################################

arqcontrole=’/etc/bkpmysql.cfg’

if [ -z "${arqcontrole}" ]
then
echo “${0} – Erro Fatal: Arquivo de Configuracao nao existe!”
exit 1
fi

titbkp=`cat ${arqcontrole}|cut -d: -f1`
arqbkp=`cat ${arqcontrole}|cut -d: -f2`
adibkp=`cat ${arqcontrole}|cut -d: -f3`
usebkp=`cat ${arqcontrole}|cut -d: -f4`
senbkp=`cat ${arqcontrole}|cut -d: -f5`
logbkp=`cat ${arqcontrole}|cut -d: -f6`
usrbkp=`cat ${arqcontrole}|cut -d: -f7`
dia=`date ‘+%u’`

msg_erro()
{
echo “ATENCAO ADMINISTRADOR! ” > /tmp/bkpmysql.msg
echo “Erro no Backup da Base de Dados Horde – ${serbkp}!” >> /tmp/bkpmysql.msg
echo ${msg} >> /tmp/bkpmysql.msg
mail ${usrbkp} -s “${serbkp} – Erro Backup DB Horde” < /tmp/bkpmysql.msg
}

echo "`date '+%d/%m/%y - %H:%M:%S -'` INICIO DA ROTINA" > ${logbkp}

case ${dia} in
1) sem=”Segunda”;;
2) sem=”Terca”;;
3) sem=”Quarta”;;
4) sem=”Quinta”;;
5) sem=”Sexta”;;
6) sem=”Sabado”;;
7) sem=”Domingo”;;
*) msg=”Dia da Semana nao definido”
msg_erro
echo “`date ‘+%d/%m/%y – %H:%M:%S -’` Erro! Dia da Semana Invalido!” >> ${logbkp}
exit 1
esac

if [ -z "${titbkp}" -o -z "${arqbkp}" -o -z "${adibkp}" -o -z "${usebkp}" -o -z "${senbkp}" -o -z "${logbkp}" -o -z "${usrbkp}" -o -z "${sem}" ]
then
echo “`date ‘+%d/%m/%y – %H:%M:%S -’` Parametros Invalidos!” >> ${logbkp}
msg=”`date ‘+%d/%m/%y – %H:%M:%S -’` Parametros Invalidos!”
msg_erro
exit 1
fi

cd ${adibkp}

echo “`date ‘+%d/%m/%y – %H:%M:%S -’` Gerando dump do banco …” >> ${logbkp}

mysqldump -u ${usebkp} -p${senbkp} –add-locks –add-drop-table –all-databases –flush-logs –disable-keys –result-file=${arqbkp}.${sem} 2>> ${logbkp}

if [ ${?} -eq 0 ]
then
echo “`date ‘+%d/%m/%y – %H:%M:%S -’` Dump Gerado!” >> ${logbkp}
else
echo “`date ‘+%d/%m/%y – %H:%M:%S -’` Erro na realizacao do Backup!” >> ${logbkp}
msg=”`date ‘+%d/%m/%y – %H:%M:%S -’` Erro na realizacao do Backup!”
msg_erro
exit 1
fi

echo “`date ‘+%d/%m/%y – %H:%M:%S -’` Compactando arquivo do dump …” >> ${logbkp}

gzip -f ${arqbkp}.${sem}

if [ ${?} -eq 0 ]
then
echo “`date ‘+%d/%m/%y – %H:%M:%S -’` Arquivo Compactado!” >> ${logbkp}
else
echo “`date ‘+%d/%m/%y – %H:%M:%S -’` Erro na compactacao!” >> ${logbkp}
msg=”`date ‘+%d/%m/%y – %H:%M:%S -’` Erro na compactacao!!”
msg_erro
exit 1
fi

echo “`date ‘+%d/%m/%y – %H:%M:%S -’` FIM DA ROTINA DE BACKUP …” >> ${logbkp}

exit

Postgresql

#!/bin/bash
DATE=`date +”%Y-%m-%d”`
HOSTNAME=`hostname`
DIR=/var/bkpdb
d=rtdb
su postgres -c “pg_dump $d | gzip -c > $DIR/$d.$HOSTNAME.$DATE.out.gz”

Caso de uso – Colivre

A Colivre utiliza o Bacula para fazer o backup de cerca de 8 servidores espalhados pelo globo. A política adotada é de cópias Full todos os domingos e cópias diferencias de segunda a sábado.

Num teste de restore realizado semanalmente, foram restaurados cerca de 8 GB em 2 min. isso porque os servidores estavam na mesma rede. Já o restore de um servidor remoto com o mesmo tamanho de arquivo levou cerca de 10 min.

Os arquivos ( volumes ) são gravados em 03 storages ( partições ) diferentes, com a reciclagem eles ocupam menos de 40% dos discos.

Alcançamos esse nível de gerenciamento de backup com muito estudo, paciência e análise. Levando cerca de 15 dias, periodo de 20/12 a 03/01, para deixar a rotina redonda, só é preciso monitorar diariamente os logs e de vez em quando fazer uma intervenção.

O Bacula tem se mostrado uma ferramenta madura, escalável, segura e confiável tranquilizando minhas poucas noites de sono.

Leituras Obrigatórias

* Bacula Main Reference Guide PDF e HTML
* Console and Operators Guide PDF e HTML
* Problem Resolution Guide PDF e HTML
* Utility Programs PDF e HTML

Post to Twitter Tweet This Post

Chamada de Trabalhos FLISOL 2010 – Salvador/BA

March 15, 2010 by alexos · Leave a Comment 

FLISOL_2010

Nós da comunidade de Software Livre Bahia convidamos a todos para enviarem suas propostas de palestras para o FLISOL 2010, as propostas devem ser encaminhadas até o dia 03 de abril de 2010 para flisol2010@gmail.com com as seguintes informações:


* Título da palestra:

* Nome do palestrante:

* Público Alvo:

* Resumo:

* Mini-Currículo:

Maiores Informações:

Flisol Brasil

Flisol Salvador

Post to Twitter Tweet This Post

Cron-apt – Otimizando a atualização dos servidores Debian

March 4, 2010 by alexos · 2 Comments 

A atualização dos servidores pode tornar-se uma tarefa chata quando você tem repetir está mesma ação diversas vezes. Para automatizar está tarefa uso o script cron-apt. Como o nome já diz ele agenda a execução do apt-get ou aptitude para atualizar os pacotes de seu sistema

Segue aqui um pequeno how-to para implantação desta ferramenta que tem sido uma mão na roda no meu dia a dia.

NOTA: A atualização automatizada dos pacotes não é recomendada para as versões testing e unstable do Debian. Mesmo na versão stable use por sua conta e risco.

Instale o pacote cron-apt

sudo aptitude install cron-apt

Edite o arquivo /etc/cron-apt/config descomentando as seguintes linhas:

APTCOMMAND=/usr/bin/aptitude

MAIL=”/var/log/cron-apt/mail”

Agora descomente e edite as seguintes linhas deste mesmo arquivo

MAILTO=”INFORME SEU EMAIL AQUI”

De
MAILON=”error”

Para
MAILON=”always”

De
SYSLOGON=”upgrade”

Para
SYSLOGON=”always”

De
DEBUG=”output”

Para
DEBUG=”always”

Por padrão ele apenas baixa os pacotes sem instalá-los usando a opção dist-upgrade. Aqui mostro como mudar está ação que não é muito interessante para servidores pois a opção dist-upgrade pode apagar pacotes importantes.

Edite o arquivo /etc/cron-apt/actions.d/3-download alterando a seguinte linha

De
dist-upgrade -d -y -o APT::Get::Show-Upgraded=true

Para
safe-upgrade -y -o APT::Get::Show-Upgraded=true

O cron-apt está agendado para ser executado às 04 da manhã todos os dias. Para mudar este agendamento edite a seguinte linha no arquivo /etc/cron.d/cron-apt

0 4 * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt

Eu por exemplo agendo as minhas atualizações para as 23 horas. Então minha configuração fica da seguinte forma:

0 23 * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt


Como informei anteriormente tenha muito cuidado ao usar ferramentas automatizas na gestão dos seus sistemas. Por isso recomendo fortemente a configuração do envio de emails, assim você poderá acompanhar de forma segura todas as ações realizadas por está ferramenta.

Fonte

Post to Twitter Tweet This Post

Infraestrutura para Aplicações Web Seguras parte 3 – Aplicação (Cont.)

March 3, 2010 by alexos · 2 Comments 

Para completar o post anterior eu não poderia deixar de lado os nossos amigos e companheiros de luta – OS DESENVOLVEDORES. Sim esses abnegados amigos que defendem com unhas e dentes seus sistemas desenvolvidos seguindo padrões de qualidade criados por eles próprios.

Eu não sou expert no assunto muito porque como desenvolvedor eu sou um bom cozinheiro. Por isso indico o site do grande Wagner Elias.

Referências – Desenvolvimento Seguro

* PHP Security
* Hardened-PHP Project
* OWASP – Open Web Application Security Project
* OWASP Development Guide
* OWASP Code Review Project
* Software Assurance Maturity Model
* OWASP Enterprise Security API
* OWASP Ruby on Rails Security Guide V2
* Hackers.org Web Application Security

As referências acima ajudarão os desenvolvedores compreenderem como desenvolver aplicações de forma segura. Sabemos que nunca estaremos 100% seguros, porém o mais importante e o mais gratificante é saber que ao tentar detectar/explorar uma falha numa aplicação ou em um sistema o atacante viu que as portas foram bem fechadas e com o aumento da complexidade a grande maioria desiste.

E para finalizar com chave de ouro indico a leitura de um texto muito engraçado e totalmente verdadeiro feito pelo meu amigo Licio FonsecaDesenvolvedores: O que o seu SysAdmin gostaria que você soubesse

Post to Twitter Tweet This Post

Infraestrutura para Aplicações Web Seguras parte 3 – Aplicação

March 3, 2010 by alexos · 2 Comments 

Finalizando nossa trilogia farei algumas recomendações para fortalecer o Apache2 e algumas referências sobre boas práticas de segurança no desenvolvimento de aplicações.

Apache2 Seguro

1 – Atualização

É chato falar sempre a mesma ladainha mas atualização é o item número 1 de qualquer cheklist de pós instalação. Sobre isso comentei na 1a. parte.

2 – Escolha o módulo do Apache que melhor atenda suas necessidades

Isso mesmo. Existe um módulo do Apache para cada necessidade vejamos:

* Apache MPM Prefork

Ele implementa um non-threaded web server que processa os pedidos de maneira similar ao Apache 1.3, sendo o melhor MPM para isolar cada requisição, assim um problema com uma única requisição não afetará as outras.
Ele é auto ajustável tornando muito rara a necessidade de ajustar as suas diretivas de configuração.

O mais importante é que a diretiva MaxClients possua um valor suficientemente grande para lidar com tantas solicitações simultâneas, mas pequena o suficiente para assegurar que haja bastante RAM física para todos os processos.

Para instalar o Apache MPM Prefork execute

aptitude install apache2-mpm-prefork

* Apache MPM Worker

Ele implementa um multi-threaded server hibrido. Usando threads para tratar as requisições. Ele atende a apliações que neessitam atender muitas requisições usando poucos recursos do sistema, entretando ele retém a estabilidade do servidor porque mantem muitos processos abertos onde cada um desse processos rodam várias threads.

As diretivas mais importantes no uso deste módulo são: ThreadsPerChild e MaxClients

Para instalar o Apache MPM Worker execute

aptitude install apache2-mpm-worker

Apache Hardening

Este assunto já foi tratado anteriomente porém quero atualizar alguns itens:

* Edite os seguintes parâmetros do arquivo /etc/apache2/conf.d/security

* Server Tokens

De
ServerTokens Full

Para
ServerTokens Prod

* ServerSignature

De
ServerSignature On

Para
ServerSignature Off

* TraceEnable

De
TraceEnable On

Para
TraceEnable Off

* Protega o acesso aos arquivos

Edite os arquivos existentes no diretório /etc/apache/sites-available . Altere os parâmetros diretiva Directory / deixando da seguinte forma:

Order Deny,Allow
Deny from all

Habilite o mod_security

Se você possuir um espírito aventureiro e gostar de fortes emoções recomendo o uso do mod_security. Ele bloqueia o monitoramento de requisições e respostas HTTP tanto quanto a negação de pacotes suspeitos.

Se você possui as caracteristicas acima então siga meu post com o passo a passo para habilitá-lo.

Links Recomendados

* Apache Performance Tunning
* Apache Security Tips

Auditoria – Ferramentas

Nikto

O Nikto Webserver Scanner é uma excelente ferramenta de auditoria para servidores Web. Escrito em perl e mantido pelo CIRT se tornou parte integrante do Nessus.
Muito cuidado com os reports gerados por ele, o ideal é estudar e testar cada alerta gerado pois alguns deles são falsos positivos, isso não tira de forma alguma o brilho desta ferramenta.

W3af

O W3af é um completo framework para ataque e auditoria de servidores Web. Ele faz o serviço completo ( barba, cabelo e bigode ) sendo capaz de fazer uma simples auditoria de vulnerabilidades ao ataque propriamente dito.

Diferentemente do Nikto ele é um devorador de recursos e pode levar dias para concluir uma auditoria de acordo com os plugins habilitados, principalmente se habilitar todos os plugins do módulo Discovery.

Para um relatório efetivo de como anda a segurança do seu Webserver recomendo o trabalho em conjunto do Nessus, Nikto e o W3af.

Post to Twitter Tweet This Post

Estamos de mudança

March 2, 2010 by alexos · Leave a Comment 

Após alguns meses de aluguel resolvi tomar vergonha na cara e oganizei um lar definitivo para o Alexos Core Labs. Meu grande amigo/irmão Ricardo Cropalato cedeu um espaço em seu webhost mas vi a possibilidade de manter meu próprio servidor, coisa que não estava afim de fazer tempos atrás.

Estou muito satisfeito com a infra-estrutura de VPS que estamos usando na Colivre, estamos mantendo nossos serviços tanto no Slicehost quanto no Linode. Escolhi um VPS no Linode para ser a nova casa deste blog.

Aproveitando registrei os dominios alexos.org e alexos.net. Vi que os leitores da lingua inglesa estavam reclamando do Google Translate então resolvi montar a versão em inglês usando o dominio alexos.org.

Muitas novidades estão por vir em breve. Estou trabalhando duro para manter um blog de qualidade e sempre atualizado.

Aguardem….

Post to Twitter Tweet This Post

Infraestrutura para Aplicações Web Seguras parte 2 – SGBDs ( Updated )

February 25, 2010 by alexos · 1 Comment 

O SGBD é ao mesmo tempo o bom e o mau elemento deste processo. Se bem configurado e mantido será um aliado poderoso, infelizmente isto nem sempre ocorre sendo bastante otimista.

As últimas noticias revelam que as boas práticas não estão sendo obedecidas. A técnica de ataque mais utilizada atualmente é o SQL Injection que é injectar código malicioso permitindo desde a criação de um simples usuário até a total indisponibilidade do serviço.

99.99% dos sites comprometidos ( defacements ) diariamente estão vulneráveis a este de ataque.Esta falha não está somente ligada ao SGBD, um código mau escrito abre esta e outras vulnerabilidades na aplicação como veremos na 3a. parte do nosso artigo.

Os SGBDs mais utilizados numa infraestrutura baseada em software livre são o MySQL e o Postgresql. Cada um destes sistemas possuem características que atendem a várias demandas de performance, produtividade, escalabilidade e segurança.

A implementação de uma infraestrutura segura para banco de dados inicia-se na modelagem do banco, uma modelagem bem feita permitirá que sua base de dados expanda mantendo a total integridade, escalabilidade e segurança. Evitando brechas de segurança e evitando as sempre presentes “gambiarras”.

Como definimos anteriormente o sistema de arquivos* e o tipo de redundância dos discos** serão itens criticos na performance e segurança na manipulação dos dados.

* Recomendo o uso do sistema de arquivos XFS
** Recomendo o uso do RAID 0+1

SGBD MySQL Seguro

1 – Amplie a segurança local

Desabilite o uso do comando LOAD DATA LOCAL INFILE prevenindo contra ataques que permitem a leitura dos arquivos locais. Isso é importante caso haja ataque de SQL Injection através de uma vulnerabilidade no código PHP.

Adicione o seguinte parâmetro na seção [mysqld] do arquivo /chroot/mysql/etc/my.cnf:

set-variable=local-infile=0

2 – Altere a senha do usuário root do banco

mysqladmin -u root password ‘NOVA_SENHA’ -p

3 – Remova usuários e bases padrões

mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host=”localhost” and user=”root”);
mysql> flush privileges;

4 – Renomeie a conta do admin ( root )

mysql> update user set user=”mydbadmin” where user=”root”;
mysql> flush privileges;

5 – Crie contas de usuários separadas para cada aplicação

mysql -u mydbadmin -p

mysql> CREATE DATABASE blog;
mysql> CREATE DATABASE guestbook;

mysql> CREATE USER ‘blgu’@'localhost’ IDENTIFIED BY ‘SENHA’;
mysql> CREATE USER ‘gbu’@'localhost’ IDENTIFIED BY ‘OUTRASENHA’;

mysql> GRANT ALL PRIVILEGES ON blog.* TO ‘blgu’@'localhost’ WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON guestbook.* TO ‘gbu’@'localhost’ WITH GRANT OPTION;

mysql> FLUSH PRIVILEGES;

MySQL Tunning

Para fazer o tunning do MyQSL recomendo o uso do seguinte script:

MySQL Performance Tuning Primer Script

O uso desta ferrramenta é recomendado após 48 horas de uso do banco permitindo que o script detecte os valores corretos para o tunning do banco.

Links Recomendados:

* Making MySQL Secure Against Attackers

* Six steps to secure sensitive data in MySQL

* SQLHack – Secure your MySQL

SGBD Postgresql Seguro

No caso do Postgresql recomendo a leitura do material do Fernando Ike aka Fike, o cara é uma sumidade no assunto. Nesta apesentação ele aborda o tunning de performance e segurança do Postgresql

* Performance Tuning para banco de dados PostgreSQL

Links Recomendados:

* Securing your PostgreSQL Database
* PostgreSQL – Security

Auditoria – Ferramentas

* OWASP SQLiX Project
* Security Database
* SQL Injection Tools
* SQL Injection Vulnerability Online Test
* SQL Inject Me – Firefox Addon

Outros Links

* SQL Injection Prevention Cheat Sheet
* Database Security
* Blind SQL Injection

Post to Twitter Tweet This Post

Infraestrutura para Aplicações Web Seguras parte 1 – Sistema ( Updated )

February 25, 2010 by alexos · Leave a Comment 

Neste artigo abordarei como montar/manter um servidor seguro. Uso o Debian GNU/Linux como sistema base mas todas as ferramentas e procedimentos listados servem para qualquer Unix-like.

Um dos grandes inimigos na implementação de qualquer solução é o tempo. Tudo tem que ser feito no menor tempo possível, com o menor gasto possível e com 0% de falha. Para respeitamos todas essas premissas as orientações apresentadas serão de rápida implementação e fácil manutenção.

Hardening

Trocando em miúdos o hardening é o fortalecimento de um sistema, serviço ou aplicação com o objetivo de minimizar ou dificultar a ação de hackers e crackers.

Iniciamos o hardening antes da instalação do sistema. Neste momento planejamos:

1 – Daemons/serviços que serão disponibilizados;
2 – Particionamento;

1 – Como o foco do nosso artigo são aplicações Web já sabemos que vamos trabalhar com o Quarteto Fantástico – Linux, Apache, PHP e MySQL ou Postgresql. De antemão já temos definidos os serviços que serão disponibilizados.

2 – Com isso definido recomendo que o diretório /var permaneca numa partição separada, lá ficarão os arquivos do site no /var/www e os arquivos do banco em /var/lib/mysql.
Dependendo da aplicação é possivel que o BD cresca rapidamente então recomendo separar a maior parte do disco para está partição e também recomendo a utilzação do sistema de arquivos XFS.

Quer saber porque recomendo o uso deste sistema de arquivos? CLIQUE AQUI

Feito todo o planejamento e com o S.O. instalado iniciaremos os procedimentos de pós-instalação:

1 – Atualizar todo o sistema. No caso do Debian recomendo antes de tudo ajustar o arquivo sources.list removendo todo o conteúdo e adicionado os seguintes repositórios:

deb http://ftp.us.debian.org/debian stable main contrib
deb http://security.debian.org/ stable/updates main contrib

Feito isso use o velho e bom aptitude update && aptitude safe-upgrade

2 – Remova todos os serviços desnecessários:

Recomendo a instalação do Nmap, assim de forma fácil e rápida descobriremos as portas abertas e os serviços em execução.

Exemplo:

nmap localhost

Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-25 00:53 BRT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000021s latency).
Hostname localhost resolves to 2 IPs. Only scanned 127.0.0.1
Not shown: 996 closed ports
PORT STATE SERVICE
xx/tcp open xxx
xxx/tcp open xxxx
xxx/tcp open xxx
xxx/tcp open xxxxx

Nmap done: 1 IP address (1 host up) scanned in 0.22 seconds

Você poderá remover a aplicação indesejada usando o comando aptitude remove [aplicação] ou apenas impedir que ela seja executada durante o boot, como por exemplo o MTA exim usando o comando update-rc.d -f exim remove. Dessa forma o exim permanecerá instalado, por ser dependência para outras aplicações, mas não será executado durante o boot.

3 – Use o sudo

Evite logar no sistema usando o usuário root e não deixe que membros da equipe façam o mesmo, assim é possivel fortalecer a auditoria de autenticação, instalação e remoção de pacotes e ações que podem danificar o sistema.

4 – Bloqueie o usuário root

Use o comando usermod -L root para bloquear o login usando o usuário root.

5 – Mude a porta padrão do ssh e bloqueie o login do usuário root

Segurança por obscuridade é uma das técnicas utilizadas para dificultar o footprinting, e o port scanning do seu sistema.
Para fazer estas modificações acesse o arquivo /etc/ssh/sshd_config e altere as seguintes linhas:

Port 22

para por exemplo

Port 3000

PermitRootLogin yes

para

PermitRootLogin no

Refinando o processo de Hardening

Algumas ferramentas podem ser utilizadas para ajudar no processo de hardening do sistema. Recomendo fortemente o uso das seguintes ferramentas:

Hntool

Este é um novo projeto do meu amigo sergipano Hugo Doria que vem crescendo bem rápido e vem contando com novas contribuições diariamente.
O objetivo desta ferramenta é facilitar a vida do Sysadmin informando as melhorias necessárias para fortalecer os serviços e o próprio sistema.
Como ele é totalmente modular fica muito fácil contribuir. Se você quer aprender a programar em Python essa é hora.
Contribua com o desenvolvimento do Hntool. A comunidade de brasileira de segurança da informação agradece.

Bastille

O Bastille protege o sistema operacional, configurando o sistema de maneira pro-ativa para aumentar sua segurança e reduzir as chances de comprometimento. Ele também pode ser usado para assessorar no processo de Hardening do sistema, reportando e detalhando cada configuração de segurança usada pelo programa.

Ele auxilia o usuário/administrador do sistema a escolher exatamente como fortalece-lo. No modo de operação/hardening padrão, ele interage com o usuário fazendo perguntas , explicando cada tópico para, então, criar uma política baseada nas respostas do usuário. Logo em seguida, aplica-se as políticas no sistema. No modo de auditoria, ele cria um relatório para ensinar o usuário sobre as configurações de segurança disponíveis, além de informar quais configurações foram definidas/ajustadas.

Para ajudar na instalação e configuração disponibilizo o capitulo referente ao Bastille que criei para minha aula na Pós em Segurança da Informação da Unijorge.

Monitoramento Seguro

Após todos os ajustes necessários é hora de monitorar e manter o ambiente sempre disponível e seguro. Para isso recomendo a instalação das seguintes ferramentas:

Ossec HIDS

O OSSEC é um escalável, multi-plataforma, e open source HIDS. Ele integra análise de log, checagem de integridade de arquivos, politica centralizada, detecção de rootkit, alerta em tempo real e resposta automática.

Para facilitar a implentação postei 03 artigos com a instalação do Ossec Server, o Agente e a Interface Web.

Lenbrando que existe a opção da instalação local ( standalone ) permitindo que você seja alertado através do email.

Munin

O Munin é uma ferramenta de gerência de desempenho muito simples de instalar e configurar. Ela permite que você obtenha informações em tempo real de como anda o seu sistema.

Veja o post que disponibilizei sobre está excelente ferramenta.

Apticron

O Apticron é um script que alerta via email diariamente sobre novas atualizações no seu servidor, no alerta você encontra a lista de pacotes que precisam ser atualizados e todo o changelog.

Acesse os links 1 ou 2 para obter informações de como instalar e configurar está ferramenta bastante útil.

Conclusão

Finalizo aqui a 1a. parte da nossa saga. Peço desculpas aos leitores que querem mais informações técnicas sobre os assuntos abordados, só que o objetivo destes artigos é trazer recomendações e referências rápidas. Prometo trazer informações mais técnicas sobre os assuntos abordados em breve.

Post to Twitter Tweet This Post

Next Page »