Instalação do ClamAV com DazukoFS
O ClamAV é um dos mais conhecidos antivírus desenvolvidos para Linux. Nesse tutorial vamos compilar, instalar e configurar o ClamAV. Além disso, vamos configurar sua proteção residente para utilizar o DazukoFS.
[ Hits: 52.747 ]
Por: Antônio Vinícius Menezes Medeiros em 06/01/2010 | Blog: https://antoniomedeiros.dev/
Configurando o clamav-milter
O clamav-milter é o componente do ClamAV que se integra aos servidores de e-mail, verificando a existência de vírus nos anexos.
Sua configuração encontra-se no arquivo /etc/clamav/clamav-milter.conf. Abra esse arquivo e faça as alterações listadas a seguir (se você preferir, aqui encontra-se uma cópia desse arquivo com as alterações já feitas):
1. Comente a linha "Example":
2. Descomente a linha "MilterSocket" e altere seu valor:
4. Adicione a linha "ClamdSocket":
5. Descomente a linha "LogFile" e altere seu valor:
6. Descomente a linha "LogFileMaxSize":
7. Descomente a linha "LogTime":
8. Descomente a linha "LogSyslog":
9. Descomente a linha "LogVerbose":
Finalmente, execute o comando a seguir para verificar se as alterações na configuração foram aplicadas:
# clamav-milter
Sua configuração encontra-se no arquivo /etc/clamav/clamav-milter.conf. Abra esse arquivo e faça as alterações listadas a seguir (se você preferir, aqui encontra-se uma cópia desse arquivo com as alterações já feitas):
1. Comente a linha "Example":
# Comment or remove the line below.
#Example
#Example
2. Descomente a linha "MilterSocket" e altere seu valor:
# Define the interface through which we communicate with sendmail
# This option is mandatory! Possible formats are:
# [[unix|local]:]/path/to/file - to specify a unix domain socket
# inet:port@[hostname|ip-address] - to specify an ipv4 socket
# inet6:port@[hostname|ip-address] - to specify an ipv6 socket
#
# Default: no default
MilterSocket /var/run/clamav/clamav-milter.socket
#MilterSocket inet:7357
3. Descomente a linha "PidFile" e altere seu valor:
# This option is mandatory! Possible formats are:
# [[unix|local]:]/path/to/file - to specify a unix domain socket
# inet:port@[hostname|ip-address] - to specify an ipv4 socket
# inet6:port@[hostname|ip-address] - to specify an ipv6 socket
#
# Default: no default
MilterSocket /var/run/clamav/clamav-milter.socket
#MilterSocket inet:7357
# This option allows you to save a process identifier of the listening
# daemon (main thread).
#
# Default: disabled
PidFile /var/run/clamav/clamav-milter.pid
# daemon (main thread).
#
# Default: disabled
PidFile /var/run/clamav/clamav-milter.pid
4. Adicione a linha "ClamdSocket":
# Define the clamd socket to connect to for scanning.
# This option is mandatory! Syntax:
# ClamdSocket unix:path
# ClamdSocket tcp:host:port
# The first syntax specifies a local unix socket (needs an absolute path) e.g.:
# ClamdSocket unix:/var/run/clamd/clamd.socket
# The second syntax specifies a tcp local or remote tcp socket: the
# host can be a hostname or an ip address; the ":port" field is only required
# for IPv6 addresses, otherwise it defaults to 3310
# ClamdSocket tcp:192.168.0.1
#
# This option can be repeated several times with different sockets or even
# with the same socket: clamd servers will be selected in a round-robin fashion.
#
# Default: no default
#ClamdSocket tcp:scanner.mydomain:7357
ClamdSocket /var/run/clamav/clamd.socket
# This option is mandatory! Syntax:
# ClamdSocket unix:path
# ClamdSocket tcp:host:port
# The first syntax specifies a local unix socket (needs an absolute path) e.g.:
# ClamdSocket unix:/var/run/clamd/clamd.socket
# The second syntax specifies a tcp local or remote tcp socket: the
# host can be a hostname or an ip address; the ":port" field is only required
# for IPv6 addresses, otherwise it defaults to 3310
# ClamdSocket tcp:192.168.0.1
#
# This option can be repeated several times with different sockets or even
# with the same socket: clamd servers will be selected in a round-robin fashion.
#
# Default: no default
#ClamdSocket tcp:scanner.mydomain:7357
ClamdSocket /var/run/clamav/clamd.socket
5. Descomente a linha "LogFile" e altere seu valor:
# Uncomment this option to enable logging.
# LogFile must be writable for the user running daemon.
# A full path is required.
#
# Default: disabled
LogFile /var/log/clamav/clamav-milter.log
# LogFile must be writable for the user running daemon.
# A full path is required.
#
# Default: disabled
LogFile /var/log/clamav/clamav-milter.log
6. Descomente a linha "LogFileMaxSize":
# Maximum size of the log file.
# Value of 0 disables the limit.
# You may use 'M' or 'm' for megabytes (1M = 1m = 1048576 bytes)
# and 'K' or 'k' for kilobytes (1K = 1k = 1024 bytes). To specify the size
# in bytes just don't use modifiers.
#
# Default: 1M
LogFileMaxSize 2M
# Value of 0 disables the limit.
# You may use 'M' or 'm' for megabytes (1M = 1m = 1048576 bytes)
# and 'K' or 'k' for kilobytes (1K = 1k = 1024 bytes). To specify the size
# in bytes just don't use modifiers.
#
# Default: 1M
LogFileMaxSize 2M
7. Descomente a linha "LogTime":
# Log time with each message.
#
# Default: no
LogTime yes
#
# Default: no
LogTime yes
8. Descomente a linha "LogSyslog":
# Use system logger (can work together with LogFile).
#
# Default: no
LogSyslog yes
#
# Default: no
LogSyslog yes
9. Descomente a linha "LogVerbose":
# Enable verbose logging.
#
# Default: no
LogVerbose yes
#
# Default: no
LogVerbose yes
Finalmente, execute o comando a seguir para verificar se as alterações na configuração foram aplicadas:
# clamav-milter
Páginas do artigo
1. Introdução2. Instalando o ClamAV
3. Configurando o freshclam
4. Configurando o clamd
5. Configurando o clamav-milter
6. Executando o ClamAV na inicialização do sistema
7. Testando o ClamAV
Outros artigos deste autor
Guia de referência do ISOLINUX (parte 2)
Incrementando o visual do KDE 4
Criando um LiveCD a partir de uma instalação do Debian Lenny
VirtualBox: a forma mais fácil de conhecer o Linux sem precisar instalá-lo
Conheça o OpenOffice.org e o BrOffice.org
Leitura recomendada
Instalação do Snort + BASE no Debian Etch pelos fontes
Autenticação via hardware: o módulo pam_usb
YASG (Yet Another Security Guide)
Recon and Scan with Metasploit
Comentários
[1] Comentário enviado por overlock em 14/01/2010 - 12:26h
Opa amigo. Ótimo Post...
Por acaso rola alguma chance de fazer isso com o ClamWin?? Abraços.
Opa amigo. Ótimo Post...
Por acaso rola alguma chance de fazer isso com o ClamWin?? Abraços.
[2] Comentário enviado por vinyanalista em 16/01/2010 - 09:24h
Infelizmente, meu caro, não há uma versão do DazukoFS para Windows. Ele é desenvolvido apenas para Linux, até porque se você for ver direitinho não há necessidade de se utilizar um DazukoFS no Windows.
Explico:
Os antivírus necessitam monitorar o acesso aos arquivos para que possam executar a famosa proteção residente.
No Linux, quem poderia fornecer essas informações aos antivírus seria o kernel, que está lidando diretamente com os programas e os arquivos. Acontece que ele não disponibiliza por si só essas informações aos aplicativos (desconheço o motivo, mas acredito que seja por questões de segurança), e era muito difícil desenvolver um antivírus para Linux que executasse tal monitoramento. Isso fez com que muitos desenvolvedores inclusive desistirem de implementar proteção residente em seus antivírus.
Por isso que foi desenvolvido o DazukoFS, um módulo que se integra ao kernel e resolve esse problema dos antivírus, permitindo a eles saber quais arquivos estão sendo acessados, por qual aplicativo e por qual usuário estão sendo acessados e permitir ou negar o acesso ao arquivo.
No Windows, vemos que todos os antivírus hoje possuem proteção residente sem precisar de nenhum recurso especial para oferecê-la. Aliás, mesmo os mais antigos já possuíam (eu utilizo Windows há pelo menos 8 anos). Então chegamos à conclusão que o próprio sistema fornece aos antivírus informações sobre o acesso aos arquivos. Por isso não houve necessidade de se desenvolver um artifício como o DazukoFS para o Windows.
O ClamWin poderia executar proteção residente utilizando os recursos que o próprio Windows oferece. Acredito que falta um pouco de pesquisa da parte de seus desenvolvedores em como implementar esse recurso.
E não digo isso sem base, digo por experiência própria: eu já desenvolvi em Delphi um aplicativo que intercepta o uso do teclado e o logon/logoff de usuários do sistema. Se há funções do Windows que permitem fazer isso, também devem haver funções que permitam interceptar o acesso aos arquivos.
Resumindo, acredito que no caso do ClamWin a solução do problema da proteção residente não esteja nas mãos do usuário, mas nas mãos dos desenvolvedores. Resta a nós esperarmos que eles implementem esse recurso ou, como se trata de código-aberto, ajudá-los a fazer isso, se tivermos conhecimento para tal.
Obrigado pelo interesse no meu artigo e até a próxima!
Infelizmente, meu caro, não há uma versão do DazukoFS para Windows. Ele é desenvolvido apenas para Linux, até porque se você for ver direitinho não há necessidade de se utilizar um DazukoFS no Windows.
Explico:
Os antivírus necessitam monitorar o acesso aos arquivos para que possam executar a famosa proteção residente.
No Linux, quem poderia fornecer essas informações aos antivírus seria o kernel, que está lidando diretamente com os programas e os arquivos. Acontece que ele não disponibiliza por si só essas informações aos aplicativos (desconheço o motivo, mas acredito que seja por questões de segurança), e era muito difícil desenvolver um antivírus para Linux que executasse tal monitoramento. Isso fez com que muitos desenvolvedores inclusive desistirem de implementar proteção residente em seus antivírus.
Por isso que foi desenvolvido o DazukoFS, um módulo que se integra ao kernel e resolve esse problema dos antivírus, permitindo a eles saber quais arquivos estão sendo acessados, por qual aplicativo e por qual usuário estão sendo acessados e permitir ou negar o acesso ao arquivo.
No Windows, vemos que todos os antivírus hoje possuem proteção residente sem precisar de nenhum recurso especial para oferecê-la. Aliás, mesmo os mais antigos já possuíam (eu utilizo Windows há pelo menos 8 anos). Então chegamos à conclusão que o próprio sistema fornece aos antivírus informações sobre o acesso aos arquivos. Por isso não houve necessidade de se desenvolver um artifício como o DazukoFS para o Windows.
O ClamWin poderia executar proteção residente utilizando os recursos que o próprio Windows oferece. Acredito que falta um pouco de pesquisa da parte de seus desenvolvedores em como implementar esse recurso.
E não digo isso sem base, digo por experiência própria: eu já desenvolvi em Delphi um aplicativo que intercepta o uso do teclado e o logon/logoff de usuários do sistema. Se há funções do Windows que permitem fazer isso, também devem haver funções que permitam interceptar o acesso aos arquivos.
Resumindo, acredito que no caso do ClamWin a solução do problema da proteção residente não esteja nas mãos do usuário, mas nas mãos dos desenvolvedores. Resta a nós esperarmos que eles implementem esse recurso ou, como se trata de código-aberto, ajudá-los a fazer isso, se tivermos conhecimento para tal.
Obrigado pelo interesse no meu artigo e até a próxima!
[3] Comentário enviado por magnolinux em 29/01/2010 - 11:11h
Primeiramente meus parabens seu artigo está muito bom.
Agora la vai algumas duvidas.
1º Qual a diferença entre o clamdscan e o clamscan????
2º Se eu executar automaticamente o freshclam -d ele fara as atualizações automaticamente.??
3º O clamdscan tem alguma funcionalidade se nao for em modo residente.???
Obrigado ....
aguardo as respostas..
abraço..
Primeiramente meus parabens seu artigo está muito bom.
Agora la vai algumas duvidas.
1º Qual a diferença entre o clamdscan e o clamscan????
2º Se eu executar automaticamente o freshclam -d ele fara as atualizações automaticamente.??
3º O clamdscan tem alguma funcionalidade se nao for em modo residente.???
Obrigado ....
aguardo as respostas..
abraço..
[4] Comentário enviado por vinyanalista em 30/01/2010 - 00:24h
Olá magnolinux. Que bom que você gostou do meu artigo.
Respondendo suas dúvidas:
1ª - Tanto o clamdscan quanto o clamscan são utilitários do ClamAV que podem ser usados para verificar a existência de vírus nos arquivos e quase todos os parâmetros de um podem ser usados também no outro. A diferença principal entre eles consiste na base de dados que eles utilizam: enquanto o clamscan carrega a base de dados do disco rígido, o clamdscan utiliza a base de dados que já está na memória e está sendo utilizada pelo clamd. Logo, o clamdscan é mais rápido que o clamscan, pois não necessita carregar a base de dados toda vez em que é executado. Outra diferença importante é que o clamdscan necessita que o clamd esteja em execução, enquanto o clamscan dispensa essa preocupação.
2ª - O parâmetro -d que você passa para o freshclam ordena que ele seja executado como daemon. Isso quer dizer que ele ficará permanentemente em execução na memória. Logo, ele verificará por atualizações automaticamente sim. Executando esse comando automaticamente durante a inicialização do sistema, você não precisará mais se preocupar com as atualizações do ClamAV. Você pode inclusive configurar quantas vezes ele procura por atualizações na Internet (o padrão é doze vezes por dia, ou seja, a cada duas horas), descomentando a linha Checks do arquivo de configuração do freshclam ("/etc/clamav/freshclam.conf") e alterando seu valor, informando quantas vezes por dia devem ser procuradas novas atualizações:
# Number of database checks per day.
# Default: 12 (every two hours)
Checks 24
3ª - Acho que a resposta à primeira dúvida já esclareceu em parte a terceira. Se você tentar executar o clamdscan sem ter iniciado o clamd antes, você receberá uma mensagem de erro. Diferente do clamdscan, o clamscan é independente do clamd. Você pode utilizá-lo para scanear os arquivos quando o clamd não estiver em execução.
Espero que tenha ajudado.
Um abraço e até a próxima!
Olá magnolinux. Que bom que você gostou do meu artigo.
Respondendo suas dúvidas:
1ª - Tanto o clamdscan quanto o clamscan são utilitários do ClamAV que podem ser usados para verificar a existência de vírus nos arquivos e quase todos os parâmetros de um podem ser usados também no outro. A diferença principal entre eles consiste na base de dados que eles utilizam: enquanto o clamscan carrega a base de dados do disco rígido, o clamdscan utiliza a base de dados que já está na memória e está sendo utilizada pelo clamd. Logo, o clamdscan é mais rápido que o clamscan, pois não necessita carregar a base de dados toda vez em que é executado. Outra diferença importante é que o clamdscan necessita que o clamd esteja em execução, enquanto o clamscan dispensa essa preocupação.
2ª - O parâmetro -d que você passa para o freshclam ordena que ele seja executado como daemon. Isso quer dizer que ele ficará permanentemente em execução na memória. Logo, ele verificará por atualizações automaticamente sim. Executando esse comando automaticamente durante a inicialização do sistema, você não precisará mais se preocupar com as atualizações do ClamAV. Você pode inclusive configurar quantas vezes ele procura por atualizações na Internet (o padrão é doze vezes por dia, ou seja, a cada duas horas), descomentando a linha Checks do arquivo de configuração do freshclam ("/etc/clamav/freshclam.conf") e alterando seu valor, informando quantas vezes por dia devem ser procuradas novas atualizações:
# Number of database checks per day.
# Default: 12 (every two hours)
Checks 24
3ª - Acho que a resposta à primeira dúvida já esclareceu em parte a terceira. Se você tentar executar o clamdscan sem ter iniciado o clamd antes, você receberá uma mensagem de erro. Diferente do clamdscan, o clamscan é independente do clamd. Você pode utilizá-lo para scanear os arquivos quando o clamd não estiver em execução.
Espero que tenha ajudado.
Um abraço e até a próxima!
[5] Comentário enviado por magnolinux em 01/02/2010 - 09:22h
Muito obrigado amigo, realmente suas respostas ajudaram muito..
Uma outra duvida é a seguinte o clamscan utiliza o arquivo de conf clamd.conf????
Muito obrigado amigo, realmente suas respostas ajudaram muito..
Uma outra duvida é a seguinte o clamscan utiliza o arquivo de conf clamd.conf????
[6] Comentário enviado por ale_oliveira em 03/03/2011 - 22:10h
Ola estive lendo sobre o post e gostaria de perguntar se é possivel remover um virus como o nome win32 sality.y do meu servidor de dados.
Valeu
Ola estive lendo sobre o post e gostaria de perguntar se é possivel remover um virus como o nome win32 sality.y do meu servidor de dados.
Valeu
[7] Comentário enviado por imacedo em 20/03/2011 - 19:36h
Boa tarde senhores. é a primeira vez que instalo o clamav e a questao é a seguinte fiz o teste e me retornou essa msg, isso esta correto??? e qdo eu scaneio novamente ele diz q tem 1 arq infectado de novo; ele nao tinha que excluir esse arquivo como vou saber se realmente esta paralizado o virus??? é possivel excluir o arquivo infectado durante o escaneamento? e como faco pra excluir os arquivos infectador? Desde já agradeco
root@testmail:~# clamscan eicar.com
LibClamAV Warning: zlib version at runtime is older than compile time: 1.2.3 < 1.2.3.3
LibClamAV info: Make sure zlib is built as shared library, and that the new zlib library is installed in the proper place
eicar.com: Eicar-Test-Signature FOUND
----------- SCAN SUMMARY -----------
Known viruses: 919816
Engine version: 0.97
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 5.614 sec (0 m 5 s)
root@testmail:~#
Boa tarde senhores. é a primeira vez que instalo o clamav e a questao é a seguinte fiz o teste e me retornou essa msg, isso esta correto??? e qdo eu scaneio novamente ele diz q tem 1 arq infectado de novo; ele nao tinha que excluir esse arquivo como vou saber se realmente esta paralizado o virus??? é possivel excluir o arquivo infectado durante o escaneamento? e como faco pra excluir os arquivos infectador? Desde já agradeco
root@testmail:~# clamscan eicar.com
LibClamAV Warning: zlib version at runtime is older than compile time: 1.2.3 < 1.2.3.3
LibClamAV info: Make sure zlib is built as shared library, and that the new zlib library is installed in the proper place
eicar.com: Eicar-Test-Signature FOUND
----------- SCAN SUMMARY -----------
Known viruses: 919816
Engine version: 0.97
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 5.614 sec (0 m 5 s)
root@testmail:~#
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Como gerar um podcast a partir de um livro em PDF
Automatizando digitação de códigos 2FA no browser
Resolver problemas de Internet
Como compartilhar a tela do Ubuntu com uma Smart TV (LG, Samsung, etc.)
Dicas
Conheça a 4Devs, caixa de ferramentas online para desenvolvedores
Como converter um vídeo MP4 para um GIF para publicar no README.md do seu repositório Github
Como Instalar o Microsoft Teams no Linux Ubuntu
Tópicos
Top 10 do mês
-
Xerxes
1° lugar - 72.151 pts -
Fábio Berbert de Paula
2° lugar - 57.651 pts -
Buckminster
3° lugar - 18.830 pts -
Mauricio Ferrari
4° lugar - 17.672 pts -
Alberto Federman Neto.
5° lugar - 15.009 pts -
Daniel Lara Souza
6° lugar - 13.907 pts -
edps
7° lugar - 13.535 pts -
Diego Mendes Rodrigues
8° lugar - 13.273 pts -
Alessandro de Oliveira Faria (A.K.A. CABELO)
9° lugar - 13.078 pts -
Andre (pinduvoz)
10° lugar - 10.409 pts
Scripts
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
