rootsh é um shell que loga tudo o que um usuário root vê no terminal. É útil se você tem vários administradores com acesso root num servidor e você quer gravar exatamente o que o usuário faz.

Fazer o download do rootsh-1.5.3.tar.gz.

wget http://www.virtualxp.org/downloads/rootsh-1.5.3.tar.gz

Descompactar, configurar, compilar e instalar:

tar zxvf rootsh-1.5.3.tar.gz -C /usr/src
cd /usr/src/rootsh-1.5.3
./configure --disable-syslog --disable-linenumbering
make
make install

Depois de instalado os binários, o sistema está quase pronto. A única necessidade que falta é criar o diretório do rootsh em /var/log onde serão gravados os logs. Esse procedimento não está documentado, mas é necessário.

mkdir /var/log/rootsh

Garantindo que o usuário root usará o rootsh como shell padrão

Para garantir que o usuário root usará o rootsh como shell padrão, adicione o rootsh ao arquivo /etc/shells:

echo /usr/local/bin/rootsh >> /etc/shells

Após esse passo, definir o shell para o usuário root

usermod -s /usr/local/bin/rootsh root

Então, toda vez que o usuário root fizer login, seja direto por ssh ou por su será criado um arquivo de log em /var/log/rootsh com a seguinte estrutura:

< user >.< date >< time >.< process id >

A formatação de cada arquivo de log é exatamente a mesma que o usuário vê no terminal.

cd /var/log/rootsh
ls
root.20100420105208.00a0a.closed
#

Conclusão

Se você não confia em seus sysadmins, ou se você quer ter um controle a mais do que está sendo feito no seu sistema, não tem erro com rootsh

Não é preciso descrever como é importante em um ambiente onde haja computadores Windows envolvidos que é necessário ter um antivírus no servidor de arquivos Linux ou FreeBSD com o Samba.

Essa versão do artigo irá cobrir Red Hat / CentOS versão 5.x.

Pré-requisitos

• Instalação mínima do CentOS e RedHat 5.3
• Utilizando o repositório Yum RPMforge

1.0 Instalando o ClamAV

É necessário o repositório Yum RPMforge estar instalado e configurado. Veja “Pré-requisitos”.

yum install clamav clamav-db clamd

1.1 Configurando o clamd

Após a instalação do clamav, edite o arquivo /etc/clamd.conf e adeque as suas necessidades.

Para uma utilização geral, a seguinte configuração é suficiente:

Arquivo: /etc/clamd.conf

LogFile /var/log/clamav/clamd.log
LogFileMaxSize 0
LogTime yes
LogSyslog yes
PidFile /var/run/clamav/clamd.pid
TemporaryDirectory /var/tmp
DatabaseDirectory /var/clamav
LocalSocket /var/run/clamav/clamd.sock
FixStaleSocket yes
TCPSocket 3310
TCPAddr 127.0.0.1
MaxConnectionQueueLength 30
MaxThreads 50
ReadTimeout 300
User root
AllowSupplementaryGroups yes
ScanPE yes
ScanELF yes
DetectBrokenExecutables yes
ScanOLE2 yes
ScanMail yes
ScanArchive yes
ArchiveBlockEncrypted no

Por que o usuário ‘root’? Porque por padrão o Clamd roda como usuário ‘clamav’ e quando o Samba chamar o clamav e for necessário apagar algum arquivo com vírus ele não vai ter permissão.

Inicar e garantir que iniciará no boot:

chkconfig --levels 35 clamd on
service clamd start

Starting Clam AntiVirus Daemon:                            [  OK  ]

1.2 Configurando freshclam para atualizações

Editar o arquivo de configuração do freshclam que ficará parecido com o seguinte:

Arquivo: /etc/freshclam.conf

DatabaseDirectory /var/clamav
UpdateLogFile /var/log/clamav/freshclam.log
LogTime yes
DatabaseMirror db.br.clamav.net
DatabaseMirror database.clamav.net
DatabaseOwner root
NotifyClamd /etc/clamd.conf
SubmitDetectionStats /etc/clamd.conf

Criar o arquivo de log pro Freshclam

touch /var/log/clamav/freshclam.log
chown clamav:clamav /var/log/clamav/freshclam.log

Caso seu servidor não tenha acesso diretamente à internet mas você possui um proxy na rede, coloque os seguintes parâmetros no arquivo /etc/freshclam.conf com as informações do proxy.

Arquivo: /etc/freshclam.conf

HTTPProxyServer 192.168.1.1
HTTPProxyPort 3128
HTTPProxyUsername user
HTTPProxyPassword s3nh4

Após isso, a permissão do arquivo /etc/freshclam.conf deverá ser 0600.

chmod 0600 /etc/freshclam.conf

Pode-se executar o comando freshclam para atualizar a assinatura de vírus.

freshclam

2.0 Instalando o Samba

A versão que vem por padrão com o Red Hat / CentOS não é possível utilizar em conjunto com o vscan, por isso será necessário compilar o Samba para que tenha suporte ao samba-vscan.

2.0.1 RPMs 64 bits gerados

Se o seu SO é 64 bits, então os pacotes do Samba eu compilei e estou disponbilizando aqui, pra facilitar o trabalho e não ser necessário instalar o ambiente de desenvolvimento no servidor.

• samba-3.0.33-3.14.x86_64.rpm
• samba-client-3.0.33-3.14.x86_64.rpm
• samba-common-3.0.33-3.14.x86_64.rpm

Caso queira compilar, prossiga para o próximo passo

2.0.2 Preparando o Samba para gerar o pacote .rpm

Faça o download do RPM source do samba:

cd ~
wget http://netops.nexicom.net/centos/5.4/updates/SRPMS/samba-3.0.33-3.14.el5.src.rpm

Instalar os arquivos:

rpm -ivh samba-3.0.33-3.14.el5.src.rpm

É necessário descompacatar o .tar.gz do código fonte e depois compactá-lo.

cd /usr/src/redhat/SOURCES
tar zxvf samba-3.0.33.tar.gz
cd samba-3.0.33/source
./autogen.sh && ./configure
make proto

Se ao tentar compilar o Samba, ao executar os comandos acima você tiver a seguinte mensagem:

./autogen.sh && ./configure
./autogen.sh: running script/mkversion.sh
./script/mkversion.sh: 'include/version.h' created for Samba("3.0.33")
./autogen.sh: running autoheader -I. -Ilib/replace
./autogen.sh: running autoconf -I. -Ilib/replace
Now run ./configure and then make.
SAMBA VERSION: 3.0.33
LIBREPLACE_LOCATION_CHECKS: START
...
LIBREPLACE_LOCATION_CHECKS: END
LIBREPLACE_CC_CHECKS: START
checking for gcc... no
checking for cc... no
checking for cc... no
checking for cl... no
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details.

É por que não tem os pacotes de desenvolvimento instalado, para resolver isso, instale-os:

yum install rpm-build gcc gcc-c++ make autoconf automake libtool

2.1 Fazer o download do vscan

2.1.1 Binário 64bits do vscan

Caso seu SO seja 64 bits, estou dispobilizando a biblioteca do vscan-clamav já compilada.

• vscan-clamav.so

Caso seja 32 bits ou queira compilar o código fonte, prossiga para o próximo tópico.

2.1.2 Compilando pelo código fonte

cd ~
wget http://www.openantivirus.org/download/samba-vscan-0.3.6c-beta5.tar.gz

Descompactar:

tar zxvf ~/samba-vscan-0.3.6c-beta5.tar.gz -C /usr/src

Compilar o samba-vscan:

cd /usr/src/samba-vscan-0.3.6c-beta5/
./configure --with-libclamav --with-samba-source=/usr/src/redhat/SOURCES/samba-3.0.33/source/

Ao final, você terá algo como:

** Configuration summary for samba-vscan 0.3.6c beta5 :

 Compile samba-vscan for Samba      : "3.0.33"
 Compile samba-vscan with sources in: /usr/src/redhat/SOURCES/samba-3.0.33/source/
 Compile samba-vscan backends       : oav sophos fprotd fsav trend icap mksd kavp clamav nai antivir
 Use GLOBAL_LIBS                    : -lmagic
 Use libmksd as                     : builtin
 Use libkavdc as                    : builtin

Hora de começar a compilar o samba-vscan:

cd /usr/src/samba-vscan-0.3.6c-beta5
make

Por enquanto é isso. Não execute make install.

2.1 Gerando o .rpm para o samba com vscan

2.1.1 Gerar o .rpm do samba

Agora é necessário compactar o diretório samba-3.0.33 novamente pra gerar o .rpm com tudo certo dentro.

Instalar dependências:

yum install cups-devel gnutls-devel pam-devel readline-devel ncurses-devel libacl-devel openldap-devel openssl-devel

cd /usr/src/redhat/SOURCES/
mv samba-3.0.33.tar.gz samba-3.0.33.tar.gz.orig
tar zcvf samba-3.0.33.tar.gz samba-3.0.33

Gerar o .rpm do samba-3.0.33:

cd /usr/src/redhat/SPECS/
rpmbuild -bb samba.spec

Ao final do processo, você terá algo como:

Wrote: /usr/src/redhat/RPMS/x86_64/samba-3.0.33-3.14.x86_64.rpm
Wrote: /usr/src/redhat/RPMS/x86_64/samba-client-3.0.33-3.14.x86_64.rpm
Wrote: /usr/src/redhat/RPMS/x86_64/samba-common-3.0.33-3.14.x86_64.rpm
Wrote: /usr/src/redhat/RPMS/x86_64/samba-swat-3.0.33-3.14.x86_64.rpm
Wrote: /usr/src/redhat/RPMS/x86_64/samba-debuginfo-3.0.33-3.14.x86_64.rpm
...

Para instalar, utilizaremos o próprio rpm.

rpm -iUvh /usr/src/redhat/RPMS/x86_64/samba-3.0.33-3.14.x86_64.rpm /usr/src/redhat/RPMS/x86_64/samba-client-3.0.33-3.14.x86_64.rpm /usr/src/redhat/RPMS/x86_64/samba-common-3.0.33-3.14.x86_64.rpm

Eu já tinha o samba instalado e nesse caso não me deixou instalar por cima e finalizou com as seguintes mensagens:

Preparing...                ########################################### [100%]
	package samba-common-3.0.33-3.15.el5_4.1.x86_64 (which is newer than samba-common-3.0.33-3.14.x86_64) is already installed
	package samba-3.0.33-3.15.el5_4.1.x86_64 (which is newer than samba-3.0.33-3.14.x86_64) is already installed
	package samba-client-3.0.33-3.15.el5_4.1.x86_64 (which is newer than samba-client-3.0.33-3.14.x86_64) is already installed

Nesse caso é seguro executar o rpm com o parâmetro --force

rpm -iUvh --force /usr/src/redhat/RPMS/x86_64/samba-3.0.33-3.14.x86_64.rpm /usr/src/redhat/RPMS/x86_64/samba-client-3.0.33-3.14.x86_64.rpm /usr/src/redhat/RPMS/x86_64/samba-common-3.0.33-3.14.x86_64.rpm

Preparing...                ########################################### [100%]
   1:samba-common           ########################################### [ 33%]
   2:samba                  ########################################### [ 67%]
   3:samba-client           ########################################### [100%]

3.0 Configuração do vscan

No diretório /etc/samba crie o arquivo de configuração para o samba-vscan (um exemplo desse arquivo está em: /usr/src/samba-vscan-0.3.6c-beta5/clamav/vscan-clamav.conf)

Arquivo: /etc/samba/vscan-clamav.conf

max file size = 0
verbose file logging = no
scan on open = yes
scan on close = yes
deny access on error = yes
deny access on minor error = yes
send warning message = yes
infected file action = delete
quarantine directory  = /tmp
quarantine prefix = vir-
max lru files entries = 100
lru file entry lifetime = 5
exclude file types =
exclude file regexp =
clamd socket name = /var/run/clamav/clamd.sock
scan archives = yes
libclamav max files in archive = 1000
libclamav max archived file size = 10485760
libclamav max recursion level = 5

64 bits

Copie a lib gerada do vscan para o ClamAV que está em /usr/src/samba-vscan-0.3.6c-beta5/

cd /usr/src/samba-vscan-0.3.6c-beta5/
cp vscan-clamav.so /usr/lib64/samba/vfs

32 bits

Copie a lib gerada do vscan para o ClamAV que está em /usr/src/samba-vscan-0.3.6c-beta5/

cd /usr/src/samba-vscan-0.3.6c-beta5/
cp vscan-clamav.so /usr/lib/samba/vfs

4.0 Configuração do Samba para utilizar o vscan

Edite o arquivo /etc/samba/smb.conf e adicione as entradas em [global]

Arquivo: /etc/samba/smb.conf

        vfs object = vscan-clamav
        vscan-clamav: config-file = /etc/samba/vscan-clamav.conf

Pronto.

Só falta iniciar ou reiniciar o Samba:

service smb start
Starting SMB services:                                     [  OK  ]
Starting NMB services:                                     [  OK  ]

Os logs dos arquivos scanneados são mostrados em /var/log/messages.

5.0 Não permitir que o yum atualize o Samba

É interessante não permitir que o yum atualize o Samba, se isso acontecer, as alterações feitas pelo samba-vscan quando compilamos ele serão perdidas e você perderá as funcionalidade de antivírus do Samba.

Para fazer isso, é bem simples, adicione a seguinte linha no arquivo /etc/yum.conf na sessão [main]

exclude=samba*

Ao iniciar o FreeBSD em single mode, o Sistema entra direto como root, sem pedir senha.

Causa

Para evitar esse tipo de situação e obrigando quem quer que seja a saber a senha para poder mexer no sistema, proceda da seguinte maneira:

Edite o arquivo /etc/ttys e procure pela linha

console none                            unknown off secure

Solução

E altere o parâmetro onde lê-se secure para insecure, ficando assim:

console none                            unknown off insecure

Após isso, quando for iniciado no single mode, o acesso somente será permito à console mediante confirmação da senha.

O gnarwl é de longe o melhor auto-reply disponível, bastante customizável e o melhor é que usa LDAP e é facilmente integrado com o Postifx.

Lembrando que se você tem o plugin ‘vacation’ no squirrelmail ele não vai ter incompatilidade, uma vez que setando a auto-resposta no squirrelmail vai sobrescrever os dados colocados originalmente no LDAP manualmente ou pelo phamm ou pelo GOsa2, ou seja, tranquilo :)

Não vou discutir aqui como instalar o gnarwl, pois para isso vou fazer outro post.

Esse post é específico em criar uma política que permita o Postfix “conversar” com o gnarwl, ou seja, vai permitir que o Postfix envie a mensagem, via BCC ao gnarwl e este verificará se o campo vacationActive está como TRUE.

Criando o arquivo com as regras

Primero, crie o arquivo que contém as regras para o gnarwl, chamando-o de gnarwl.te e com o seguinte conteúdo:

Arquivo gnarwl.te

module gnarwl 1.0;

require {
	type var_lib_t;
	type postfix_postdrop_t;
	type postfix_local_t;
	type sendmail_exec_t;
	class unix_stream_socket { read write getattr };
	class file { execute read lock create execute_no_trans write getattr };
	class dir { write search add_name };
}

#============= postfix_local_t ==============
allow postfix_local_t sendmail_exec_t:file { read execute execute_no_trans };
allow postfix_local_t var_lib_t:dir { write add_name };
allow postfix_local_t var_lib_t:file { read lock getattr write create };

#============= postfix_postdrop_t ==============
allow postfix_postdrop_t postfix_local_t:unix_stream_socket { read write getattr };

Vou explicar algumas linhas.

Linha 7 e 14: o postfix tem que ter permissão para executar o sendmail, pois quando o email é encaminhado para o usuário gnarwl (é um usuário local do Linux) ele auto-responde a mensagem para quem enviou, por isso essa regra é necessária.

Linhas 8 e 19: ao acessar o arquivo .forward do home do gnarwl, tem o comando que faz um pipe para o executável do gnarwl, essa linha é |/usr/bin/gnarwl, por isso o postfix precisa dessa permissão.

Compilando as regras

Com o arquivo criado, é necessário compilar as régras e instalar a nova política.

checkmodule -M -m -o gnarwl.mod gnarwl.te

O resultado do comando será algo parecido com:

checkmodule:  loading policy configuration from gnarwl.te
checkmodule:  policy configuration loaded
checkmodule:  writing binary representation (version 6) to gnarwl.mod

semodule_package -o gnarwl.pp -m gnarwl.mod

Se tudo for Ok, não haverá resultado de saída.

semodule -i gnarwl.pp

Se tudo for Ok, não haverá resultado de saída.

Verificando a instalação

O comando semodule -l lista todos os módulos instalados, veja que o novo módulo gnarwl 1.0 está instalado.

semodule -l |grep gnarwl
gnarwl	1.0

Se algum problema ocorreu no processo, comente sua dúvida.

• As aplicações instaladas no servidor de repente começam a não responder de forma esperada, ou seja, problemas incomuns e um ambiente considerado estável
• Contas de usuários adicionais que você não consegue visualizar (elas podem ter sido feitas para parecer com contas do sistema)
• Novos arquivos ou diretórios com nomes incomuns, por exemplo ‘…’, ‘.qualquercoisa’ etc
• Tráfego de rede acima do comum e que não podem ser atribuidas a um processo em particular
• Você recebe um email de um departamento de segurança dizendo que seu servidor foi detectado em estar fazendo port scan ou enviando tráfego de rede malicioso para determinado site
• O servidor está rodando significativamente lento e alto consumo de processamento.

Esses são os pontos principais, onde, pode haver um ou até mesmo todos os sintomas listados acima, mas não limitado a esses.

Link relacionado

Nesse Blog, do meu amigo Luciano, tem uma análise completa de um host comprometido e detalhamento do que foi feito para identificar e combater. Obrigado pela contribuição Luciano!

• http://lucianoborguetti.blogspot.com/2009/06/possible-t0rn-v8-or-variation-rootkit.html

Comente caso você tenha uma outra característica!

Having a centralized logging is a prerequisite if you want to have your logs intacts. But having the events recorded in plain files is virtually impossible for queries.

Because of this, I will show you how to configure rsyslog to write events in MySQL DB and a web interface for queries with filters to facilitate viewing of the logs without have to access the console for such task.

The focus of this post is on CentOS / Red Hat, but it can be used in other distributions with a few modifications in the process.

Prerequisites

• Instalação mínima do CentOS e RedHat 5.3

It may be interesting for you to use a web-based repository for Yum for this follow the instructions in this post

• CentOS 5: Utilizando repositório Yum da internet

Installing the necessary packages

yum install rsyslog.i386 rsyslog-mysql.i386 mysql-server php php-mysql php-gd httpd mod_ssl

Making sure that the services will start at boot

chkconfig --levels 35 rsyslog on
chkconfig --levels 35 httpd on
chkconfig --levels 35 mysqld on

Setting rSyslog

As syslog comes by default with CentOS 5 / Red Hat 5, it is necessary to disable it because both of them uses the same port to listen for write request (UDP 514). rSyslog won’t start if syslog is active.

service syslog stop
chkconfig --del syslog

Note

rSyslog uses the same syntax as syslog.conf. So, if you have a customized configuration you can copy syslog.conf over rsyslog.conf, just remember to rename the original rsyslog.conf to rsyslog.conf.orig just in case something goes wrong then you can rollback to the original one.

To rSyslog have access to MySQL it’s necessary to load the ommysql plugin, add this line at the begin of the /etc/rsyslog.conf file.

$ModLoad ommysql.so

Creating a MySQL database for rSyslog

Before everything, it’s needed to start MySQL service

service mysqld start

As root, lets create the access for the user from rSyslog to connect do database

mysql

mysql> CREATE USER 'rsyslog'@'localhost' IDENTIFIED BY 'P45sword';
mysql> GRANT ALL PRIVILEGES ON Syslog.* TO 'rsyslog'@'localhost' WITH GRANT OPTION;

Now, create the database that will be used by rSyslog

As root, run

mysql < /usr/share/doc/rsyslog-mysql-2.0.6/createDB.sql

Back to the file, /etc/rsyslog.conf add this line before the rsyslog directives

*.*    :ommysql:localhost,Syslog,rsyslog,P45sword

This is the syntax:

   :ommysql:database-server,database-name,database-userid,database-password

Where

• ommysql: is the plugin name
• database-server: MySQL db server address (tipicaly localhost)
• database-name: database
• database-userid: the user allowed to connect to MySQL
• database-password: user password

At the end of this process, the file /etc/rsyslog.conf will look like

$ModLoad ommysql.so

*.*                      :ommysql:localhost,Syslog,rsyslog,P45sword

*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 *
uucp,news.crit                                          /var/log/spooler
local7.*                                                /var/log/boot.log

Allowing remote connections to rSyslog

Edit the /etc/sysconfig/rsyslog file and add the parameter -r at line 6

SYSLOGD_OPTIONS="-r -m 0"

It’s possible to start rsyslog right now, so you can see if everything gonna ok

service rsyslog start

Watch the log /var/log/messages, if everything is ok, a message from rsyslog starting may look like this one, without error

Sep 22 18:42:23 master rsyslogd: [origin software="rsyslogd" swVersion="2.0.6" x -pid="2779" x-info="http://www.rsyslog.com"][x-configInfo udpReception="Yes" udp Port="514" tcpReception="No" tcpPort="0"] restart
Sep 22 18:42:23 master kernel: rklogd 2.0.6, log source = /proc/kmsg started.

Installing the Web UI client for rSyslog

With the rsyslog service ok, comes the part where we configure the web interface to make de filters, queries etc.

Download the frontend phpLogCon to your server

wget http://www.virtualxp.org/downloads/phplogcon-2.6.4.tar.gz

Extract to /usr/src

tar zxvf phplogcon-2.6.4.tar.gz -C /usr/src

Go to directory where you extracted it, in this case /usr/src/phplogcon-2.6.4 and copy the directory src to /var/www/html

cp -R src /var/www/html/syslog
cd /var/www/html/syslog
touch config.php
chown apache config.php

If you haven’t started apache yet, you can do it now

service httpd start

Starting httpd:                                            [  OK  ]

Access your web browser pointing to server address http://172.20.32.205/syslog, replace the address with your server.

Note the error, it’s normal and awaited. Click in “here” to start configuring phpLogCon.

The installer will check the OS for the prerequisites to start the program. Click “Next”.

The test was done on the phpLogCon has write access to config.php file that we created and defined the permission. Click “Next” to continue.

On Basic Configuration, let the default options selected. Click “Next”.

This is the most important part, it’s here that will be configured the data sources from Syslog.

Change the field “Source Type” to “MySQL” and fill the fields on block “Database Type Options”, like the figure above.

Click Next.

Ready! All okie dokie now!

Click “Finish!” and you will be redirected to the main screen for the phpLogCon.

Setting clients to log on Syslog server

On Linux clientes that you wanna log on a Syslog server, you must configure /etc/syslog.conf and add the following line:

*.*                   @syslog_server

Where, “syslog_server” is the hostname or IP Address from syslog server.

With this done, you need to restart Syslog service on host client

service syslog restart

Those procedures are for Red Hat / CentOS servers clients. You should adapt to you distribution.

Please, leave a comment showing the procedure for your client! It will be very helpful.

Ter um log centralizado é um pré-requisito se você quer ter seus logs íntegros. Mas ter os eventos registrados apenas em arquivos é praticamente inviável para consultas.

Por conta disso, mostrarei aqui como configurar o rSyslog para gravar os eventos no MySQL e uma interface web para consultas, com filtros e tudo o mais para facilitar a visualização dos logs sem ser precisso acessar a console para tal atividade.

Pré-requisitos

• Instalação mínima do CentOS e RedHat 5.3

Talvez seja interessante pra você utilizar um repositório Web para o Yum, para isso siga as instruções desse post

• CentOS 5: Utilizando repositório Yum da internet

Instalando os pacotes necessários

yum install rsyslog.i386 rsyslog-mysql.i386 mysql-server php php-mysql php-gd httpd mod_ssl

Certificando que os serviços inicializarão no boot

chkconfig --levels 35 rsyslog on
chkconfig --levels 35 httpd on
chkconfig --levels 35 mysqld on

Configurando o rSyslog

Como o syslog vem por padrão instalado no CentOS 5 / Red Hat 5, é necessário desabilitá-lo porque ambos utilizam a mesma porta para ouvir requisições de gravação remotas (UDP 514) e o rSyslog não vai iniciar se o syslog estiver ativo.

service syslog stop
chkconfig --del syslog

Nota

O rSyslog entende a mesma sintaxe do syslog.conf. Então, se você tiver uma configuração específica para o syslog hoje pode copiar o arquivo syslog.conf para rsyslog.conf, lembrando de renomear o rsyslog.conf para rsyslog.conf.orig, assim caso alguma coisa aconteça de errado poderá voltar o arquivo original.

Para o rSyslog ter acesso ao MySQL é preciso carregar o plugin ommysql, acrescente essa linha no início do arquivo /etc/rsyslog.conf

$ModLoad ommysql.so

Criando a base MySQL para o rSyslog

Antes de tudo é preciso iniciar o serviço do MySQL

service mysqld start

Como root, vamos criar o acesso para o usuário do banco que o rSyslog irá utilizar para conectar-se

mysql

mysql> CREATE USER 'rsyslog'@'localhost' IDENTIFIED BY 'P45sword';
mysql> GRANT ALL PRIVILEGES ON Syslog.* TO 'rsyslog'@'localhost' WITH GRANT OPTION;

E agora, criar o banco de dados que será utilizado pelo rSyslog.

Como root, execute o comando

mysql < /usr/share/doc/rsyslog-mysql-2.0.6/createDB.sql

De volta ao arquivo /etc/rsyslog.conf acrescente essa linha, antes das diretivas do rSyslog

*.*    :ommysql:localhost,Syslog,rsyslog,P45sword

A sintaxe é essa:

:ommysql:database-server,database-name,database-userid,database-password

Onde

• ommysql: é o nome do plugin
• database-server: endereço do servidor do MySQL
• database-name: nome da base
• database-userid: usuário que conectar-se-á e tem permissão no MySQL
• database-password: senha do usuário

Ao final do processo o arquivo /etc/rsyslog.conf parecerá com o seguinte

$ModLoad ommysql.so

*.*                      :ommysql:localhost,Syslog,rsyslog,P45sword

*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 *
uucp,news.crit                                          /var/log/spooler
local7.*                                                /var/log/boot.log

Permitindo conexões remotas ao rSyslog

Edite o arquivo /etc/sysconfig/rsyslog e acresente o parâmetro -r na linha 6

SYSLOGD_OPTIONS="-r -m 0"

Já é possível iniciar o rsyslog para ver se tudo ocorreu bem.

service rsyslog start

Verifique o log /var/log/messages e se tudo foi certo, a mensagem referente ao rsyslog iniciando deve ser como essa, sem erros

Sep 22 18:42:23 master rsyslogd: [origin software="rsyslogd" swVersion="2.0.6" x -pid="2779" x-info="http://www.rsyslog.com"][x-configInfo udpReception="Yes" udp Port="514" tcpReception="No" tcpPort="0"] restart
Sep 22 18:42:23 master kernel: rklogd 2.0.6, log source = /proc/kmsg started.

Instalando e configurando a interface Web para o rSyslog

Com o serviço rsyslog configurado vem a parte necessária da interface Web para consultas e etc.

Baixe o frontend phpLogCon para o computador

wget http://www.virtualxp.org/downloads/phplogcon-2.6.4.tar.gz

Descompacte o arquivo para /usr/src

tar zxvf phplogcon-2.6.4.tar.gz -C /usr/src

Vá ao diretório onde descompactou, no caso o /usr/src/phplogcon-2.6.4 e copie o diretório src para /var/www/html

cp -R src /var/www/html/syslog
cd /var/www/html/syslog
touch config.php
chown apache config.php

Se você não iniciou o apache ainda, pode iniciar agora

service httpd start

Starting httpd:                                            [  OK  ]

Acesse agora, do navegador do seu computador o host http://172.20.32.205/syslog, substitua o endereço para o do seu servidor.

Note o erro, é normal e esperado. Clique em “here” para configurar o phpLogCon

Agora o instalador verificará se o SO tem os pré-requisitos necessários para rodar o programa. Clique em “Next”.

O teste feito foi referente se o phpLogCon tem acesso à escrita no arquivo config.php que criamos e definimos a permissão. Clique em “Next” para prosseguir.

Nas configurações básicas, deixe as oções padrão marcadas e clique em “Next”.

Essa é a tela de configuração mais importante. É nela que será configurado a origem dos dados dos eventos do Syslog.

Mude o campo “Source Type” para “MySQL” e preencha os campos da sessão “Database Type Options” como na figura acima.

Clique em Next.

Pronto! Tudo okie dokie agora!

Clique em “Finish!” e você será direcionado para a tela principal do phpLogCon.

Configurando clientes para logar no servidor rSyslog

Nos clientes Linux / FreeBSD etc, que você quer que os logs sejam enviados ao servidor do rSyslog, você deve configurar o /etc/syslog.conf para essa finalidade. Adicione a seguinte linha:

*.*                   @syslog_server

Onde, “syslog_server” é o hostname ou IP do servidor syslog.

Quando terminar, é necessário reiniciar o serviço do syslog no lado do cliente.

service syslog restart

Esses procedimentos são para Red Hat / CentOS e clientes Linux em geral. Para outros sistemas, deve-se adaptar de acordo.

Deixe um comentário mostrando como foi feito para o seu cliente utilizar essa solução de log centralizado! Será de bastante valor.

Crie o arquivo /etc/iptables/blocked.ips com a lista de IPs ou redes a serem bloqueados.

Como exemplo

192.168.0.0/24
200.122.53.11
74.67.1.213

E o script que será o responsável por carregar as regras.

#!/bin/bash

IPT=`which iptables`
SPAMLIST="spamlist"
SPAMDROPMSG="SPAM LIST DROP"
BADIPS=$(egrep -v -E "^#|^$" /etc/iptables/blocked.ips)

# create a new iptables list
$IPT -N $SPAMLIST

for ipblock in $BADIPS
do
   $IPT -A $SPAMLIST -s $ipblock -j LOG --log-prefix "$SPAMDROPMSG"
   $IPT -A $SPAMLIST -s $ipblock -j DROP
done

$IPT -I INPUT -j $SPAMLIST
$IPT -I OUTPUT -j $SPAMLIST
$IPT -I FORWARD -j $SPAMLIST

Com um sistema estável e rodando por um longo período você apenas deseja fazer a atualização de programas que são conhecidamente vulneráveis, ou seja, quer saber como fazer apenas atualizações de segurança sem atualizar todo o sistema operacional.

Irei mostrar aqui como proceder para apenas atualizar os pacotes vulneráveis, sem tocar em outros que são conhecidamente estáveis.

É possível instalar para o Yum um plugin que cuida disso, lista e atualiza pacotes que contenham BUGs, CVE (Common Vulnerabilities Exposure) ou problemas de funcionamento.

Pré-requisitos

• Instalação mínima do CentOS e RedHat 5.3

Instalando o Plugin

Execute o seguinte comando

yum install yum-security

Listando as atualizações de segurança disponíveis

Com o comando yum list-security o Yum mostrará uma lista com os programas que possuem atualizações disponíveis

yum list-security

Note que ao executar o Yum, logo abaixo ele mostra quais plugins estão sendo carregados em tempo de execução:

Loaded plugins: fastestmirror, security

Para listar todas as atualizações de segurança relevantes e ter um retorno sobre onde há atualizações, use o comando

yum --security check-update

Se tudo estiver OK, o retorno será parecido com esse

Limiting package lists to security relevant ones
No packages needed, for security, 40 available

Pra ter uma lista de todos os pacotes com BUGs corrigidos e que você tem instalado no seu sistema, execute o comando

yum list-security bugzillas

Atualizando todos os pacotes vulneráveis/com BUGs

Já que o objetivo é realmente ter o SO livre de BUGs e CVEs, nada mais justo que atualizar todos os pacotes vulneráveis.

yum update --security

Usuários Linux e administradores de sistema frequentemente não possuem um foco geral em alterações do SO, logs e rastreamento do que foi feito em uma invasão.

Não tem como começar a falar sobre segurança a nível de “Layers” (camada OSI) sem entrar no assunto IDS, no caso a ferramenta mais conhecida: Snort.

http://www.fogonacaixadagua.com.br/2y7 [Configurando e instalando Snort, em inglês]

Nem sempre o Snort vê todos os possíveis exploits de segurança. Enquanto ele testa tráfego de pacotes em camadas superiores da OSI, ele não detectará Backdoors e rootkits. Também não detectará acesso shell ou SSH de usuários descontentes, usuários não autorizados nem outros administradores ou usuários comuns.

Keyloggers

A recomendação do CERT é que qualquer servidor suspeito seja refeito, mas geralmente os administratores não conseguem obter provas de tal fato.

http://www.cert.org/tech_tips/win-UNIX-system_compromise.html

Os keyloggers mais utilizados no Linux incluem:

a) nível do PAM

Enquanto modificações no PAM é um assunto muito abrangente e merece um tópico só sobre ele, vários keyloggers podem ser utilizados usando o PAM. O utilitário “rootsh” é uma solução  bastante interessante.

rootsh [http://freshmeat.net/projects/rootsh/]

Rootsh is a wrapper for shells that logs all echoed keystrokes and terminal output to a file and/or to syslog. Its main purpose is the auditing of users who need a shell with root privileges. They start rootsh through the sudo mechanism.

Quais os benefícios de se usar o rootsh ao invés de script(1)?

Porque script(1):

• não envia entrada/saída para um servidor syslog
• não pode ser usado como login shell
• não detecta interferências no arquivo de log
• não pode ser restrito a apenas alguns comandos

Permite que você habilite um logger a nível de sistema que mostrará tudo o que for digitado no terminal independente se o usuário use o comando `sudo` ou logue-se normalmente.

“rootsh” é extremamente útil, especialmente se você possui mais de um sysadmin ou usuário root  (a recomendação é que você sempre desabilite completamente o acesso do usuário root e utilizar o ‘sudo’)

Por padrão, o programa “rootsh” grava os logs em /var/log/rootsh (pode ser alterado durante a configuração). Claro que os logs podem ser editados, como qualquer arquivo log, ao menos que você utilize uma opção de logs centralizado com syslogd ou syslog-ng.

b) Keylogger a nível do kernel

Sebek is kernel module installed on high-interaction honeypots for the purpose of extensive data collection. It allows administrators to collect activities such as keystrokes on the system, even in encrypted environments. Designed primarily for Win32 and Linux systems.

https://projects.honeynet.org/sebek/

Sebek é um módulo para o kernel que tembém está disponível para Windows.

http://www.honeynet.org.pt/index.php/HoneyMole

c) Hardware keyloggers

Estes mascaram USB-to-PCI e são geralmente colocados juntos a KVMs.

http://www.keelog.com/download.html

Ficam entre o teclado e a interface onde o teclado está conectado, sendo praticamente impossível detectar via software. Armazenam os dados digitados pelo teclado que podem ser baixados outra hora para verificação.

Essa versão do artigo irá cobrir FreeBSD versões 6.x e 7.x, uma outra será feita para Red Hat e CentOS com geração dos RPMs para as plataformas.

• Samba com Antivírus ClamAV no Red Hat / CentOS

Instalando o Clamav

No FreeBSD, instalar o Clamav é recomendável fazer pelo ports mesmo, forma mais tranquila de instalar.

cd /usr/ports/security/clamav
make config

Deixar as opções selecionadas como na imagem.

Instalar o clamav:

make install

Após a instalação, editar o arquivo /usr/local/etc/freshclam.conf e comentar a linha onde lê-se: Example

O arquivo /usr/local/etc/freshclam.conf terá como conteúdo algo parecido com o seguinte, caso seu ambiente seja diferente, adapte-o de acordo com as suas necessidades.

Arquivo /usr/local/etc/freshclam.conf

DatabaseDirectory /var/db/clamav
UpdateLogFile /var/log/freshclam.log
LogTime yes
LogSyslog yes
PidFile /var/run/clamd/freshclam.pid
DatabaseOwner clamav
DNSDatabaseInfo current.cvd.clamav.net
DatabaseMirror db.br.clamav.net
DatabaseMirror database.clamav.net
NotifyClamd /usr/local/etc/clamd.conf
SubmitDetectionStats /usr/local/etc/clamd.conf
DetectionStatsCountry BR

O mesmo aplica-se ao arquivo /usr/local/etc/clamd.conf

Arquivo /usr/local/etc/clamd.conf

LogFileMaxSize 2M
LogTime yes
LogSyslog yes
LogFile /var/log/clamd.log
PidFile /var/run/clamd/clamd.pid
LocalSocket /tmp/clamd.socket
TCPSocket 3310
TCPAddr 127.0.0.1
User clamav
ScanPE yes
ScanELF yes
DetectBrokenExecutables yes
ScanOLE2 yes
ScanPDF yes
ScanMail yes
MailFollowURLs no
ScanPartialMessages yes
PhishingSignatures yes
PhishingScanURLs yes
PhishingAlwaysBlockSSLMismatch no
PhishingAlwaysBlockCloak no
HeuristicScanPrecedence yes
ScanHTML yes
ScanArchive yes

Acrescentar as seguintes linhas ao arquivo /etc/rc.conf:

clamav_clamd_enable="YES"
clamav_freshclam_enable="YES"

Criar os arquivos de log e definir permissões corretas

touch /var/log/clamd.log /var/log/freshclam.log
chown clamav:clamav /var/log/clamd.log /var/log/freshclam.log
mkdir -p /var/run/clamd
chown clamav:clamav /var/run/clamd

Após a configuração, iniciar o clamd e fazer a atualização da base de vírus.

/usr/local/etc/rc.d/clamav-clamd start
freshclam

Instalando o Samba 3

Baixando o código fonte

É realmente necessário recompilar o samba para ter a funcionalidade do vscan, pois somente com os binários ele não irá compilar.

Não testei com outra versão, portanto não sei da estabilidade/funcionalidade, aqui utilizarei a versão 3.0.34 do samba.

cd ~
fetch http://download.samba.org/samba/ftp/stable/samba-3.0.34.tar.gz
tar zxvf samba-3.0.34.tar.gz -C /usr/src
cd /usr/src/samba-3.0.34/source
./configure
gmake proto
gmake
gmake install

O samba será instalado por padrão no diretório /usr/local/samba.

Desabilitando o samba atual (instalado pelo ports [se houver])

Se você possui o samba instalado hoje pelo ports deverá desativá-lo e desabilitá-lo da inicialização automática, defina o parâmetro de inicialização de cada daemon como “NO”:

samba_enable="NO"

ou as linhas

nmbd_enable="NO"
smbd_enable="NO"
winbindd_enable="NO"

do arquivo /etc/rc.conf

Se desejar desinstalar definitivamente o samba do servidor, basta entrar no ports /usr/ports/net/samba3 e executar o comando

make deinstall

Fazer o download do vscan

cd ~
fetch http://www.openantivirus.org/download/samba-vscan-0.3.6c-beta5.tar.gz
tar zxvf samba-vscan-0.3.6c-beta5.tar.gz -C /usr/src/samba-3.0.34/examples/VFS
cd /usr/src/samba-3.0.34/examples/VFS/samba-vscan-0.3.6c-beta5

Compilar e instalar

./configure
gmake clamav
cp vscan-clamav.so /usr/local/samba/lib/vfs
cp clamav/vscan-clamav.conf /usr/local/etc

O conteúdo do arquivo /usr/local/etc/vscan-clamav.conf deverá parecer com o seguinte:

Arquivo /usr/local/etc/vscan-clamav.conf

[samba-vscan]
max file size = 0
verbose file logging = no
scan on open = yes
scan on close = yes
deny access on error = yes
deny access on minor error = yes
send warning message = yes
infected file action = delete
quarantine directory = /tmp
quarantine prefix = vir-
max lru files entries = 100
lru file entry lifetime = 5
exclude file types =
exclude file regexp =
clamd socket name = /tmp/clamd.socket
libclamav max files in archive = 1000
libclamav max archived file size = 10485760

A linha

infected file action = delete

refere-se a ação a ser tomada caso um vírus seja encontrado, a ação padrão é não fazer nada, o recomendável é colocar em “quarantine” ou “delete”.

Configurar o Samba para utilizar o vscan

É possível utilizar o vscan a nível de compartilhamento e global, para tanto, basta colocar as seguintes linhas onde quer utilizar o vscan, se for global não há necessidade de colocar nos compartilhamentos.

Arquivo /usr/local/etc/smb.conf

vfs object = vscan-clamav
vscan-clamav: config-file = /usr/local/etc/vscan-clamav.conf

Iniciando o samba

O samba deverá ser iniciado agora na linha de comando e na inicialização pode ser no arquivo /etc/rc.local

/usr/local/samba/sbin/smbd -D -s /usr/local/etc/smb.conf
/usr/local/samba/sbin/nmbd -D -s /usr/local/etc/smb.conf

Através do log /var/log/messages é possível acompanhar o funcionamento do vscan.