ff-multiconverter, multimedia, audio, video, linux, ubuntu ubuntu kylin, china, releases, linux terminal, ubuntu, linux, comandos, shell conky, gadgets, ubuntu, linux SpeedTest-Cli, velocidad, red, consola, terminal tag foto 6 pinta, grafica, linux, ubuntu djl, juegos, yum, synaptic, paquetes ubuntu, releases, canonical psensor, ubuntu, linux, sistema, monitor
Mostrando las entradas con la etiqueta Seguridad. Mostrar todas las entradas

Tripwire, útil para monitorizar y alertar de cambios específicos de ficheros en un rango de sistemas

Tripwire es un programa de computador Open Source consistente en una herramienta de seguridad e integridad de datos.

Tripwire es útil para monitorizar y alertar de cambios específicos de ficheros en un rango de sistemas.

Para mejor eficacia, se recomienda instalar el programa antes de haber conectado el computador por primera vez a internet a fin de crear una base de datos de los ficheros existentes en el sistema, para poder contrastar los posibles cambios en éstos una vez conectado a la red. Tripwire funciona correctamente en sistemas operativos GNU/Linux.



¿Por qué usar Tripwire?
Para mejorar la seguridad de su sistema.

No existen los sistemas computacionales perfectos e invulnerables que desearíamos, y siempre estaremos expuestos a ataques. Más allá de todas las medidas preventivas que tomemos (firewalls, patches, políticas, etc.) siempre cabe la posibilidad de ser alcanzados por un hacker. Los ataques exitosos a través de la red típicamente involucran la modificación parcial del sistema mediante la alteración o reemplazo de ciertos archivos, lo cual suele ser empleado por el atacante para posteriormente tomar el control total del sistema.

Tripwire asume que todos los controles de seguridad han fallado, y que nuestro sistema ya ha sido alterado; al menos, parcialmente. Sin embargo, parte del arte de los atacantes consiste en no ser descubiertos, y para esto emplean diversas técnicas relativamente sofisticadas.

Tripwire servirá para alertar al administrador de estos cambios (los cuales de otro modo podrían pasar desapercibidos por semanas o meses) a fin de tomar acciones con rapidez.

Para esto, Tripwire monitorea rutinariamente la integridad de una gran cantidad de archivos que tienden a ser blanco de los atacantes. Sin embargo, este proceso es pesado, y se suele ejecutar a intervalos; por ejemplo, diarios o interdiarios, aunque no hay ninguna restricción (salvo de recursos) para no lanzarlo cada media hora.

Instalar Tripwire
Descargue la versión open source de Tripwire del site www.tripwire.org1 . Elija la
versión que corresponda mejor a su sistema operativo.

Tripwire normalmente se distribuye en un archivo RPM que viene empacado en for-
mato TAR comprimido. En este último caso, usar:

# tar xvzf tripwire.tar.gz
Lo cual debería generar el archivo tripwire-2.3-47.i386.rpm (el nombre exacto
dependerá de su versión.)

Ahora instálelo:

# rpm -ivh tripwire-2.3-47.i386.rpm

Nota: En diversas distribuciones de Linux, incluyendo RedHat 7.2 y superiores, Tripwire ya está instalado, razón por la cual este paso puede no ser necesario.

Definir las claves de Tripwire


Tripwire utiliza dos claves (que pueden ser palabras u oraciones) para almacenar su información.

Una de ellas, la "site key" o "clave del site", se emplea para encriptar los archivos de configuración y de las políticas. La otra - la "local key" o "clave local", se usa para encriptar la información referida al estado de los archivos del sistema que se monitorean.

Ud. necesita estas dos claves para las tareas de administración de Tripwire. Estas se deben introducir tan pronto como se ha instalado Tripwire mediante el comando:

# /etc/tripwire/twinstall.sh

Recuérdelas bien, o anótelas en un lugar seguro.

Configurar el archivo de políticas

La configuración de los archivos que van a ser monitoreados por Tripwire se mantiene en un gran archivo conocido como "archivo de políticas" (policy file.) Su manipulación es algo tediosa dada su extensión. Tripwire viene con un archivo que sirve de "plantilla" para ser modificado.

Este archivo es:

/etc/tripwire/twpol.txt.

Ud. puede modificarlo directamente con un editor de texto (aunque le aconsejo que guarde una copia sin modificar del mismo.)

Ahora haremos una observación de órden práctico y didáctico: Tripwire por lo general toma varios minutos en cada una de sus ejecuciones, y si Ud. nunca lo ha usado, probablemente le resultará desesperante aguardar mucho tiempo sin saber si las cosas están yendo bien o mal. Por este motivo yo sugiero que empecemos con una versión reducida (y casi inútil) del archivo de políticas. Una vez que Ud. comprenda el proceso completo, podrá retomar el archivo original y aprovecharlo.

Nuevamente va la advertencia: haga una copia de seguridad del archivo twpol.txt.

Para recortar el archivo proporcionado, simplemente use un editor de texto (como vi) y busque la sección "File System and Disk Administraton Programs".

Programa de auditoría automática Titan, que detecta problemas de seguridad en la máquina local

titan Para corroborar la inseguridad de los sistemas Unix instalados tal y como se distribuyen, o mínimamente configurados, hemos hecho la prueba con uno de los sistemas considerados más seguros: Solaris, de la empresa Sun Microsystems, Inc.. Hemos instalado Solaris 7 sobre un PC, cerrado la mayoría de servicios ofrecidos (en /etc/inetd.conf), y controlado el acceso a otros (telnet, finger, ftp...) mediante TCP Wrappers: justo lo que la mayor parte de administradores harían antes de poner el sistema a funcionar. Tras estos pasos, hemos ejecutado el programa de auditoría automática Titan, que detecta problemas de seguridad en la máquina local (para más información sobre este software se puede consultar [FPA98]).


Instalación de Titan

Hemos elegido Titan justamente por ser uno de los programas más fácilmente instalables sobre SunOS o Solaris: al tratarse de un conjunto de shellscripts, el administrador no ha de preocuparse por ningún proceso de compilación (con los posibles errores que éste puede causar), ni conocer técnicas avanzadas de seguridad para poder utilizarlo (como otros programas que presentan una multitud de opciones diferentes que se pueden combinar entre ellas, de forma que quien los quiera utilizar debe conocer bastante bien ciertos términos de Unix y de la seguridad, que no suelen ser triviales). Tanto la instalación de Titan como su ejecución son muy sencillos.
Para instalar Titan, una vez desempaquetado el fichero, hemos de ejecutar simplemente
Titan-Config, con la opción -i (la opción -d desinstala el software. El programa de instalación nos preguntará si deseamos hacer copias de seguridad de los ficheros que se modifiquen al ejecutar Titan; por nuestra seguridad, podemos decirle que sí (y):

anita:/export/home/toni/Security/Tools# gzip -d Titan,v3.0.FCS.tar.gz
anita:/export/home/toni/Security/Tools# tar xvf Titan,v3.0.FCS.tar
anita:/export/home/toni/Security/Tools# cd Titan,v3.0.FCS
anita:/export/home/toni/Security/Tools/Titan,v3.0.FCS# ./Titan-Config -i
checking for dependencies...
finding out where we are...
we are in '/export/home/toni/Security/Tools/Titan,v3.0.FCS'

checking out your system...
this system runs: SunOS-5.7-i86pc
we will be using: sol2x86

setting up links...
removing old links...
linking bin into path...
linking lib into path...
linking logs into path...
linking src into path...
linking tmp into path...
linking done.
cleaning up is_root, sanity_check, Titan...
pulling in local Titan script...
Run Titan utilites with 'Titan -[v,f,i]' after reading the Docs...
OR
Run Titan using a config file. (Titan -c sample.Server) after reading the Docs
Titan can backup all of the files it modifies; This is recommended
proceed? y/n: y
Okay... Checking for backup program...
Found backtit.sh - Backing up system files now... This might take a while..
Creating backup dir in : /export/home/toni/Security/Tools/Titan,v3.0.FCS/\
arch/sol2sun4/bin/Backup//1013990418
Generating listings.....
Calculating and backing up files now...................................\
............ Done!!
...
...
Saved off 44 files to: /export/home/toni/Security/Tools/Titan,v3.0.FCS/\
arch/sol2sun4/bin/Backup//1013990418
See details in savelist: /export/home/toni/Security/Tools/Titan,v3.0.FCS/\
arch/sol2sun4/bin/Backup//1013990418/../SaveList.1013990418
Restore by running /export/home/toni/Security/Tools/Titan,v3.0.FCS/\
arch/sol2sun4/bin/lib/untit.sh -[g,r]
anita:/export/home/toni/Security/Tools/Titan,v3.0.FCS#

Una vez instalado Titan (todo a partir del directorio actual, no genera ficheros en ningún otro lugar de nuestros sistemas de archivos) podemos ejecutar ya el programa de auditoría, con la opción -v para que no realice ningún cambio en nuestro sistema, sino que simplemente se limite a informarnos de los posibles problemas de seguridad que podemos tener; si deseamos ver el funcionamiento de cada uno de los shellscripts invocados por Titan, podemos utilizar la opción -i, y si lo que queremos es solucionar los problemas detectados, la opción -f (cuidado si hacemos esto, la política de seguridad de Titan es tan estricta que podemos dejar al sistema sólamente utilizable por el root).

Ejecución de Titan
En nuestro caso, queremos que Titan nos informe de los problemas de seguridad que detecte, pero que no los solucione él:

anita:/export/home/toni/Security/Tools/Titan,v3.0.FCS# ./Titan –v _____________________________________________________
*=*=*=*=* Running modules/add-umask.sh now.....
Output to ../logs/modules/add-umask.sh.V.042506
-----------------------------------------------------
No umask file /etc/init.d/umask.sh found

_____________________________________________________
*=*=*=*=* Running modules/adjust-arp-timers.sh now.....
Output to ../logs/modules/adjust-arp-timers.sh.V.042506
-----------------------------------------------------

Checking for ARP timers in /etc/rc2.d/S69inet

ARP timers are not set - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/adjust.syn-timeout.sh now.....
Output to ../logs/modules/adjust.syn-timeout.sh.V.042506
-----------------------------------------------------
ERROR - This script is Only needed on Solaris 2.4 and older
please see Sun's patch (Patch 103582-11 currently) for a better fix

_____________________________________________________
*=*=*=*=* Running modules/automount.sh now.....
Output to ../logs/modules/automount.sh.V.042506
-----------------------------------------------------
File /etc/rc2.d/S74autofs exists...
Automounter =
/usr/lib/autofs/automountd /usr/sbin/automount /usr/bin/pkill - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/create-issue.sh now.....
Output to ../logs/modules/create-issue.sh.V.042506
-----------------------------------------------------
Cannot read /etc/issue - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/decode.sh now.....
Output to ../logs/modules/decode.sh.V.042506
-----------------------------------------------------
Decode disabled - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/disable-L1-A.sh now.....
Output to ../logs/modules/disable-L1-A.sh.V.042506
-----------------------------------------------------
./modules/disable-L1-A.sh: ./sanity_check: No such file or directory

_____________________________________________________
*=*=*=*=* Running modules/disable-NFS.bind.sh now.....
Output to ../logs/modules/disable-NFS.bind.sh.V.042506
-----------------------------------------------------
Verifying port settings using ndd
privileged port definition is currently set to 1024

You should run disable-NFS.bind.sh with the -F option (port=1024)

_____________________________________________________
*=*=*=*=* Running modules/disable-accounts.sh now.....
Output to ../logs/modules/disable-accounts.sh.V.042506
-----------------------------------------------------
Checking 11 Users....
Checking that shell set to noshell for:
daemon bin adm lp uucp nuucp listen nobody noaccess nobody4 ppp
Verify shell status....

daemon shell = - FAILS CHECK
bin shell = - FAILS CHECK
adm shell = - FAILS CHECK
lp shell = - FAILS CHECK
uucp shell = - FAILS CHECK
nuucp shell = /usr/lib/uucp/uucico - FAILS CHECK
listen shell = - FAILS CHECK
nobody shell = - FAILS CHECK
noaccess shell = - FAILS CHECK
nobody4 shell = - FAILS CHECK
ppp shell = /usr/sbin/pppls - FAILS CHECK

11 Users Not Secured Out Of 11

_____________________________________________________
*=*=*=*=* Running modules/disable-core.sh now.....
Output to ../logs/modules/disable-core.sh.V.042506
-----------------------------------------------------
Core dump size has not been set: FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/disable-ping-echo.sh now.....
Output to ../logs/modules/disable-ping-echo.sh.V.042506
-----------------------------------------------------
Ping echo response allowed - FAILED CHECK
Run ./modules/disable-ping-echo.sh with -[Ff] to fix...

_____________________________________________________
*=*=*=*=* Running modules/disable_ip_holes.sh now.....
Output to ../logs/modules/disable_ip_holes.sh.V.042506
-----------------------------------------------------
Checking ip_forwarding...
ip_forwarding disabled - PASSES CHECK
Checking ip_forward_src_routed...
ip_forward_src_routed disabled - PASSES CHECK
Checking ip_forward_directed_broadcasts...
ip_forward_directed_broadcasts disabled - PASSES CHECK
Checking ip_ignore_redirect...
ip_ignore_redirect enabled - PASSES CHECK
Checking ip_strict_dst_multihoming...
ip_strict_dst_multihoming enabled - PASSES CHECK
System configured as 'notrouter' - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/dmi-2.6.sh now.....
Output to ../logs/modules/dmi-2.6.sh.V.042506
-----------------------------------------------------
ERROR - This script is Only supported on Solaris 2.6 and newer,
please use one of the other scripts for your OS

_____________________________________________________
*=*=*=*=* Running modules/eeprom.sh now.....
Output to ../logs/modules/eeprom.sh.V.042506
-----------------------------------------------------
Architecture = i86pc
Eeprom security-mode not supported on this host

_____________________________________________________
*=*=*=*=* Running modules/file-own.sh now.....
Output to ../logs/modules/file-own.sh.V.042506
-----------------------------------------------------
Checking /usr file ownership
Found 25345 files in /usr that should be root owned
Checking /sbin file ownership
Found 13 files in /sbin that should be root owned
Checking /usr group permissions
Found 0 files in /usr that should be set group g-w
Checking /sbin group permissions
Found 0 files in /sbin that should be set group g-w
Checking /etc group permissions
Found 0 files in /etc that should be set group g-w
Checking /opt group permissions
Found 0 files in /opt that should be set group g-w

_____________________________________________________
*=*=*=*=* Running modules/fix-cronpath.sh now.....
Output to ../logs/modules/fix-cronpath.sh.V.042506
-----------------------------------------------------
File /var/spool/cron/crontabs/root exists; continuing
/etc is not writable by world - PASSES CHECK.
/etc is not writeable by group - PASSES CHECK.
/etc/cron.d is not writable by world - PASSES CHECK.
/etc/cron.d is not writeable by group - PASSES CHECK.
/usr is not writable by world - PASSES CHECK.
drwxrwxr-x 32 root 1024 Oct 8 00:58 /usr
/usr is writeable by group - FAILS CHECK
/usr/sbin is not writable by world - PASSES CHECK.
drwxrwxr-x 5 root 4608 Sep 24 01:32 /usr/sbin
/usr/sbin is writeable by group - FAILS CHECK
/usr/lib is not writable by world - PASSES CHECK.
drwxrwxr-x 42 root 10240 Oct 8 00:55 /usr/lib
/usr/lib is writeable by group - FAILS CHECK
/usr/lib/fs is not writable by world - PASSES CHECK.
drwxrwxr-x 13 root 512 Sep 23 18:33 /usr/lib/fs
/usr/lib/fs is writeable by group - FAILS CHECK
/usr/lib/fs/nfs is not writable by world - PASSES CHECK.
/usr/lib/fs/nfs is not writeable by group - PASSES CHECK.
/usr/bin is not writable by world - PASSES CHECK.
drwxrwxr-x 3 root 7680 Oct 8 00:52 /usr/bin
/usr/bin is writeable by group - FAILS CHECK
/etc/cron.d/logchecker ownership should be changed to root
/usr/lib/newsyslog ownership should be changed to root
/usr/bin/rdate ownership should be changed to root
/usr/sbin/rtc ownership should be changed to root
No cron.allow file - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/fix-modes.sh now.....
Output to ../logs/modules/fix-modes.sh.V.042506
-----------------------------------------------------
Only supported on Solaris 2.2 thru 2.6

_____________________________________________________
*=*=*=*=* Running modules/fix-stack.sh now.....
Output to ../logs/modules/fix-stack.sh.V.042506
-----------------------------------------------------
ERROR - This script is Only known to work on Solaris 2.5.[0-5]

_____________________________________________________
*=*=*=*=* Running modules/fix-stack.sol2.6.sh now.....
Output to ../logs/modules/fix-stack.sol2.6.sh.V.042506
-----------------------------------------------------
Stack Protection not currently set - Run fix-stack.sol2.6.sh -F

_____________________________________________________
*=*=*=*=* Running modules/ftpusers.sh now.....
Output to ../logs/modules/ftpusers.sh.V.042506
-----------------------------------------------------
No /etc/ftpusers file in place...
Should contain at least:

root
daemon
sys
bin
adm
lp
smtp
uucp
nuucp
listen
nobody
noaccess
news
ingres
audit
admin
sync
nobody4

Please Run with '-F/f' to Fix - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/hosts.equiv.sh now.....
Output to ../logs/modules/hosts.equiv.sh.V.042506
-----------------------------------------------------
No /etc/hosts.equiv - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/inetd.sh now.....
Output to ../logs/modules/inetd.sh.V.042506
-----------------------------------------------------
File /etc/inet/inetd.conf exists - Checking...
name Closed - PASSES CHECK
exec Closed - PASSES CHECK
comsat Closed - PASSES CHECK
talk Open - FAILS CHECK
uucp Closed - PASSES CHECK
smtp Closed - PASSES CHECK
tftp Closed - PASSES CHECK
finger Open - FAILS CHECK
systat Closed - PASSES CHECK
netstat Closed - PASSES CHECK
rquotad Closed - PASSES CHECK
rusersd Closed - PASSES CHECK
sprayd Closed - PASSES CHECK
walld Closed - PASSES CHECK
rexd Closed - PASSES CHECK
shell Closed - PASSES CHECK
login Closed - PASSES CHECK
exec Closed - PASSES CHECK
comsat Closed - PASSES CHECK
time Closed - PASSES CHECK
echo Closed - PASSES CHECK
discard Closed - PASSES CHECK
daytime Closed - PASSES CHECK
chargen Closed - PASSES CHECK
100087 Closed - PASSES CHECK
rwalld Closed - PASSES CHECK
rstatd Closed - PASSES CHECK
100068 Closed - PASSES CHECK
100083 Closed - PASSES CHECK
100221 Closed - PASSES CHECK
fs Closed - PASSES CHECK
ufsd Closed - PASSES CHECK
100232 Closed - PASSES CHECK
100235 Closed - PASSES CHECK
536870916 Closed - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/keyserv.sh now.....
Output to ../logs/modules/keyserv.sh.V.042506
-----------------------------------------------------
In /etc/rc2.d/S71rpc keyserv ; user nobody enabled - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/log-tcp.sh now.....
Output to ../logs/modules/log-tcp.sh.V.042506
-----------------------------------------------------

_____________________________________________________
*=*=*=*=* Running modules/loginlog.sh now.....
Output to ../logs/modules/loginlog.sh.V.042506
-----------------------------------------------------
No /var/adm/loginlog file - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/lpsched.sh now.....
Output to ../logs/modules/lpsched.sh.V.042506
-----------------------------------------------------
In /etc/rc2.d/S80lp lpsched is enabled - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/nfs-portmon.sh now.....
Output to ../logs/modules/nfs-portmon.sh.V.042506
-----------------------------------------------------
NFS port monitor disabled - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/nsswitch.sh now.....
Output to ../logs/modules/nsswitch.sh.V.042506
-----------------------------------------------------
passwd -> files - PASSES CHECK
group -> files - PASSES CHECK
hosts -> files - PASSES CHECK
networks -> files - PASSES CHECK
protocols -> files - PASSES CHECK
rpc -> files - PASSES CHECK
ethers -> files - PASSES CHECK
netmasks -> files - PASSES CHECK
bootparams -> files - PASSES CHECK
publickey -> files - PASSES CHECK
netgroup -> files - PASSES CHECK
automount -> files - PASSES CHECK
aliases -> files - PASSES CHECK
services -> files - PASSES CHECK
sendmailvars -> files - PASSES CHECK
15 of 15 entries set to files as default - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/nuke-sendmail.sh now.....
Output to ../logs/modules/nuke-sendmail.sh.V.042506
-----------------------------------------------------
Sendmail is enabled in /etc/rc2.d/S88sendmail - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/pam-rhosts-2.6.sh now.....
Output to ../logs/modules/pam-rhosts-2.6.sh.V.042506
-----------------------------------------------------
PAM allows rhosts for rlogin : FAILS CHECK
PAM allows rhosts for rsh : FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/passwd.sh now.....
Output to ../logs/modules/passwd.sh.V.042506
-----------------------------------------------------
All accounts have passwords - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/powerd.sh now.....
Output to ../logs/modules/powerd.sh.V.042506
-----------------------------------------------------
Power management not set to be run by root - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/psfix.sh now.....
Output to ../logs/modules/psfix.sh.V.042506
-----------------------------------------------------
Could not find /etc/rc3.d/S79tmpfix - FAILS CHECK
Run with -[Ff] option to fix

_____________________________________________________
*=*=*=*=* Running modules/rhosts.sh now.....
Output to ../logs/modules/rhosts.sh.V.042506
-----------------------------------------------------
Running against /etc/passwd...

_____________________________________________________
*=*=*=*=* Running modules/rootchk.sh now.....
Output to ../logs/modules/rootchk.sh.V.042506
-----------------------------------------------------
/.login - Clean of . - PASSES CHECK
/etc/.login - Clean of . - PASSES CHECK
/etc/default/login - Clean of . - PASSES CHECK
/.cshrc - Clean of . - PASSES CHECK
/etc/skel/local.cshrc - Contains . - FAILS CHECK
set path=(/bin /usr/bin /usr/ucb /etc .)
/etc/skel/local.login - Clean of . - PASSES CHECK
/etc/skel/local.profile - Clean of . - PASSES CHECK
/.profile - Clean of . - PASSES CHECK
/etc/profile - Clean of . - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/routed.sh now.....
Output to ../logs/modules/routed.sh.V.042506
-----------------------------------------------------

The route daemon advertises routes - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/sendmail.sh now.....
Output to ../logs/modules/sendmail.sh.V.042506
-----------------------------------------------------
No sendmail.cf.titan2 exists - FAILS CHECK
Run with -[Ff] option to fix.
Checking for smrsh
smrsh not found in /sbin - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/smtp-banner.sh now.....
Output to ../logs/modules/smtp-banner.sh.V.042506
-----------------------------------------------------
No /etc/mail/sendmail.cf exists - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/smtpbanner-8.8.sh now.....
Output to ../logs/modules/smtpbanner-8.8.sh.V.042506
-----------------------------------------------------
ERROR - This script is Only supported on patched Solaris 2.6 and newer,
please use one of the other scripts for your OS

_____________________________________________________
*=*=*=*=* Running modules/snmpdx-2.6.sh now.....
Output to ../logs/modules/snmpdx-2.6.sh.V.042506
-----------------------------------------------------
ERROR - This script is Only supported on Solaris 2.6 and newer,
please use one of the other scripts for your OS

_____________________________________________________
*=*=*=*=* Running modules/syslog.sh now.....
Output to ../logs/modules/syslog.sh.V.042506
-----------------------------------------------------
File /etc/syslog.conf exists checking contents....
Syslog auth notice messages disabled - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/tcp-sequence.sh now.....
Output to ../logs/modules/tcp-sequence.sh.V.042506
-----------------------------------------------------
TCP_STRONG_ISS=1
/etc/default/inetinit - has the system default . - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/userumask.sh now.....
Output to ../logs/modules/userumask.sh.V.042506
-----------------------------------------------------
Checking for umask 022 in
/etc/.login
/etc/default/login
/etc/profile
/etc/skel/local.cshrc
/etc/skel/local.login
/etc/skel/local.profile

Umask value other than 022 in /etc/.login - FAILS CHECK
Umask value other than 022 in /etc/.login - FAILS CHECK
Umask value 022 in /etc/profile - PASSES CHECK
Umask value 022 in /etc/skel/local.cshrc - PASSES CHECK
Umask value other than 022 in /etc/skel/local.login - FAILS CHECK
Umask value other than 022 in /etc/skel/local.profile - FAILS CHECK

UMASK value 022 in /etc/default/login - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/utmp.sh now.....
Output to ../logs/modules/utmp.sh.V.042506
-----------------------------------------------------
File utmp permissions o-w - PASSES CHECK
File utmp permissions o-w - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/vold.sh now.....
Output to ../logs/modules/vold.sh.V.042506
-----------------------------------------------------

File /etc/rc2.d/S92volmgt and /usr/sbin/vold exists - FAILS CHECK

Run with -[Ff] option to fix

_____________________________________________________
*=*=*=*=* Running modules/ziplock.sh now.....
Output to ../logs/modules/ziplock.sh.V.042506
-----------------------------------------------------

Unfortunately this is a FIX ONLY utility.....
As noted in the Introduction statement it may break functionality
for all non-root users if run -F

The list of files is as follows and may be manually modified
by editing this script and inserting/commenting out as you
like. Just make sure you know what it is you are changing:

The list of binaries that would be modified is:

/usr/bin/at
/usr/kvm/eeprom
/sbin/su
/usr/bin/atq
/usr/bin/atrm
/usr/bin/chkey
/usr/bin/crontab
/usr/bin/eject
/usr/bin/fdformat
/usr/bin/newgrp
/usr/bin/ps
/usr/bin/rcp
/usr/bin/rdist
/usr/bin/rlogin
/sbin/sulogin
/usr/bin/login
/usr/bin/rsh
/usr/bin/su
/usr/bin/tip
/usr/bin/uptime
/usr/bin/yppasswd
/usr/bin/w
/usr/bin/ct
/usr/bin/cu
/usr/bin/uucp
/usr/bin/uuglist
/usr/bin/uuname
/usr/bin/uustat
/usr/bin/uux
/usr/lib/exrecover
/usr/lib/fs/ufs/ufsdump
/usr/lib/fs/ufs/ufsrestore
/usr/lib/pt_chmod
/usr/lib/sendmail.mx
/usr/lib/acct/accton
/usr/sbin/allocate
/usr/sbin/mkdevalloc
/usr/sbin/mkdevmaps
/usr/sbin/ping
/usr/sbin/sacadm
/usr/sbin/static/rcp
/usr/sbin/whodo
/usr/sbin/deallocate
/usr/sbin/list_devices
/usr/openwin/bin/xlock
/usr/openwin/bin/xdm
/usr/openwin/lib/mkcookie
/usr/ucb/ps
/usr/vmsys/bin/chkperm
/usr/bin/passwd
/usr/bin/csh
/etc/lp/alerts/printer
/usr/kvm/crash
/usr/kvm/eeprom
/usr/bin/netstat
/usr/bin/nfsstat
/usr/bin/write
/usr/bin/ipcs
/usr/sbin/arp
/usr/sbin/prtconf
/usr/sbin/swap
/usr/sbin/sysdef
/usr/sbin/wall
/usr/sbin/dmesg
/usr/openwin/bin/Xsun
/usr/openwin/bin/wsinfo
/usr/openwin/bin/mailtool
/usr/openwin/bin/xload
/usr/openwin/bin/kcms_calibrate
/usr/openwin/bin/kcms_configure
/usr/openwin/bin/kcms_server
/var/adm/messages
/var/log/syslog
/var/adm/pacct
anita:/export/home/toni/Security/Tools/Titan,v3.0.FCS#

Mirando por encima el resultado ofrecido por Titan, vemos que ha detectado <casi 50 posibles problemas! (cada mensaje FAILS CHECK denota una alarma, mientras que cada mensaje PASSES CHECK denota un test satisfactorio).

A la vista de estos resultados, y teniendo en cuenta que hemos utilizado una versión más o menos moderna de Solaris (la versión 7 10/98, si hubiéramos comprobado una versión de Solaris o SunOS más antigua habríamos detectado seguramente muchos más problemas), parece claro que un sistema Unix instalado tal y como se distribuye, o con una configuración de seguridad mínima -nuestro caso-, representa un grave problema ya no sólo para la máquina en cuestión, sino para toda la red en la que trabaja. Por tanto, el uso de cualquier herramienta que nos ayude a solucionar, o al menos a localizar problemas, va a ser útil.

Boletín de Seguridad de Ubuntu: las últimas vulnerabilidades

ubuntu En detalle las vulnerabilidades publicadas en el Boletín Oficial de Ubuntu, relativas a la primera quincena del mes, en el período del 1 al 16/07/2009.

Se refieren obviamente a todas las versiones por las cuales todavìa Canonical brinda soporte técnico: Ubuntu 6.06 LTS Ubuntu 8.04 LTS Ubuntu 8.10 Ubuntu 9.04.

Aplicables para: Ubuntu, Kubuntu, Edubuntu y Xubuntu

Ubuntu Security Notice USN-804-1 July 16, 2009 pulseaudio vulnerability CVE-2009-1894

A security issue affects the following Ubuntu releases: Ubuntu 8.04 LTS Ubuntu 8.10 Ubuntu 9.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 8.04 LTS: pulseaudio 0.9.10-1ubuntu1.1 Ubuntu 8.10: pulseaudio 0.9.10-2ubuntu9.4 Ubuntu 9.04: pulseaudio 1:0.9.14-0ubuntu20.2 In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: Tavis Ormandy, Julien Tinnes, and Yorick Koster discovered that PulseAudio did not safely re-execute itself. A local attacker could exploit this to gain root privileges.

Ubuntu Security Notice USN-803-1 July 14, 2009 dhcp3 vulnerability CVE-2009-0692

A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 8.04 LTS Ubuntu 8.10 Ubuntu 9.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: dhcp3-client 3.0.3-6ubuntu7.1 dhcp3-client-udeb 3.0.3-6ubuntu7.1 Ubuntu 8.04 LTS: dhcp3-client 3.0.6.dfsg-1ubuntu9.1 dhcp3-client-udeb 3.0.6.dfsg-1ubuntu9.1 Ubuntu 8.10: dhcp3-client 3.1.1-1ubuntu2.1 dhcp3-client-udeb 3.1.1-1ubuntu2.1 Ubuntu 9.04: dhcp3-client 3.1.1-5ubuntu8.1 dhcp3-client-udeb 3.1.1-5ubuntu8.1 After a standard system upgrade you need to restart any DHCP network connections utilizing dhclient3 to effect the necessary changes. Details follow: It was discovered that the DHCP client as included in dhcp3 did not verify the length of certain option fields when processing a response from an IPv4 dhcp server. If a user running Ubuntu 6.06 LTS or 8.04 LTS connected to a malicious dhcp server, a remote attacker could cause a denial of service or execute arbitrary code as the user invoking the program, typically the 'dhcp' user. For users running Ubuntu 8.10 or 9.04, a remote attacker should only be able to cause a denial of service in the DHCP client. In Ubuntu 9.04, attackers would also be isolated by the AppArmor dhclient3 profile.

Ubuntu Security Notice USN-802-1 July 13, 2009 apache2 vulnerabilities CVE-2009-1890, CVE-2009-1891

A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 8.04 LTS Ubuntu 8.10 Ubuntu 9.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: apache2-common 2.0.55-4ubuntu2.6 apache2-mpm-perchild 2.0.55-4ubuntu2.6 apache2-mpm-prefork 2.0.55-4ubuntu2.6 apache2-mpm-worker 2.0.55-4ubuntu2.6 libapr0 2.0.55-4ubuntu2.6 Ubuntu 8.04 LTS: apache2-mpm-event 2.2.8-1ubuntu0.10 apache2-mpm-perchild 2.2.8-1ubuntu0.10 apache2-mpm-prefork 2.2.8-1ubuntu0.10 apache2-mpm-worker 2.2.8-1ubuntu0.10 apache2.2-common 2.2.8-1ubuntu0.10 Ubuntu 8.10: apache2-mpm-event 2.2.9-7ubuntu3.2 apache2-mpm-prefork 2.2.9-7ubuntu3.2 apache2-mpm-worker 2.2.9-7ubuntu3.2 apache2.2-common 2.2.9-7ubuntu3.2 Ubuntu 9.04: apache2-mpm-event 2.2.11-2ubuntu2.2 apache2-mpm-prefork 2.2.11-2ubuntu2.2 apache2-mpm-worker 2.2.11-2ubuntu2.2 apache2.2-common 2.2.11-2ubuntu2.2 In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: It was discovered that mod_proxy_http did not properly handle a large amount of streamed data when used as a reverse proxy. A remote attacker could exploit this and cause a denial of service via memory resource consumption. This issue affected Ubuntu 8.04 LTS, 8.10 and 9.04. (CVE-2009-1890) It was discovered that mod_deflate did not abort compressing large files when the connection was closed. A remote attacker could exploit this and cause a denial of service via CPU resource consumption. (CVE-2009-1891)

Ubuntu Security Notice USN-801-1 July 13, 2009 tiff vulnerability CVE-2009-2347

A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 8.04 LTS Ubuntu 8.10 Ubuntu 9.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: libtiff4 3.7.4-1ubuntu3.6 Ubuntu 8.04 LTS: libtiff4 3.8.2-7ubuntu3.4 Ubuntu 8.10: libtiff4 3.8.2-11ubuntu0.8.10.3 Ubuntu 9.04: libtiff4 3.8.2-11ubuntu0.9.04.3 In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: Tielei Wang and Tom Lane discovered that the TIFF library did not correctly handle certain malformed TIFF images. If a user or automated system were tricked into processing a malicious image, an attacker could execute arbitrary code with the privileges of the user invoking the program.

Ubuntu Security Notice USN-799-1 July 13, 2009 dbus vulnerability CVE-2009-1189

A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 8.04 LTS Ubuntu 8.10 Ubuntu 9.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: libdbus-1-2 0.60-6ubuntu8.4 Ubuntu 8.04 LTS: libdbus-1-3 1.1.20-1ubuntu3.3 Ubuntu 8.10: libdbus-1-3 1.2.4-0ubuntu1.1 Ubuntu 9.04: libdbus-1-3 1.2.12-0ubuntu2.1 After a standard system upgrade you need to reboot your computer to effect the necessary changes. Details follow: It was discovered that the D-Bus library did not correctly validate signatures. If a local user sent a specially crafted D-Bus key, they could spoof a valid signature and bypass security policies.

Ubuntu Security Notice USN-800-1 July 13, 2009 irssi vulnerability CVE-2009-1959

A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 8.04 LTS Ubuntu 8.10 Ubuntu 9.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: irssi 0.8.10-1ubuntu1.1 Ubuntu 8.04 LTS: irssi 0.8.12-3ubuntu3.1 Ubuntu 8.10: irssi 0.8.12-4ubuntu2.1 Ubuntu 9.04: irssi 0.8.12-6ubuntu1.1 After a standard system upgrade you need to restart irssi to effect the necessary changes. Details follow: It was discovered that irssi did not properly check the length of strings when processing WALLOPS messages. If a user connected to an IRC network where an attacker had IRC operator privileges, a remote attacker could cause a denial of service.

Ubuntu Security Notice USN-797-1 July 06, 2009 tiff vulnerability CVE-2009-2285

A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 8.04 LTS Ubuntu 8.10 Ubuntu 9.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: libtiff4 3.7.4-1ubuntu3.4 Ubuntu 8.04 LTS: libtiff4 3.8.2-7ubuntu3.2 Ubuntu 8.10: libtiff4 3.8.2-11ubuntu0.8.10.1 Ubuntu 9.04: libtiff4 3.8.2-11ubuntu0.9.04.1 In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: It was discovered that the TIFF library did not correctly handle certain malformed TIFF images. If a user or automated system were tricked into processing a malicious image, a remote attacker could cause an application linked against libtiff to crash, leading to a denial of service.

Ubuntu Security Notice USN-796-1 July 06, 2009 pidgin vulnerability CVE-2009-1889

A security issue affects the following Ubuntu releases: Ubuntu 8.04 LTS Ubuntu 8.10 Ubuntu 9.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 8.04 LTS: pidgin 1:2.4.1-1ubuntu2.5 Ubuntu 8.10: pidgin 1:2.5.2-0ubuntu1.3 Ubuntu 9.04: pidgin 1:2.5.5-1ubuntu8.3 After a standard system upgrade you need to restart Pidgin to effect the necessary changes. Details follow: Yuriy Kaminskiy discovered that Pidgin did not properly handle certain messages in the ICQ protocol handler. A remote attacker could send a specially crafted message and cause Pidgin to crash.

Ubuntu Security Notice USN-795-1 July 02, 2009 nagios2, nagios3 vulnerability CVE-2009-2288

A security issue affects the following Ubuntu releases: Ubuntu 8.04 LTS Ubuntu 8.10 Ubuntu 9.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 8.04 LTS: nagios2 2.11-1ubuntu1.5 Ubuntu 8.10: nagios3 3.0.2-1ubuntu1.2 Ubuntu 9.04: nagios3 3.0.6-2ubuntu1.1 After a standard system upgrade you need to restart Nagios to effect the necessary changes. Details follow: It was discovered that Nagios did not properly parse certain commands submitted using the WAP web interface. An authenticated user could exploit this flaw and execute arbitrary programs on the server.

Ubuntu Security Notice USN-794-1 July 02, 2009 libcompress-raw-zlib-perl, perl vulnerability CVE-2009-1391

A security issue affects the following Ubuntu releases: Ubuntu 8.04 LTS Ubuntu 8.10 Ubuntu 9.04 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 8.04 LTS: libcompress-raw-zlib-perl 2.008-1ubuntu0.1 Ubuntu 8.10: libcompress-raw-zlib-perl 2.011-2ubuntu0.1 perl 5.10.0-11.1ubuntu2.3 Ubuntu 9.04: libcompress-raw-zlib-perl 2.015-1ubuntu0.1 perl 5.10.0-19ubuntu1.1 In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: It was discovered that the Compress::Raw::Zlib Perl module incorrectly handled certain zlib compressed streams. If a user or automated system were tricked into processing a specially crafted compressed stream or file, a remote attacker could crash the application, leading to a denial of service.

Nuevas actualizaciones de seguridad para Ubuntu 9.04 Jaunty Jackalope

Como ya nos tiene acostumbrados Canonical una vez a la semana son publicadas las actualizaciones relativas a la seguridad de Jaunty Jackalope la ùltima release de Ubuntu. Se trata de correcciones de errores y/o actualiuzaciones de software de importancia.

Esta semana publicamos:

libpurple-bin
This package contains the utilities not included in the main libpurple0 package. Currently included are: purple-remote, purple-send, purple-send-async, and purple-url-handler.

libpurple0
Some extra packages are suggested to use increased functionality:
* tcl8.4, tk8.4:
* Support for writing plugins with Tcl/Tk

libtiff4
libtiff is a library providing support for the Tag Image File Format (TIFF), a widely used format for storing image data.
This package includes the shared library.



pidgin
Some extra packages are recommended to use the core functionality present in most pidgin installations:
* gstreamer0.10-plugins-base, gstreamer0.10-plugins-good
* Sound support. More extra packages are suggested to use increased functionality:
* gnome-panel | kdebase-workspace-bin | docker:
* To use the system tray icon functionality (minimizing to an icon, having
the icon blink when there are new messages, etc.)
* evolution-data-server:
* For interfacing with an Evolution address book
* libsqlite3-0:
* To use Contact Availability Prediction plugin

pidgin-data
This package contains architecture-independent supporting data files required for use with pidgin, such as documentation, icons, translations, and sounds.


Recomendados:

hal
This abstraction layer is simply an interface that makes it possible to add support for new devices and new ways of connecting devices to the computer, without modifying every application that uses the device. It maintains a list of devices that currently exist, and can provide information about those upon request.

libhal-storage1
This abstraction layer is simply an interface that makes it possible to add support for new devices and new ways of connecting devices to the computer, without modifying every application that uses the device. It maintains a list of devices that currently exist, and can provide information about those upon request. This library provides an interface for handling storage devices.

libhal1
This abstraction layer is simply an interface that makes it possible to add support for new devices and new ways of connecting devices to the computer, without modifying every application that uses the device. It maintains a list of devices that currently exist, and can provide information about those upon request. This package contains shared libraries to be used by applications.

Si te ha gustado el artículo inscribete al feed clicando en la imagen más abajo para tenerte siempre actualizado sobre los nuevos contenidos del blog:



Guia de Seguridad del Administrador de Linux (GSAL): Acceso a los ficheros del servidor WWW

Acceso a los ficheros del servidor WWW

En algún momento habrá que acceder a los ficheros del servidor para actualizarlos. Hacer un logging y utilizar un editor de texto como el emacs no suele ser una sabia decisión a largo plazo, si valoras tu tiempo. Hay varios paquetes de autoría de HTML que pueden acceder al website vía FTP o compartición de ficheros de Windows.

FTP

Este es el método clásico de garantizar acceso a los usuarios a los servidores ftp, las preocupaciones habituales incluyen que los usuarios puedan verse sus
ficheros entre sí, que vean ficheros del sistema que no deberían, etcétera.

Hacer un chroot de las sesiones de los usuarios resolverá la mayoría de estos problemas, sin embargo el principal problema que existe con el FTP es que cifrar el nombre de usuario y la contraseña no suele ser posible debido al hecho de que la mayoría de la gente está utilizando clientes FTP de Windows.

Recomendaría el ProFTPD antes que el WU-FTPD para una aplicación de este tipo,
el ProFTPD tiene mejores controles de acceso.

Acceso Samba

El Samba es bastante útil para compartir directorios www con clientes Windows, se pueden mantener los nombres de usuarios y contraseñas separados del sistema (utilizando smbpasswd en vez del passwd del sistema) y el cifrado de logins no es ningún problema. Simplemente hay que hacer los directorios compartidos no visibles, y utilizar la directiva "valid users" para restringir qué usuarios pueden ver los datos compartidos. Por ejemplo:

[www-example]

path = /www/www.example.org/

valid users = example

read only = No

browseable = No

configurará un directorio compartido bastante seguro del directorio "/www/www.example.org/" al que sólo podrá acceder el usuario "example".

Acceso Frontpage

El FrontPage es uno de los programas más famosos para edición de HTML entre los usuarios de Windows (qué caramba, incluso yo lo utilizo). Puede comunicarse directamente con los servidores WWW y descargar / subir ficheros de un sitio (llamado el "sitio Frontpage") si el servidor soporta extensiones FrontPage. Las extensiones FrontPage se encuentran disponibles para diferentes plataformas

UNIX, gratuitamente, en Ready To Run Software: http://www.rtr.com En el pasado, las extensiones FrontPage de RTR para UNIX han sido un tanto desastrosas. Sin embargo existen alternativas comerciales, una es el Instant ASP, disponible en:
http://www.halcyonsoft.com

RearSite

El RearSite es un programa cgi que proporciona a los usuarios acceso a sus directorios vía un navegador normal. Se puede conseguir en:
http://listes.cru.fr/rs/fd

Fast Webpage Exchanger

El Fast Webpage Exchanger mantiene sincronizados los ficheros utilizando un interesante fichero de configuración en el que se especifica todo. Se puede descargar desde: http://www.enjoy.ne.jp/~gm/program/iew_en.html

SMTP

Simple Mail Transfer Protocol (SMTP), es uno de los servicios más importantes que proporciona Internet. Ahora casi todas las compañías tienen o dependen del correo, y por extensión todos los servidores SMTP. Se encuentran disponibles muchos paquetes SMTP, siendo el más viejo y el más probado el Sendmail (ahora con soporte comercial, etc.), y hay dos nuevos contendientes, Postfix y Qmail, ambos dos escritos desde cero teniendo en cuenta la seguridad. Filtrar con el
cortafuegos el SMTP no tiene pérdida, se ejecuta en el puerto 25, tcp:

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 25

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 25

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 25

o bien con ipchains:

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 25

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 25

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 25

Sendmail

Sendmail es otro de esos servicios con los que la mayoría de nosotros hemos tenido relaciones. Odiamos administrarlo y nos encantaría reemplazarlo (en realidad he empezado a eliminar el Sendmail de las máquinas que administro y lo estoy reemplazando con el Postfix).

Sendmail se ha ganado por sí mismo una muy mala reputación en cuanto a seguridad, sin embargo es difícil echarle la culpa al software cuando te encuentras con sistemas ejecutando versiones antiguas del sendmail. La raíz del problema (si se me permite el mal juego de palabras) es que casi todo el mundo ejecuta el sendmail como root (y algo así como el 70% del correo de Internet se maneja mediante máquinas con Sendmail, de modo que hay un montón de ellas), de
forma que tan pronto se encuentra un bug, encontrar un sistema que explotar no es tan difícil. Las últimas versiones de sendmail han sido bastante buenas, sin hacks del root, etc, y con las nuevas características anti spam finalmente ha alcanzado la mayoría de edad. Más información en Sendmail y su código fuente está disponible en:

http://www.sendmail.org/

Hacer un chroot del sendmail es una buena opción, pero lleva demasiado trabajo, y puesto que se ejecuta como root, algo bastante discutible en cuanto a su efectividad (puesto que el root se puede escapar de una cárcel chroot).

Personalmente pienso que es mejor invertir el esfuerzo en cambiarse a Postfix o a Qmail.

Mantener actualizado el sendmail es relativamente simple, recomendaría como mínimo la versión 8.9.3 (la serie 8.9 tiene más características anti-spam, la 8.8.x tiene la mayoría de estas características, suponiendo que se ha configurado correctamente el sendmail.cf). La mayoría de las distribuciones vienen con la 8.8.x, aunque las versiones más recientes suelen venir con la
8.9.x. Se puede conseguir el código fuente desde ftp://ftp.sendmail.org/, pero compilar el sendmail no es algo para el débil de corazón o para aquellos que no tengan un montón de tiempo para dedicárselo.

Sendmail sólo tiene que estar accesible desde el mundo exterior si se está utilizando para recibir correo de otras máquinas y repartirlo localmente. Si sólo se quiere ejecutar sendmail de forma que funcione el reparto local (p. ej., una estación de trabajo autónoma, un servidor de prueba u otros) y que se pueda enviar con facilidad el correo a otras máquinas, simplemente filtra con
el cortafuegos el sendmail, o mejor, no lo ejecutes en modo demonio (en el cual escucha conexiones). Sendmail se puede ejecutar en la cola de refresco de un nodo, donde simplemente se "despierta" cada cierto tiempo y procesa el correo local, ya sea distribuyéndolo localmente o enviándolo a través de la red. Para configurar la ejecución del Sendmail en modo cola:

edita el script de inicio del Sendmail y cambia la línea que contiene:

sendmail –bd –q1h

por:

sendmail –q1h

Ten en cuenta que: si utilizas el sistema para enviar mucho correo quizás prefieras disminuir el tiempo de refresco, quizás "-q15m" (refrescar la cola cada 15 minutos), ahora el correo saliente y el correo interno del sistema se comportarán bien, lo cual a menos que se ejecute un servidor de correo, es perfecto.

Ahora vienen todas esas maravillosas características anti-spam del sendmail.
Los ficheros de configuración del Sendmail consisten en (se aplica al Sendmail 8.9.x):

/etc/sendmail.cf

El fichero de configuración principal, también dice dónde se encuentran el resto de ficheros de configuración.

/etc/mail/

Se puede definir la localización de los ficheros de configuración en sendmail.cf, generalmente la gente los coloca en /etc/ o en /etc/mail (lo cual
lo lía menos).

access

La base de datos de la lista de accesos, permite rechazar el correo proveniente de ciertas fuentes (IP o dominio), y controlar con facilidad las transmisiones.
Mi fichero de acceso es así:

* RELAY

spam.com REJECT

lo que quiere decir que a 10.0.0.* (los hosts de mi red interna) se les permite
utilizar el servidor de correo para enviar correo donde quieran, y el correo de
*.spam.com se rechaza. Hay listas en línea de spammers conocidos, generalmente
suele tener entre 5-10.000 entradas, lo cual puede afectar seriamente el
rendimiento del sendmail (pues cada conexión se comprueba contra esta lista),
por otra parte, tener una máquina sendmail para enviar spam es incluso peor.

aliases

El fichero de alias, te permite controlar el reparto del correo local al
sistema, es útil para hacer una copia de seguridad del correo entrante de un
usuario a un spool por separado. La mayoría del software de servidores de
listas utiliza este fichero para enviar el correo que recibe a los programas
que realmente procesan las listas. Recuerda ejecutar el comando "newaliases"
después de editar este fichero, y después reiniciar el sendmail.

domaintable

la tabla de dominios (añadir dominios) que se maneja, útil para hacer hosting
virtual.

majordomo

fichero de configuración de majordomo, personalmente recomendaría SmartList a
Majordomo.

sendmail.cw

fichero que contiene nombres de hosts de los que se recibe correo, útil si se
alberga más de un dominio.

sendmail.hf

situación del fichero de ayuda (telnet al puerto 25 y escribir "HELP")

virtusertable

Tabla de usuario virtual, mapea usuarios entrantes, p. ej., mapear
ventas@ejemplo.org a john@ejemplo.org

Sendmail 8.9.x (y versiones anteriores) en realidad no tienen soporte para
hacer un log de todo el correo de una forma agradable (un requisito
indispensable por muchas compañías por motivos legales). Esta es una de las
características sobre las que se trabaja en la versión de Sendmail 8.10.x.
Hasta entonces, hay dos formas de hacer log del correo, la primera es algo
agraciada, y registra un log de los correos entrantes a usuarios según cada
usuario. El segundo método no es agraciado, e implica un simple log de todas
las transacciones SMTP a un fichero, habría que escribir algún tipo de
procesador (probablemente en perl) para que el log fuese útil.

El correo (o las conexiones SMTP para ser más precisos) primero se filtra con el fichero access, y es aquí donde se pueden RECHAZAR correos de ciertos dominios/IP's, y TRANSMITIR correo de ciertos hosts (p. ej. tu red interna de máquinas windows). Cualquier dominio local para el que se hospeda el correo tendrá que ir al sendmail.cw. Suponiendo que el correo cumple con las reglas y va a la cola para reparto local, el siguiente fichero que se comprueba en virtusertable, que es una lista de direcciones de correo mapeadas al nombre de la cuenta/otra dirección de correo. p.ej.:

seifried@seifried.org alias-seifried

listuser@seifried.org usuariolista

@seifried.org correos-estropeados

La última regla es para evitar que reboten los correos estropeados, y que en lugar de eso se envíen a un buzón. Después se comprueba el fichero de alias, si se encuentra una entrada se hace lo que dice, y si no, se intenta entregar el correo a un buzón de un usuario local, mi entrada seifried del fichero de alias
es:

alias-seifried: seifried, "/var/backup-spool/seifried"

De esta forma mi correo se reparte a mi buzón normal, y a un buzón de copia de seguridad (por si acaso he borrado un correo que no quisiera), o en el peor de los casos, Microsoft Outlook decide cascar un día y cargarse mis buzones. Esto también sería útil en empresas, puesto que ahora se tiene una copia de seguridad de todo el correo entrante según cada usuario, y se les puede
permitir ( o no) acceder al fichero que contiene el correo en la copia de seguridad.

Una advertencia, cuando se esté usando una regla general para un dominio ( p. ej. @seifried.org) hay que crear un alias para CADA cuenta, y para las listas de correo. Si no, cuando se examina la lista y no se encuentra una entrada específica (para, digamos, lista-correo@seifried.org) lo enviará al buzón especificado por la regla general. Ya sólo por este motivo no se debería
utilizar una regla general.

El segundo método es muy simple, sencillamente se arranca el sendmail con la opción –x y se especifica un fichero para hacer un log de todas las transacciones. Este fichero crecerá con enorme rapidez, NO recomendaría utilizar este método para hacer log del correo, al menos que sea absolutamente necesario.

Qmail

Qmail (al igual que Postfix) fue creado como una respuesta directa a los fallos percibidos en Sendmail. Qmail es GPL con una cláusula sin distribución binaria que obliga a instalarlo desde el código fuente. Muy poco del código del Qmail se ejecuta como root, y es muy modular comparado con el sendmail (el cual es un trozo de código monolítico). Se puede descargar de: http://www.qmail.org/

Postfix

El Postfix es un agente de transferencia de correo (MTA) orientado a la seguridad, velocidad, y facilidad de configuración, cosas en las que Sendmail suele fallar por lo general. Recomendaría encarecidamente reemplazar el Sendmail por el Postfix. La única parte de Postfix que se ejecuta como root es un programa de control maestro, llamado "master", que llama a otros programas
para procesar el correo a la cola ("pickup"), un programa para gestionar la cola, espera conexiones entrantes, repartos de correo retrasados, etc.

("qmgr"), un programa que en realidad envía y recibe el correo ("smtpd") etc.
Cada parte de Postfix está muy bien pensada, y generalmente hace una o dos tareas, muy bien. Por ejemplo, en lugar del modelo de sendmail, donde el correo simplemente se volcaba a /var/spool/mqueue, en Postfix existe un directorio accesible por el mundo llamado "maildrop" el cual se comprueba mediante "pickup", el cual alimenta los datos a "cleanup", el cual mueve el correo (si está correctamente formateado, etc.) a un directorio seguro de cola para el
procesado real.

Los ficheros primarios de configuración están en /etc/postfix, y existen varios ficheros primarios de configuración que es necesario tener:

master.cf

Controla el comportamiento de varios programas de "ayuda", están hechos chroot, el máximo número de procesos que pueden ejecutar, etcétera. Probablemente sea mejor dejar las configuraciones por defecto en la mayoría de los servidores de correo, a menos que se necesite ajustar algo por altas cargas o asegurar el servidor (p. ej. haciéndolo chroot).

main.cf

Este fichero está muy próximo al sendmail.cf (en cuanto a propósito, en cuanto al diseño es bastante diferente). Está bien comentado y configura todas las variables principales, y las situaciones y formato de diferentes ficheros que contienen información tal como los mapeos a usuarios virtuales e información relativa.

He aquí una lista de variables y localización de ficheros que se suele tener que configurar, el fichero /etc/postfix/main.cf por lo general suele estar comentado densamente. Ten en cuenta que los siguientes ejemplos de entradas main.cf no son un main.cf completo.

# ¿cuál es el nombre de la máquina?

myhostname = correo.ejemplo.org

# ¿cuál es el nombre de dominio?

mydomain = ejemplo.org

# ¿cómo etiqueto el "from" del correo?

myorigin = $mydomain

# ¿en qué interfaces lo ejecuto? Por lo general, en todas.

inet_interfaces = all

# un fichero que contiene una lista de nombres de hosts y nombres de

# dominio cualificados desde los cuales recibo correo,

# generalmenteestán listados así:

# mydestination = localhost, $myhostname, etc

# pero prefiero mantener el listado en un fichero.

mydestination = /etc/postfix/mydestination

# mapa de nombres de usuarios entrantes. "man 5 virtual"

virtual_maps = hash:/etc/postfix/virtual

# mapeo de alias (como /etc/aliases en sendmail), "man 5 aliases"

alias_maps = hash:/etc/postfix/aliases

# base de datos de alias, se pueden tener diferentes configuraciones.

# "man 5 aliases"

alias_database = hash:/etc/postfix/aliases

# dónde repartir el correo, formato Mailbox o Maildir

# (el tradicional /var/spool/mail).

home_mailbox = Maildir/

# dónde guardar el correo, generalmente en /var/spool/mail/ pero se

# puede cambiar con facilidad

mail_spool_directory = /var/spool/mail

# ¿qué comando utilizamos para repartir el correo? /usr/bin/procmail

# es el comando por defecto, pero yo utilizo scanmail que es el sello

# del software antivirus AMaViS

mailbox_command = /usr/sbin/scanmails

# para quién retransmito el correo, de nuevo se pueden listarlos o

# guardarlos en un fichero (uno por línea).

relay_domains = /etc/postfix/relaydomains

# lista de redes locales (por defecto se retransmite el correo de

# estos hosts).

mynetworks = 10.0.0.0/24, 127.0.0.0/8

# ¿qué se le muestra a la gente que conecte al puerto 25? Por defecto

# muestra el número de versión, lo cual yo no hago.

smtpd_banner = $myhostname ESMTP $mail_name

En términos generales, cualquier fichero que simplemente liste un elemento por línea (como /etc/postfix/mydestination o /etc/postfix/relaydomains) se suelen almacenar como simple texto llano. Los ficheros que contienen mapeados (p. ej. alias, donde se tienen entradas como "root: cualquierusuario") deberían transformarse en ficheros hash de base de datos por velocidad (se puede especificar el tipo de fichero como hash, dbm, etc.).

Al igual que la mayoría de productos de IBM, Postfix tiene una licencia bastante curiosa, pero parece que la mayoría es código abierto y libre. Postfix se encuentra disponible en: http://www.postfix.org/. Se pueden conseguir los rpm's de postfix en: ftp://contrib.Redhat.com/, y aparentemente SuSE ahora viene con Postfix.

Sendmail Pro

Sendmail Pro es una versión comercial de Sendmail con soporte, y se encuentra disponible en: http://www.sendmail.com/. No me ha sido posible conseguir una demo o encontrar a alguien que lo utilice, de modo que no estoy seguro al 100% de lo cercano que se encuentra al Sendmail "original", aunque la compañía me ha dicho que utiliza el mismo código de base.

Zmailer

Zmailer es un gestor de correo GPL disponible en: http://www.zmailer.org/.
Tiene ganchos criptográficos y por lo general parece bien construido.

DMail

DMail es un servidor de correo comercial, y no es código abierto. Se puede descargar una versión de prueba de: http://netwinsite.com/dmail_first.htm

nullmailer

El nullmailer envía correo a hosts inteligentes (relays) de forma que la máquina local no tenga que ejecutar ningún software de servidor. Está en:
http://em.ca/~bruceg/nullmailer/.

MasqMail

El MasqMail manda el correo a una cola mientras está offline y después lo envía cuando conectas a tu ISP. Se puede configurar para múltiples ISP's, con dirección de respuesta, etc. Se puede descargar en:
http://merlin.uni-sw.gwdg.de/~okurth/masqmail/

Dynamic Relay Authorization Control

El Dynamic Relay Authorization Control (DRAC) se une a tu servidor POP/IMAP para garantizar temporalmente acceso de reenvío SMTP a los hosts que se han autentificado con éxito y recogen correo (asumiendo que estos hosts enviarán correo, y no van a abusar de este privilegio. Se puede conseguir en:
http://mail.cc.umanitoba.ca/drac/index.html.

POP

WU IMAPD (popd original)

POP e IMAP están relacionados pero son muy diferentes, de modo que los he separado aparte. POP significa "Protocolo de Oficina de Correos, Post Office Protocol" y simplemente te permite listar mensajes, recibirlos y borrarlos. Existen muchos servidores POP disponibles para Linux, el original que viene con la mayoría de las distribuciones suele ser adecuado para la mayoría de los
usuarios. Los problemas principales con POP son similares a los de muchos otros protocolos; los nombres de usuarios y sus contraseñas se transmiten en texto claro, haciendo de ello un buen objetivo para un sniffer de paquetes. El POP se puede "SSLificar", sin embargo no todos los clientes de correo soportan POP seguro mediante SSL. La mayoría de los servidores POP vienen configurados para utilizar TCP_WRAPPERS, que es un método excelente de restringir el acceso. Para más información, ver anteriormente la sección sobre TCP_WRAPPERS. POP se ejecuta como root (ya que tiene que acceder a buzones) y en el pasado se han detectado varios ataques de root a varios servidores POP. POP se ejecuta en el puerto 109 y 110 (aunque el 109 está obsoleto), utilizando el protocolo tcp. El servidor IMAPD de la Universidad de Washington también viene con un servidor POP y en general se trata del servidor POP standard que viene con la mayoría de distribuciones Linux. Se puede conseguir de: http://www.washington.edu/imap/.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 110

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 110

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 110

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 110

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 110

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 110

Cyrus

Cyrus en un servidor imap (también soporta pop y kpop) dirigido a entornos "cerrados". Es decir, que los usuarios no tendrán ningún acceso al servidor de correo más que mediante los protocolos imap o pop. Esto le permite a Cyrus almacenar el correo de forma más segura, y permite una gestión más sencilla en instalaciones más grandes. Cyrus no tiene licencia GNU, pero es relativamente "libre", y está disponible en: http://andrew2.andrew.cmu.edu/cyrus/imapd/.
También existe un conjunto de herramientas añadidas a Cyrus disponible en:
ftp://ftp.hr.vc-graz.ac.at/cyrus-tools/.

IDS POP

IDS (No apesta, "It Doesn't Suck") POP es un reemplazo más ligero del popd dirigido a instalaciones más pequeñas. Es GPL y se encuentra disponible en:
http://www.nodomainname.net/software/ids-pop/.

Qpopper

Qpopper es freeware, está producido por Qualcomm (los autores de Eudora). No lo recomendaría (el código fuente no está disponible). Se puede conseguir de:
http://eudora.qualcomm.com/freeware/qpop.html.

IMAPD

WU IMAPD (imapd original)

IMAP es un POP con esteroides. Permite mantener con facilidad múltiples cuentas, permitir a múltiples personas acceso a una cuenta, dejar correo en el servidor, simplemente descargar los encabezados, o los cuerpos sin attachments, etc. IMAP es ideal para cualquiera o con serias necesidades de correo. Los servidores POP e IMAP que traen la mayoría de las distribuciones (empaquetados en un único paquete llamado imapd, por extraño que parezca) cubren la mayoría
de las necesidades.

IMAP también se ejecuta como root, aunque imapd suele tener el privilegio del usuario que está accediendo, y no se puede configurar con facilidad para que se ejecute como usuario no-root, puesto que tienen buzones abiertos (y en el caso de IMAP, crea carpetas, ficheros, etc. en el directorio personal del usuario), de modo que no se pueden quitar los privilegios tan pronto como alguien quisiera. Ni se puede hacer chroot con facilidad (IMAP necesita tener acceso a
/var/spool/mail, e IMAP necesita acceder al directorio personal del usuario).

La mejor política es tener el software actualizado. Y si es posible, filtrar pop e imapd con el cortafuegos, lo cual funciona bien no hay nadie de gira que necesite recoger su correo vía Internet. El IMAP de la Universidad de Washington (WU) se encuentra disponible en: http://www.washington.edu/imap/.

IMAP se ejecuta en el puerto 143 y la mayoría de los servidores IMAPD soportan
TCP_WRAPPERS, lo cual le hace relativamente sencillo de bloquear.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 143

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 143

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 143

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 143

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 143

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 143


Si te ha gustado el artículo inscribete al feed clicando en la imagen más abajo para tenerte siempre actualizado sobre los nuevos contenidos del blog:

El SNMP se diseñó para permitir que sistemas heterogéneos y equivalentes hablasen entre sí

El SNMP (Protocolo Simple de Gestión de Red, Simple Network Management Protocol) se diseñó para permitir que sistemas heterogéneos y equivalentes hablasen entre sí, generasen informes y permitiesen modificaciones de sus configuraciones sobre una red TCP-IP.

Por ejemplo, un dispositivo SNMP (como un router Cisco) se puede monitorizar/configurar desde un cliente SNMP, y se pueden escribir con sencillez scripts, para, digamos, alertarte si los paquetes denegados/segundo suben por encima de 20.

Por desgracia, SNMP no trae seguridad incluida. El SNMPv1 se propuso originalmente en el RFC 1157 (Mayo de 1990) y la sección 8 (Consideraciones de Seguridad) dice: "En esta memoria no se discuten asuntos de seguridad". Creo que eso lo resume todo. En 1992/1993, salió el SNMPv2, y contenía consideraciones de seguridad, sin embargo éstas se eliminaron más tarde cuando demostraron ser totalmente rompibles. De modo que hoy hemos acabado con un SNMPv2 sin seguridad.
Actualmente, la única forma de proteger los dispositivos SNMP consiste en configurar el nombre de la comunidad por algo difícil de adivinar (pero es muy fácil hacer un sniffing del cable y encontrar el nombre), y filtrar con el cortafuegos el SNMP de modo que sólo los hosts que necesiten hablar entre sí puedan hacerlo (lo cual te deja abierto al spoofing). Los ataques al nombre de la comunidad mediante fuerza bruta son fáciles de llevar a cabo, y suelen ser efectivos, y existen varios métodos para monitorizar específicamente las transmisiones SNMP y reventar por completo una comunidad SNMP, es un mundo peligroso el que existe por ahí fuera.

Estos riesgos se pueden mitigar ligeramente dada la utilidad que tiene el SNMP, puesto que si está soportado e implementado de forma correcta, puede hacer significativamente más sencilla la administración de la red. Casi en cada
implementación de SNMP, el nombre por defecto de la comunidad es "public" (en cuanto a Linux, NT, etc), hay que cambiarlo, por algo más oscuro (el nombre de la empresa es una mala idea). Una vez que alguien ha conseguido el nombre de la comunidad, puede llevar a cabo un "snmpwalk" y entrar en la red. El SNMP se ejecuta sobre UDP en los puertos 161 y 162; hay que bloquear esto en todas las entradas a la red (la backbone, el pool de acceso telefónico, etc.). Si un
segmento de la red no tiene habilitados dispositivos SNMP o una consola SNMP, habría que bloquear el SNMP hacia y desde esa red. Esta es la única línea de defensa en cuanto a SNMP.

Por añadidura, el uso de IPSec (u otro software VPN) puede reducir considerablemente el riesgo de sniffing. Los RFC's del SNMPv3 se centran con intensidad en la seguridad (específicamente el RFC 2274, Ene 1998) de modo que queda algo de esperanza en el futuro. Si se están comprando productos SNMP, asegúrate de que soportan SNMPv3, pues sólo así tendrás oportunidades reales de seguridad.

Con el cu-snmpd no existen problemas específicos per-se, aparte de los problemas generales del SNMP anteriormente cubiertos. Las herramientas y utilidades cu-snmp sólo soportan SNMPv1 y SNMPv2, de modo que recuerda tener
cuidado al utilizarlas sobre redes no fiables, puesto que la principal línea de seguridad (el nombre de la comunidad) quedará expuesta a que lo vea cualquiera.

ipfwadm –I –a accept –P udp –S 10.0.0.0/8 –D 0.0.0.0/0 161:162

ipfwadm –I –a accept –P udp –S un.host.fiable –D 0.0.0.0/0 161:162

ipfwadm –I –a deny –P udp –S 0.0.0.0/0 –D 0.0.0.0/0 161:162

ipchains –A input –p udp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 161:162

ipchains –A input –p udp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 161:162

ipchains –A input –p udp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 161:162

Finger

El Finger es una de esas cosas que la mayoría de los administradores deshabilitan e ignoran. Es una herramienta útil según la ocasión, pero si se quiere permitir que otros administradores se hagan una idea de cuál de tus usuarios está intentando reventar el sistema, utiliza identd. El Finger revela demasiada información, y es la herramienta favorita para pruebas niciales, y recopilación de datos sobre los objetivos. Existen otro tipo de ataques DOS, la mayoría consistentes en el envío de cientos de peticiones de finger y en ciertas configuraciones simplemente en observar el murmullo del servidor. Por
favor, no ejecutes el finger. Muchas distribuciones vienen con él habilitado, pero citando el inetd.conf de Red Hat:

# Finger, systat y netstat proporcionan información que puede ser

# valiosa para potenciales "revienta sistemas". Muchos sitios eligen

# deshabilitar alguno de estos servicios para mejorar la seguridad.

Si todavía se tiene la sensación de que es absolutamente imprescindible utilizarlo, ejecútalo con –u para denegar las peticiones de tipo finger @host que sólo se utilizan para reunir información para futuros ataques. Deshabilita finger, de veras. Recientemente Fingerd también ha sido la causa de unos pocos ataques severos de denegación de servicio, especialmente si se ejecuta el NIS con grandes mapas, NO, repito NO ejecutes fingerd. El finger se ejecuta en el
puerto 79, y el cfinger se ejecuta en el puerto 2003, ambos utilizan tcp.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 79

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 79

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 79

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 79

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 79

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 79

Cfingerd

Cfingerd (fingerd configurable) es un buen reemplazo del fingerd original, se construyó teniendo en cuenta la seguridad, normalmente se ejecuta como usuario no-root, y los usuarios lo pueden configurar con facilidad de modo que no se
les pueda hacer un finger. Cfingerd se encuentra disponible en:

http://ftp.bitgate.com/cfingerd/

PFinger

El PFinger es parecido al Cfingerd en la forma en que supone un reemplazo seguro del fingerd original. Se puede conseguir en:
http://www.xelia.ch/unix/pfinger/

Identd

El servicio identd se utiliza para mapear usuarios/procesos a puertos en uso.
Por ejemplo, la mayoría de los servidores irc intentan averiguar quién se está conectando a ellos haciendo una petición identd, lo cual consiste básicamente en preguntarle al servidor identd desde el ordenador cliente qué información

tiene sobre un número de puerto, y la respuesta puede varias desde ninguna (si nadie está utilizando ese puerto en particular) a un nombre de usuario, un nombre de grupo, un id de proceso y otra información interesante. La configuración por defecto de la mayoría de las distribuciones es que el identd está activado (es elegante ejecutarlo, los servidores de irc y las versiones más recientes de sendmail comprueban las respuestas de identd), y sólo distribuirán el nombre de usuario. El uso principal del identd es permitir a los sistemas remotos algún tipo de forma de seguir la pista de los usuarios que se están conectando a sus servidores, irc, telnet, correo, u otros, por propósitos de autentificación (no es una buena idea, ya que es muy fácil de falsear). La universidad local de Edmonton requiere que se ejecute el identd si se quiere hacer un telnet a cualquiera de los servidores de shell, principalmente de forma que puedan seguir con rapidez la pista de las cuentas comprometidas.

Ejecutar el identd en tu máquina ayudará a otros administradores a la hora de hacer el seguimiento de problemas, puesto que no sólo consiguen la dirección IP y la hora del problema, sino que utilizando identd pueden averiguar el nombre del usuario. Esta forma es una espada de doble filo, mientras que proporciona información útil para seguir a usuarios maliciosos (definitivamente la gente a la que se quiere mantener alejada de los servidores) también se puede utilizar para conseguir información de los usuarios del sistema, lo cual dé como resultado que sus cuentas sean comprometidas. Ejecutar identd en los servidores sólo tiene sentido si están albergando cuentas de shell.

Identd soporta bastantes características, y se puede configurar con sencillez para que se ejecute como usuario no-root. Dependiendo de las políticas de seguridad, se puede querer o no dar mucha información, o se puede querer informar lo máximo posible. Simplemente activa la opción en inetd.conf, después en in.identd (las configuraciones por defecto son –l –e –o).

-p port

-a address

Se puede utilizar para especificar a qué puerto y en qué dirección se enlaza (en el caso de una máquina con IP's en forma de alias, o a múltiples interfaces), generalmente sólo es útil si se quiere que conecten máquinas internas, puesto que a las máquinas externas probablemente no les sea posible imaginarse a qué puerto se cambió.

-u uid

-g gid

Se utilizan para configurar el usuario y el grupo bajo el que el identd tendrá privilegios después de conectar al puerto, lo cual da como resultado el ser menos susceptible de comprometer la seguridad del sistema. En cuanto al manejo de la cantidad de información que proporciona:

-o

Especifica que identd no devuelva el tipo de sistema operativo, decir Copyright © 1999, Kurt Seifried, José Antonio Revilla

simplemente "UNKNOWN" es una muy buena opción.

-n

Hará que identd devuelva números de usuarios (p.ej. su UID) y no el nombre de usuario, lo cual todavía les proporciona suficiente información para ti y para seguir la pista del usuario con facilidad, sin proporcionar valiosas pistas a posibles atacantes.

-N

Permite a los usuarios hacer crear un fichero ~/.noident , lo cual forzará que el identd devuelva "HIDDEN-USER" en lugar de información. Esto les permite a los usuarios la opción de tener un cierto grado de privacidad, pero un usuario malicioso lo utilizará para evadir la identificación.

-F format

Te permite especificar mucha más información que la standard, cualquier cosa desde el nombre y número del usuario hasta el PID real, nombre de comando, ¡y los argumentos dados! Esto sólo lo recomendaría para uso interno, puesto que es
mucha información que los atacantes encontrarían útil.

En general, recomendaría utilizar el identd en servidores con cuentas de usuario shell, o si no deshabilitarlo, principalmente debido al número de ataques de denegación de servicio a los que es susceptible. Ejecutar identd le hará la vida mucho más fácil a otros usuarios a la hora de seguir pistas provenientes de tu sitio, algunas con mejoras de seguridad (no lo aseguro todavía pues aún no he podido comprobarlo):

http://insecurity.net/ - El identd seguro de Paul, escrito en Perl

http://www.ojnk.un/~odin/ - ojnk identd

http://www.tildeslash.org/nullidentd.html - null identd

http://www.ajk.tele.fi/~too/sw/ - identd falso

http://p8ur.op.het.net/midentd/ - midentd

http://www.nyct.net/~defile/programs/ident2/ - ident2

Identd se ejecuta en el puerto 113 utilizando tcp, y por lo general sólo se necesitará si que quiere hacer IRC (muchas redes irc requieren una respuesta identd), o ser amable con los sistemas ejecutando demonios (tales como tcp_wrapped telnet, o sendmail) que hagan revisiones identd en las conexiones.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 113

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 113

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 113

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 113

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 113

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 113

NTPD

El NTP (Protocolo de Red de Tiempo, Network Time Protocol) es bastante simple en cuanto a su misión, mantiene sincronizados los relojes de los ordenadores. ¿Y qué? Intenta comparar ficheros de log desde 3 servidores separados si sus
relojes están fuera de sincronismo por unos cuantos minutos. El NTP funciona simplemente mediante un cliente que se conecta a un servidor de tiempo, averiguando el retraso entre ellos (en una red de área local podría ser de sólo
1-2ms, a través de internet puede ser de varios cientos de ms), y después pregunta la hora y configura el reloj propio. Además, los servidores se pueden colocar en "cluster" para mantenerse sincronizados entre ellos, las posibilidades de que 3 o más servidores pierdan la pista de la hora que es (también llamado "deriva", "drift" ) es relativamente baja.
Habitualmente, la señal de tiempo se suele generar por un reloj atómico o una señal GPS, medida por un ordenador, estos son los servidores "stratum 1", más abajo se indican servidores de tiempo "stratum 2" que se encuentran generalmente abiertos al público, una compañía podría mantener sus propios servidores de tiempo "stratum 3" si es lo suficientemente necesario, etcétera.

Los datos que intercambia el NTP por supuesto que no son sensibles, es una señal de tiempo, sin embargo, si a un atacante le fuese posible interferirla, podrían ocurrir todo tipo de cosas desagradables: los ficheros de log se podrían volver inutilizables, las cuentas podrían expirar antes de tiempo, los trabajos del cron que hacen la copia de seguridad del servidor se podrían ejecutar en hora punta causando retrasos, etc. De modo que es una buena idea ejecutar tu propio servidor de tiempo y configurar el ajuste máximo que harán a sólo unos pocos segundos (en cualquier caso, tampoco deberían derivar mucho más). Si se es realmente paranoico, o se tiene un gran número de clientes, habría que considerar comprar una unidad de tiempo GPS.

Vienen de todo tipo de formas y tamaños, desde un rack de 1Unidad que se enchufa directamente a la LAN hasta tarjetas ISA o PCI que se conectan en un servidor y tienen una antena. Es una buena idea filtrar con el cortafuegos el servidor de tiempo, puesto que podrían darse ataques de negación de servicio en detrimento de la red. Además de esto, si es posible, utilizar el cifrado disponible en ntpd, basada en DES, suele ser suficiente para desalentar a la mayoría de atacantes. El NTP se encuentra disponible en: http://www.eecis.udel.edu/~ntp/. Generalmente, ntpd o xntpd no suelen traer páginas de manual (genial, eh?) pero se puede encontrar documentación en /usr/doc/ntp-xxx/, o en:

http://www.eecis.udel.edu/~ntp/ntp_spool/html/index.htm.

NTP se ejecuta en el
puerto 123 utilizando udp y tcp, de modo que filtrarlo con el cortafuegos es relativamente sencillo:

ipfwadm –I –a accept –P udp –S 10.0.0.0/8 –D 0.0.0.0/0 123

ipfwadm –I –a accept –P udp –S un.host.fiable –D 0.0.0.0/0 123

ipfwadm –I –a deny –P udp –S 0.0.0.0/0 –D 0.0.0.0/0 123

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 123

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 123

o

ipchains –A input –p udp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 123

ipchains –A input –p udp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 123

ipchains –A input –p udp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 123

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 123

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 123

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/123

CVS
CVS permite trabajar juntos a múltiples desarrolladores en proyectos con enorme cantidad de código fuente, y mantiene una gran base de código en alguna parte de forma limpia. Los mecanismos internos de seguridad del CVS son bastante
simples por sí mismos; de hecho, si alguien dijera que son débiles, le tendría que dar la razón. La autentificación del CVS se suele conseguir a través de la red, utilizando pserver, los nombres de usuario se envían en texto claro, y las contraseñas tienen un hash trivial (en realidad no existe seguridad).

Para evitar esto, se cuenta con varias opciones buenas. En un entorno Unix, probablemente el método más simple sea utilizar SSH para pasar las conexiones por un túnel entre las máquinas clientes y el servidor. "Tim el PierdeTiempo" (Tim Hemel) ha escrito una excelente página ocupándose de esto, disponible en:

http://cuba.xs4all.nl/~tim/scvs/. Una aproximación algo más complicada (pero a la larga mejor en cuanto a grandes instalaciones) es "kerberizar" el servidor CVS y los clientes.

Las redes grandes (especialmente en entornos universitarios) ya han establecido una infraestructura con Kerberos. Detalles en la "kerberización" del CVS disponibles en: http://www.cyclic.com/cyclic-pages/security.html. Aparte de que
recomendaría encarecidamente filtrar con el cortafuegos el CVS, a menos que se esté utilizando para cualquier tipo de propósito público (como un proyecto de código abierto a través de Internet).

Otra herramienta que acaba de aparecer para asegurar CVS es "cvsd", un wrapper para pserver que hace chroot y/o suid el pserver al de un usuario no dañino.
cvsd se encuentra disponible en: http://cblack.mokey.com/cvsd/ en formato rpm y en tarball fuente.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 2401

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 2401

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 2401

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 2401

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 2401

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 2401


rsync

El rsync es un método extremadamente eficiente para hacer mirroring de ficheros, ya sea de ficheros de código desde un árbol CVS, un sitio web, o incluso este documento. rsync mantiene los permisos de ficheros, enlaces, hora de los ficheros y más. Además de esto, soporta modo anónimo (lo cual por cierto, utilizo para hacer el mirroring de este documento) lo cual hace la vida muy sencilla en lo concerniente.

El programa rsync puede actuar por sí mismo como cliente (se ejecuta desde una línea de comandos o un script) y como servidor (generalmente se ejecuta desde inetd.conf). El programa en sí es bastante seguro: no requiere privilegios de root para ejecutarse como cliente ni como servidor (aunque se puede hacer si se quiere) y se puede hacer chroot a sí mismo en el directorio raíz o cualquiera que esté siendo hecho mirror (sin embargo esto requiere privilegios de root y puede ser más peligroso de lo que merezca la pena).
También se puede mapear el id del usuario y el id del grupo con acceso al sistema (por defecto, es nobody para la mayoría de los paquetes de rsync precompilados y probablemente sea la mejor elección). En modo no-anónimo, rsync soporta nombres de usuarios y contraseñas que se cifran fuertemente utilizando MD4 de 128 bit. La página del manual "man rsyncd.conf" cubre claramente la configuración de un servidor rsync y lo hace relativamente seguro. El fichero de configuración por defecto es /etc/rsyncd.conf. Tiene una sección global y sección modular (básicamente cada directorio compartido es un módulo):

ejemplo de rsyncd.conf

motd file = /etc/rsync.motd # Especifica fichero a mostrar

etcmax connections = 5 # número máximo de conexiones, para evitar saturación

[pub-ftp]

comment = public ftp area # comentario simple

path = /home/ftp/pub # path al directorio exportado

read only = yes # hacerlo de sólo lectura, para directorios exportados

chroot = yes # chroot a /home/ftp/pub

uid = nobody # configurar explícitamente el UID

gid = nobody # configurar explícitamente el GID

[asuntos-secretos]

comment = mis asuntos secretos

path = /home/user/secretos # path a mis secretos

list = no # ocultar este módulo cuando pidan una lista

secrets file = /etc/rsync.users # fichero de contraseñas

auth users = me, bob, santa # lista de usuarios a los que se permite ver mis
secretos

hosts allow = 1.1.1.1, 2.2.2.2 # lista de hosts permitidos

Como se puede ver, el rsync es bastante configurable, y generalmente es
bastante seguro, excepción hecha de que las transiciones de ficheros no van
cifradas de ninguna forma. Si se necesita seguridad, sugeriría utilizar el SSH
para abrir una conexión mediante un túnel, o alguna solución VPN como
FreeS/WAN. Igualmente asegúrate de estar ejecutando rsync 2.3.x o una versión
más alta, ya que se encontró un compromiso de root en la 2.2.x. Rsync se
encuentra disponible en: http://rsync.samba.org/. Rsync se ejecuta en el puerto
873, tcp.

ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 873

ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 873

ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 873

o

ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 873

ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 873

ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 873