Este tutorial foi escrito com o intuito de ajudar os administradores de
sistema a fazerem a auditoria dos logs do sistema , pe?a chave para a
seguran?a de uma rede.
PREVIA SOBRE O LOGCHECK
O logcheck ? um software de auditoria de log para sistemas UNIX . Esse
software desenvolvido pela Psionic Software , analisa e informa atrav?s
do e-mail , o que est? acontecendo no seu sistema , tentado alertar para
uma poss?vel invas?o.
O logcheck ainda pode ser usado para trabalhar junto com o PortSentry ,
um ?timo software IDS (Intrusion Detection System) , ent?o , eu aconselharia
vc instalar e configurar o PortSentry.
Veja os Sistemas que suportam o Logcheck:
? Linux
? SunOS
? Solaris
? HPUX
? Digital OSF/1
? FreeBSD
? BSDI
? OpenBSD
? NetBSD
? Generic (Most variants)
INSTALA??O
A primeira coisa a fazer ? adquirir o software , para isso v? at?
http://www.psionic.com/tools/logcheck-1.1.1.tar.gz ou ent?o procure
no CD-ROM do FreeBSD na parte Security dos packages .
No meu caso , tenho o logcheck no CD-ROM do FreeBSD 4.1.1-Release . Para
instalar o logcheck pelo cd vc pode usar o sysinstall em /stand .
Depois de ter instalado verifique se foi criado os seguintes arquivos , por
padr?o eles ca?ram em /usr/local/etc :
Logcheck.hacking.sample
Logcheck.ignore.sample
Logcheck.sh
Logcheck.violations.ignore.sample
Logcheck.violations.sample
Se todos esses arquivos estiverem forem criados, o software foi instalado
sem problemas.
VEJAMOS O QUE SIGNIFICA CADA UM DESSES ARQUIVOS
Logcheck.hacking ? Este arquivo cont?m keywords que caracterizariam um poss?vel
ataque ao seu sistema , essas keywords geralmente ocorrem quando se ? atacado
por um Port Scanner ou quando se usa sintaxes ilegais no Sendmail.
Logcheck.ignore ? Este arquivo faria quase que o contr?rio do logcheck.hacking,
ele negaria certos alertas , como conex?es com o deamon telnetd.
Logcheck.violations ? Este arquivo cont?m keywords gerados pelo sistema , tanto
negativas como positivas . ex: Denied , Refused.
Logcheck.violations.ignore ? Como o nome j? diz , este ? o arquivo que ignora
certas mensagens geradas pelo sistema
Logcheck.sh ? Esse aqui seria o script de inicializa??o do logcheck.
Eu n?o aconselharia editar esses arquivos , a n?o ser o logcheck.sh , pois
dependendo das regras que voc? adicionar ou retirar , o logcheck pode vir a
dar falsos avisos , o que n?o ? interessante.
Lembre -se de renomear todos os arquivos exceto , o logcheck.sh , retire a parte
.sample dos arquivos , sendo assim eles passaram a fazer parte da configura??o
do logcheck:
mv logcheck.ignore.sample logcheck.ignore
mv logcheck.hacking.sample logcheck.hacking
mv logcheck.violations.ignore.sample logcheck.violations.ignore
mv logcheck.violations.sample logcheck.violations
Feito isso podemos passar para nosso arquivo de configura??o
ARQUIVO DE CONFIGURA??O ----- LOGCHECK.SH---------
Esse arquivo como j? foi dito , ? o script de inicializa??o do nosso utilit?rio,
na verdade ser?o poucas altera??es que teremos que fazer , colocarei a parte deste
script que teremos que configurar .
------------------------------logcheck.sh-----------------------
#!/bin/sh
#
# logcheck.sh: Log file checker
# Written by Craig Rowland
#
# This file needs the program logtail.c to run
#
# This script checks logs for unusual activity and blatant
# attempts at hacking. All items are mailed to administrators
# for review. This script and the logtail.c program are based upon
# the frequentcheck.sh script idea from the Gauntlet(tm) Firewall
# (c)Trusted Information Systems Inc. The original authors are
# Marcus J. Ranum and Fred Avolio.
#
# Default search files are tuned towards the TIS Firewall toolkit
# the TCP Wrapper program. Custom daemons and reporting facilites
# can be accounted for as well...read the rest of the script for
# details.
#
# Version Information
#
# 1.0 9/29/96 -- Initial Release
# 1.01 11/01/96 -- Added working /tmp directory for symlink protection
# (Thanks Richard Bullington ([email protected])
# 1.1 1/03/97 -- Made this script more portable for Sun's.
# 1/03/97 -- Made this script work on HPUX
# 5/14/97 -- Added Digital OSF/1 logging support. Big thanks
# to Jay Vassos-Libove for
# his changes.
# CONFIGURATION SECTION
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/ucb:/usr/local/bin
# Logcheck is pre-configured to work on most BSD like systems, however it
# is a rather dumb program and may need some help to work on other
# systems. Please check the following command paths to ensure they are
# correct.
# Person to send log activity to.
SYSADMIN=root
# Full path to logtail program.
# This program is required to run this script and comes with the package.
LOGTAIL=/usr/local/bin/logtail
# Full path to SECURED (non public writable) /tmp directory.
# Prevents Race condition and potential symlink problems. I highly
# recommend you do NOT make this a publically writable/readable directory.
# You would also be well advised to make sure all your system/cron scripts
# use this directory for their "scratch" area.
TMPDIR=/usr/local/etc/tmp
# The 'grep' command. This command MUST support the
# '-i' '-v' and '-f' flags!! The GNU grep does this by default (that's
# good GNUs for you Linux/FreeBSD/BSDI people :) ). The Sun grep I'm told
# does not support these switches, but the 'egrep' command does (Thanks
# Jason ). Since grep and egrep are usually the GNU
# variety on most systems (well most Linux, FreeBSD, BSDI, etc) and just
# hard links to each other we'll just specify egrep here. Change this if
# you get errors.
# Linux, FreeBSD, BSDI, Sun, HPUX, etc.
GREP=egrep
# The 'mail' command. Most systems this should be OK to leave as is.
# If your default mail command does not support the '-s' (subject) command
# line switch you will need to change this command one one that does.
# The only system I've seen this to be a problem on are HPUX boxes.
# Naturally, the HPUX is so superior to the rest of UNIX OS's that they
# feel they need to do everything differently to remind the rest that
# they are the best ;).
# Linux, FreeBSD, BSDI, Sun, etc.
MAIL=mail
# HPUX 10.x and others(?)
#MAIL=mailx
# Digital OSF/1, Irix
#MAIL=Mail
# File of known active hacking attack messages to look for.
# Only put messages in here if you are sure they won't cause
# false alarms. This is a rather generic way of checking for
# malicious activity and can be inaccurate unless you know
# what past hacking activity looks like. The default is to
# look for generic ISS probes (who the hell else looks for
# "WIZ" besides ISS?), and obvious sendmail attacks/probes.
HACKING_FILE=/usr/local/etc/logcheck.hacking
# File of security violation patterns to specifically look for.
# This file should contain keywords of information administrators should
# probably be aware of. May or may not cause false alarms sometimes.
# Generally, anything that is "negative" is put in this file. It may miss
# some items, but these will be caught by the next check. Move suspicious
# items into this file to have them reported regularly.
VIOLATIONS_FILE=/usr/local/etc/logcheck.violations
# File that contains more complete sentences that have keywords from
# the violations file. These keywords are normal and are not cause for
# concern but could cause a false alarm. An example of this is the word
# "refused" which is often reported by sendmail if a message cannot be
# delivered or can be a more serious security violation of a system
# attaching to illegal ports. Obviously you would put the sendmail
# warning as part of this file. Use your judgement before putting words
# in here or you can miss really important events. The default is to leave
# this file with only a couple entries. DO NOT LEAVE THE FILE EMPTY. Some
# grep's will assume that an EMPTY file means a wildcard and will ignore
# everything! The basic configuration allows for the more frequent sendmail
# error.
#
# Again, be careful what you put in here and DO NOT LEAVE IT EMPTY!
VIOLATIONS_IGNORE_FILE=/usr/local/etc/logcheck.violations.ignore
# This is the name of a file that contains patterns that we should
# ignore if found in a log file. If you have repeated false alarms
# or want specific errors ignored, you should put them in here.
# Once again, be as specific as possible, and go easy on the wildcards
IGNORE_FILE=/usr/local/etc/logcheck.ignore
# The files are reported in the order of hacking, security
# violations, and unusual system events. Notice that this
# script uses the principle of "That which is not explicitely
# ignored is reported" in that the script will report all items
# that you do not tell it to ignore specificially. Be careful
# how you use wildcards in the logcheck.ignore file or you
# may miss important entries.
# Make sure we really did clean up from the last run.
# Also this ensures that people aren't trying to trick us into
# overwriting files that we aren't supposed to. This is still a race
# condition, but if you are in a temp directory that does not have
# generic luser access it is not a problem. Do not allow this program
# to write to a generic /tmp directory where others can watch and/or
# create files!!
# Shouldn't need to touch these...
HOSTNAME=`hostname`
DATE=`date +%m/%d/%y:%H.%M`
umask 077
rm -f $TMPDIR/check.$$ $TMPDIR/checkoutput.$$ $TMPDIR/checkreport.$$
if [ -f $TMPDIR/check.$$ -o -f $TMPDIR/checkoutput.$$ -o -f $TMPDIR
echo "Log files exist in $TMPDIR directory that cannot be removed.
this may be an attempt to spoof the log checker." \
| $MAIL -s "$HOSTNAME $DATE ACTIVE SYSTEM ATTACK!" $SYSADMIN
exit 1
fi
# LOG FILE CONFIGURATION SECTION
# You might have to customize these entries depending on how
# you have syslogd configured. Be sure you check all relevant logs.
# The logtail utility is required to read and mark log files.
# See INSTALL for more information. Again, using one log file
# is preferred and is easier to manage. Be sure you know what the
# > and >> operators do before you change them. LOG FILES SHOULD
# ALWAYS BE chmod 600 OWNER root!!
# Generic and Linux Slackware 3.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$
# Linux Red Hat Version 3.x, 4.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$
#$LOGTAIL /var/log/secure >> $TMPDIR/check.$$
#$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
# FreeBSD 2.x
$LOGTAIL /var/log/messages > $TMPDIR/check.$$
$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
# BSDI 2.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$
#$LOGTAIL /var/log/secure >> $TMPDIR/check.$$
#$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
#$LOGTAIL /var/log/ftp.log >> $TMPDIR/check.$$
# Un-comment out the line below if you are using BSDI 2.1
#$LOGTAIL /var/log/daemon.log >> $TMPDIR/check.$$
# SunOS, Sun Solaris 2.5
#$LOGTAIL /var/log/syslog > $TMPDIR/check.$$
#$LOGTAIL /var/adm/messages >> $TMPDIR/check.$$
# HPUX 10.x and others(?)
#$LOGTAIL /var/adm/syslog/syslog.log > $TMPDIR/check.$$
# Digital OSF/1
# OSF/1 - uses rotating log directory with date & time in name
# LOGDIRS=`find /var/adm/syslog.dated/* -type d -prune -print`
# LOGDIR=`ls -dtr1 $LOGDIRS | tail -1`
# if [ ! -d "$LOGDIR" ]
# then
# echo "Can't identify current log directory." >> $TMPDIR/checkrepor$
# else
# $LOGTAIL $LOGDIR/auth.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/daemon.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/kern.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/lpr.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/mail.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/syslog.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/user.log >> $TMPDIR/check.$$
# fi
#
Bom essa ? a parte que devemos configurar , vou me basear na configura??o de
uma m?quina FreeBSD , na qual ele ser? executado , mas se voc? quiser configurar
ele para linux ou qualquer outro sistema , n?o ser? t?o diferente.
Eu precisei criar um diret?rio no /etc/local/etc com o nome tmp , assim n?o
precisei mudar algumas sintaxes . Vejamos o que temos que mudar :
# Person to send log activity to.
SYSADMIN=root
Essa linha diz para quem ser? enviado o e-mail com as notifica??es. Ser for
para root , deixa desse jeito.
# Full path to logtail program.
# This program is required to run this script and comes with the package.
LOGTAIL=/usr/local/bin/logtail
Essa linha nos diz onde est? o logtail , ele ? necess?rio para rodar o script,
mas n?o esquente , porque ele vem no package do logcheck.
# Linux, FreeBSD, BSDI, Sun, HPUX, etc.
GREP=egrep
Essa linha faz referencia ao "egrep" , geralmente n?o necessita ser mudada.
# Linux, FreeBSD, BSDI, Sun, etc.
MAIL=mail
Esta faz refer?ncia ao "mail" , geralmente n?o precisa ser mudada.
HACKING_FILE=/usr/local/etc/logcheck.hacking
VIOLATIONS_FILE=/usr/local/etc/logcheck.violations
VIOLATIONS_IGNORE_FILE=/usr/local/etc/logcheck.violations.ignore
IGNORE_FILE=/usr/local/etc/logcheck.ignore
Essas linhas se referem ao caminho dos arquivos que vimos anteriormente,
certifique -se se est? correto com o seu sistema.
# FreeBSD 2.x
$LOGTAIL /var/log/messages > $TMPDIR/check.$$
$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
Essas linhas nos diz que o logcheck ir? analisar os logs vindos de /var/log/messages
e /var/log/maillog , voc? pode alterar essas linhas , dependendo de como o seu
syslog est? configurado.
Lembre -se que voc? pode e deve alterar essas linhas para que o logcheck
funcione corretamente em seu sistema .
Pronto ! , feito isso podemos rodar o logcheck.
RODANDO O LOGCHECK
Vamos colocar o logcheck para trabalhar e em seguida ativaremos o PortSentry,
com isso teremos uma seguran?a maior em nossa rede.
FreeBSD # ./logcheck.sh
FreeBSD# portsentry -tcp
FreeBSD# portsentry -udp
Logo ap?s isso simulei ataques , que o portsentry detectou , e que foi enviado
cara mim por e-mail atrav?s do logcheck.
UMA EXEMPLO DE E-MAIL ENVIADO PELO LOGHECK
From root Thu May 17 15:24:36 2001
Return-Path:
Received: (from root@localhost)
by freebsd.net.com.br (8.11.0/8.11.0) id f4HIOaZ00445
for root; Thu, 17 May 2001 15:24:36 -0300 (BRT)
(envelope-from root)
Date: Thu, 17 May 2001 15:24:36 -0300 (BRT)
From: Charlie Root
Message-Id: <[email protected]>
To: root
Subject: freebsd.net.com.br 05/17/01:15.24 ACTIVE SYSTEM ATTACK!
Active System Attack Alerts
=-=-=-=-=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
Security Violations
=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
May 17 08:03:02 freebsd login: ROOT LOGIN (root) ON ttyv0
May 17 15:08:21 freebsd login: ROOT LOGIN (root) ON ttyv0
Unusual System Events
=-=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
ANALISANDO O E-MAIL ENVIADO PELO LOGCHECK
Active System Attack Alerts
=-=-=-=-=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
Esse alerta enviado pelo logcheck , como podemos ver foi dado pelo portsentry,
o que poderia ser uma poss?vel tentativa de invas?o. Esses avisos foram colocados
aqui porque o alerta "atackalert" esta em nosso arquivo de keyword com caracterizariam
uma poss?vel invas?o.
Security Violations
=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
May 17 08:03:02 freebsd login: ROOT LOGIN (root) ON ttyv0
May 17 15:08:21 freebsd login: ROOT LOGIN (root) ON ttyv0
Novamente temos as infoma??es do portsentry , isso porque a sintaxe "atackalert"
se encontra em todos os nossos arquivos de configura??o,
exceto ? claro nos arquivos que ignoram regras.
A duas novas linhas s?o :
May 17 08:03:02 freebsd login: ROOT LOGIN (root) ON ttyv0
May 17 15:08:21 freebsd login: ROOT LOGIN (root) ON ttyv0
Isso nos diz a data e a hora que Root logou no sistema , agora se n?o foi voc?,
talvez estja com problemas.
Unusual System Events
=-=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
Aqui est? novamente nossa entrada do PortSentry , bom nessa parte voc?
provavelmente receber? infoma??es dos eventos que ocorreram em geral na m?quina,
como reboot , inicializa??o de programas , entre outros.
Provav?lmente voc? precisar? rodar o logcheck como super-usu?rio por?m por quest?es de seguran?a o logcheck n?o ? habilitado a rodar como usu?rio root ou id 0.
Para resolver esta quest?o use o comando:
#su -s /bin/bash -c "/usr/sbin/logcheck>/b>" logcheck
lembrando que o caminho do comando que est? em negrito ? o caminho do bin?rio do script logcheck.
Caso voc? n?o saiba o caminho do aplicativo use o comando.
#whereis logcheck.
At? mais.
sistema a fazerem a auditoria dos logs do sistema , pe?a chave para a
seguran?a de uma rede.
PREVIA SOBRE O LOGCHECK
O logcheck ? um software de auditoria de log para sistemas UNIX . Esse
software desenvolvido pela Psionic Software , analisa e informa atrav?s
do e-mail , o que est? acontecendo no seu sistema , tentado alertar para
uma poss?vel invas?o.
O logcheck ainda pode ser usado para trabalhar junto com o PortSentry ,
um ?timo software IDS (Intrusion Detection System) , ent?o , eu aconselharia
vc instalar e configurar o PortSentry.
Veja os Sistemas que suportam o Logcheck:
? Linux
? SunOS
? Solaris
? HPUX
? Digital OSF/1
? FreeBSD
? BSDI
? OpenBSD
? NetBSD
? Generic (Most variants)
INSTALA??O
A primeira coisa a fazer ? adquirir o software , para isso v? at?
http://www.psionic.com/tools/logcheck-1.1.1.tar.gz ou ent?o procure
no CD-ROM do FreeBSD na parte Security dos packages .
No meu caso , tenho o logcheck no CD-ROM do FreeBSD 4.1.1-Release . Para
instalar o logcheck pelo cd vc pode usar o sysinstall em /stand .
Depois de ter instalado verifique se foi criado os seguintes arquivos , por
padr?o eles ca?ram em /usr/local/etc :
Logcheck.hacking.sample
Logcheck.ignore.sample
Logcheck.sh
Logcheck.violations.ignore.sample
Logcheck.violations.sample
Se todos esses arquivos estiverem forem criados, o software foi instalado
sem problemas.
VEJAMOS O QUE SIGNIFICA CADA UM DESSES ARQUIVOS
Logcheck.hacking ? Este arquivo cont?m keywords que caracterizariam um poss?vel
ataque ao seu sistema , essas keywords geralmente ocorrem quando se ? atacado
por um Port Scanner ou quando se usa sintaxes ilegais no Sendmail.
Logcheck.ignore ? Este arquivo faria quase que o contr?rio do logcheck.hacking,
ele negaria certos alertas , como conex?es com o deamon telnetd.
Logcheck.violations ? Este arquivo cont?m keywords gerados pelo sistema , tanto
negativas como positivas . ex: Denied , Refused.
Logcheck.violations.ignore ? Como o nome j? diz , este ? o arquivo que ignora
certas mensagens geradas pelo sistema
Logcheck.sh ? Esse aqui seria o script de inicializa??o do logcheck.
Eu n?o aconselharia editar esses arquivos , a n?o ser o logcheck.sh , pois
dependendo das regras que voc? adicionar ou retirar , o logcheck pode vir a
dar falsos avisos , o que n?o ? interessante.
Lembre -se de renomear todos os arquivos exceto , o logcheck.sh , retire a parte
.sample dos arquivos , sendo assim eles passaram a fazer parte da configura??o
do logcheck:
mv logcheck.ignore.sample logcheck.ignore
mv logcheck.hacking.sample logcheck.hacking
mv logcheck.violations.ignore.sample logcheck.violations.ignore
mv logcheck.violations.sample logcheck.violations
Feito isso podemos passar para nosso arquivo de configura??o
ARQUIVO DE CONFIGURA??O ----- LOGCHECK.SH---------
Esse arquivo como j? foi dito , ? o script de inicializa??o do nosso utilit?rio,
na verdade ser?o poucas altera??es que teremos que fazer , colocarei a parte deste
script que teremos que configurar .
------------------------------logcheck.sh-----------------------
#!/bin/sh
#
# logcheck.sh: Log file checker
# Written by Craig Rowland
#
# This file needs the program logtail.c to run
#
# This script checks logs for unusual activity and blatant
# attempts at hacking. All items are mailed to administrators
# for review. This script and the logtail.c program are based upon
# the frequentcheck.sh script idea from the Gauntlet(tm) Firewall
# (c)Trusted Information Systems Inc. The original authors are
# Marcus J. Ranum and Fred Avolio.
#
# Default search files are tuned towards the TIS Firewall toolkit
# the TCP Wrapper program. Custom daemons and reporting facilites
# can be accounted for as well...read the rest of the script for
# details.
#
# Version Information
#
# 1.0 9/29/96 -- Initial Release
# 1.01 11/01/96 -- Added working /tmp directory for symlink protection
# (Thanks Richard Bullington ([email protected])
# 1.1 1/03/97 -- Made this script more portable for Sun's.
# 1/03/97 -- Made this script work on HPUX
# 5/14/97 -- Added Digital OSF/1 logging support. Big thanks
# to Jay Vassos-Libove for
# his changes.
# CONFIGURATION SECTION
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/ucb:/usr/local/bin
# Logcheck is pre-configured to work on most BSD like systems, however it
# is a rather dumb program and may need some help to work on other
# systems. Please check the following command paths to ensure they are
# correct.
# Person to send log activity to.
SYSADMIN=root
# Full path to logtail program.
# This program is required to run this script and comes with the package.
LOGTAIL=/usr/local/bin/logtail
# Full path to SECURED (non public writable) /tmp directory.
# Prevents Race condition and potential symlink problems. I highly
# recommend you do NOT make this a publically writable/readable directory.
# You would also be well advised to make sure all your system/cron scripts
# use this directory for their "scratch" area.
TMPDIR=/usr/local/etc/tmp
# The 'grep' command. This command MUST support the
# '-i' '-v' and '-f' flags!! The GNU grep does this by default (that's
# good GNUs for you Linux/FreeBSD/BSDI people :) ). The Sun grep I'm told
# does not support these switches, but the 'egrep' command does (Thanks
# Jason ). Since grep and egrep are usually the GNU
# variety on most systems (well most Linux, FreeBSD, BSDI, etc) and just
# hard links to each other we'll just specify egrep here. Change this if
# you get errors.
# Linux, FreeBSD, BSDI, Sun, HPUX, etc.
GREP=egrep
# The 'mail' command. Most systems this should be OK to leave as is.
# If your default mail command does not support the '-s' (subject) command
# line switch you will need to change this command one one that does.
# The only system I've seen this to be a problem on are HPUX boxes.
# Naturally, the HPUX is so superior to the rest of UNIX OS's that they
# feel they need to do everything differently to remind the rest that
# they are the best ;).
# Linux, FreeBSD, BSDI, Sun, etc.
MAIL=mail
# HPUX 10.x and others(?)
#MAIL=mailx
# Digital OSF/1, Irix
#MAIL=Mail
# File of known active hacking attack messages to look for.
# Only put messages in here if you are sure they won't cause
# false alarms. This is a rather generic way of checking for
# malicious activity and can be inaccurate unless you know
# what past hacking activity looks like. The default is to
# look for generic ISS probes (who the hell else looks for
# "WIZ" besides ISS?), and obvious sendmail attacks/probes.
HACKING_FILE=/usr/local/etc/logcheck.hacking
# File of security violation patterns to specifically look for.
# This file should contain keywords of information administrators should
# probably be aware of. May or may not cause false alarms sometimes.
# Generally, anything that is "negative" is put in this file. It may miss
# some items, but these will be caught by the next check. Move suspicious
# items into this file to have them reported regularly.
VIOLATIONS_FILE=/usr/local/etc/logcheck.violations
# File that contains more complete sentences that have keywords from
# the violations file. These keywords are normal and are not cause for
# concern but could cause a false alarm. An example of this is the word
# "refused" which is often reported by sendmail if a message cannot be
# delivered or can be a more serious security violation of a system
# attaching to illegal ports. Obviously you would put the sendmail
# warning as part of this file. Use your judgement before putting words
# in here or you can miss really important events. The default is to leave
# this file with only a couple entries. DO NOT LEAVE THE FILE EMPTY. Some
# grep's will assume that an EMPTY file means a wildcard and will ignore
# everything! The basic configuration allows for the more frequent sendmail
# error.
#
# Again, be careful what you put in here and DO NOT LEAVE IT EMPTY!
VIOLATIONS_IGNORE_FILE=/usr/local/etc/logcheck.violations.ignore
# This is the name of a file that contains patterns that we should
# ignore if found in a log file. If you have repeated false alarms
# or want specific errors ignored, you should put them in here.
# Once again, be as specific as possible, and go easy on the wildcards
IGNORE_FILE=/usr/local/etc/logcheck.ignore
# The files are reported in the order of hacking, security
# violations, and unusual system events. Notice that this
# script uses the principle of "That which is not explicitely
# ignored is reported" in that the script will report all items
# that you do not tell it to ignore specificially. Be careful
# how you use wildcards in the logcheck.ignore file or you
# may miss important entries.
# Make sure we really did clean up from the last run.
# Also this ensures that people aren't trying to trick us into
# overwriting files that we aren't supposed to. This is still a race
# condition, but if you are in a temp directory that does not have
# generic luser access it is not a problem. Do not allow this program
# to write to a generic /tmp directory where others can watch and/or
# create files!!
# Shouldn't need to touch these...
HOSTNAME=`hostname`
DATE=`date +%m/%d/%y:%H.%M`
umask 077
rm -f $TMPDIR/check.$$ $TMPDIR/checkoutput.$$ $TMPDIR/checkreport.$$
if [ -f $TMPDIR/check.$$ -o -f $TMPDIR/checkoutput.$$ -o -f $TMPDIR
echo "Log files exist in $TMPDIR directory that cannot be removed.
this may be an attempt to spoof the log checker." \
| $MAIL -s "$HOSTNAME $DATE ACTIVE SYSTEM ATTACK!" $SYSADMIN
exit 1
fi
# LOG FILE CONFIGURATION SECTION
# You might have to customize these entries depending on how
# you have syslogd configured. Be sure you check all relevant logs.
# The logtail utility is required to read and mark log files.
# See INSTALL for more information. Again, using one log file
# is preferred and is easier to manage. Be sure you know what the
# > and >> operators do before you change them. LOG FILES SHOULD
# ALWAYS BE chmod 600 OWNER root!!
# Generic and Linux Slackware 3.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$
# Linux Red Hat Version 3.x, 4.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$
#$LOGTAIL /var/log/secure >> $TMPDIR/check.$$
#$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
# FreeBSD 2.x
$LOGTAIL /var/log/messages > $TMPDIR/check.$$
$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
# BSDI 2.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$
#$LOGTAIL /var/log/secure >> $TMPDIR/check.$$
#$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
#$LOGTAIL /var/log/ftp.log >> $TMPDIR/check.$$
# Un-comment out the line below if you are using BSDI 2.1
#$LOGTAIL /var/log/daemon.log >> $TMPDIR/check.$$
# SunOS, Sun Solaris 2.5
#$LOGTAIL /var/log/syslog > $TMPDIR/check.$$
#$LOGTAIL /var/adm/messages >> $TMPDIR/check.$$
# HPUX 10.x and others(?)
#$LOGTAIL /var/adm/syslog/syslog.log > $TMPDIR/check.$$
# Digital OSF/1
# OSF/1 - uses rotating log directory with date & time in name
# LOGDIRS=`find /var/adm/syslog.dated/* -type d -prune -print`
# LOGDIR=`ls -dtr1 $LOGDIRS | tail -1`
# if [ ! -d "$LOGDIR" ]
# then
# echo "Can't identify current log directory." >> $TMPDIR/checkrepor$
# else
# $LOGTAIL $LOGDIR/auth.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/daemon.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/kern.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/lpr.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/mail.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/syslog.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/user.log >> $TMPDIR/check.$$
# fi
#
Bom essa ? a parte que devemos configurar , vou me basear na configura??o de
uma m?quina FreeBSD , na qual ele ser? executado , mas se voc? quiser configurar
ele para linux ou qualquer outro sistema , n?o ser? t?o diferente.
Eu precisei criar um diret?rio no /etc/local/etc com o nome tmp , assim n?o
precisei mudar algumas sintaxes . Vejamos o que temos que mudar :
# Person to send log activity to.
SYSADMIN=root
Essa linha diz para quem ser? enviado o e-mail com as notifica??es. Ser for
para root , deixa desse jeito.
# Full path to logtail program.
# This program is required to run this script and comes with the package.
LOGTAIL=/usr/local/bin/logtail
Essa linha nos diz onde est? o logtail , ele ? necess?rio para rodar o script,
mas n?o esquente , porque ele vem no package do logcheck.
# Linux, FreeBSD, BSDI, Sun, HPUX, etc.
GREP=egrep
Essa linha faz referencia ao "egrep" , geralmente n?o necessita ser mudada.
# Linux, FreeBSD, BSDI, Sun, etc.
MAIL=mail
Esta faz refer?ncia ao "mail" , geralmente n?o precisa ser mudada.
HACKING_FILE=/usr/local/etc/logcheck.hacking
VIOLATIONS_FILE=/usr/local/etc/logcheck.violations
VIOLATIONS_IGNORE_FILE=/usr/local/etc/logcheck.violations.ignore
IGNORE_FILE=/usr/local/etc/logcheck.ignore
Essas linhas se referem ao caminho dos arquivos que vimos anteriormente,
certifique -se se est? correto com o seu sistema.
# FreeBSD 2.x
$LOGTAIL /var/log/messages > $TMPDIR/check.$$
$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
Essas linhas nos diz que o logcheck ir? analisar os logs vindos de /var/log/messages
e /var/log/maillog , voc? pode alterar essas linhas , dependendo de como o seu
syslog est? configurado.
Lembre -se que voc? pode e deve alterar essas linhas para que o logcheck
funcione corretamente em seu sistema .
Pronto ! , feito isso podemos rodar o logcheck.
RODANDO O LOGCHECK
Vamos colocar o logcheck para trabalhar e em seguida ativaremos o PortSentry,
com isso teremos uma seguran?a maior em nossa rede.
FreeBSD # ./logcheck.sh
FreeBSD# portsentry -tcp
FreeBSD# portsentry -udp
Logo ap?s isso simulei ataques , que o portsentry detectou , e que foi enviado
cara mim por e-mail atrav?s do logcheck.
UMA EXEMPLO DE E-MAIL ENVIADO PELO LOGHECK
From root Thu May 17 15:24:36 2001
Return-Path:
Received: (from root@localhost)
by freebsd.net.com.br (8.11.0/8.11.0) id f4HIOaZ00445
for root; Thu, 17 May 2001 15:24:36 -0300 (BRT)
(envelope-from root)
Date: Thu, 17 May 2001 15:24:36 -0300 (BRT)
From: Charlie Root
Message-Id: <[email protected]>
To: root
Subject: freebsd.net.com.br 05/17/01:15.24 ACTIVE SYSTEM ATTACK!
Active System Attack Alerts
=-=-=-=-=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
Security Violations
=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
May 17 08:03:02 freebsd login: ROOT LOGIN (root) ON ttyv0
May 17 15:08:21 freebsd login: ROOT LOGIN (root) ON ttyv0
Unusual System Events
=-=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
ANALISANDO O E-MAIL ENVIADO PELO LOGCHECK
Active System Attack Alerts
=-=-=-=-=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
Esse alerta enviado pelo logcheck , como podemos ver foi dado pelo portsentry,
o que poderia ser uma poss?vel tentativa de invas?o. Esses avisos foram colocados
aqui porque o alerta "atackalert" esta em nosso arquivo de keyword com caracterizariam
uma poss?vel invas?o.
Security Violations
=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
May 17 08:03:02 freebsd login: ROOT LOGIN (root) ON ttyv0
May 17 15:08:21 freebsd login: ROOT LOGIN (root) ON ttyv0
Novamente temos as infoma??es do portsentry , isso porque a sintaxe "atackalert"
se encontra em todos os nossos arquivos de configura??o,
exceto ? claro nos arquivos que ignoram regras.
A duas novas linhas s?o :
May 17 08:03:02 freebsd login: ROOT LOGIN (root) ON ttyv0
May 17 15:08:21 freebsd login: ROOT LOGIN (root) ON ttyv0
Isso nos diz a data e a hora que Root logou no sistema , agora se n?o foi voc?,
talvez estja com problemas.
Unusual System Events
=-=-=-=-=-=-=-=-=-=-=
May 16 09:32:08 freebsd portsentry[224]: attackalert: Connect from host:
windows.net.com.br/192.1.1.1 to TCP port: 1080
May 16 09:32:08 freebsd portsentry[224]: attackalert: Host: 192.1.1.1 is
already blocked. Ignoring
Aqui est? novamente nossa entrada do PortSentry , bom nessa parte voc?
provavelmente receber? infoma??es dos eventos que ocorreram em geral na m?quina,
como reboot , inicializa??o de programas , entre outros.
Provav?lmente voc? precisar? rodar o logcheck como super-usu?rio por?m por quest?es de seguran?a o logcheck n?o ? habilitado a rodar como usu?rio root ou id 0.
Para resolver esta quest?o use o comando:
#su -s /bin/bash -c "/usr/sbin/logcheck>/b>" logcheck
lembrando que o caminho do comando que est? em negrito ? o caminho do bin?rio do script logcheck.
Caso voc? n?o saiba o caminho do aplicativo use o comando.
#whereis logcheck.
At? mais.
Seja Membro Gratuítamente
Assine a newsletter para receber em seu email as publicações atualizadas neste blog