aca un mail de recomendación para los desarrolladores del núcleo de la lista de correo de LKML (es bueno también como recomendación para tener en cuenta para todos los días en la computadora de casa)

The compromise of kernel.org and related machines has made it clear that
some developers, at least, have had their systems penetrated.  As we
seek to secure our infrastructure, it is imperative that nobody falls
victim to the belief that it cannot happen to them.  We all need to
check our systems for intrusions.  Here are some helpful hints as
proposed by a number of developers on how to check to see if your Linux
machine might be infected with something:

0. One way to be sure that your system is not compromised is to simply
   do a clean install; we can all benefit from a new start sometimes.
   Before reinstalling any systems, though, consider following the steps
   below to learn if your system has been hit or not.

1. Install the chkrootkit package from your distro repository and see if it
   reports anything.  If your distro doesn't have the chkroot package,
   download it from:

http://www.chkrootkit.org/

   Another tool is the ossec-rootcheck tool which can be found at:

http://www.ossec.net/main/rootcheck

   And another one is the rkhunter program:

http://www.rootkit.nl/projects/rootkit_hunter.html

   [Note, this tool has the tendancy to give false-positives on some
   Debian boxes, please read /usr/share/doc/rkhunter/README.Debian.gz if
   you run this on a Debian machine]

2. Verify that your package signatures match what your package manager thinks
   they are.

   To do this on a rpm-based system, run the following command:
   	rpm --verify --all
   Please read the rpm man page for information on how to interpret the
   output of this command.

   To do this on a Debian based system, run the following bash snippet:
	dpkg -l \*|while read s n rest; do if [ "$s" == "ii" ]; then echo $n;
	fi; done > ~/tmp.txt
	for f in `cat ~/tmp.txt`; do debsums -s -a $f; done
   If you have a source-based system (Gentoo, LFS, etc.) you presumably
   know what you are doing already.

3. Verify that your packages are really signed with the distro's keys.

   Here's a bash snippet that can do this on a rpm based system to
   verify that the packages are signed with any key, not necessarily
   your distro's key.  That exercise is left for the reader:

	for package in `rpm -qa`; do
		sig=`rpm -q --qf '%{SIGPGP:pgpsig}\n' $package`
		if [ -z "$sig" ] ; then
			# check if there is a GPG key, not a PGP one
			sig=`rpm -q --qf '%{SIGGPG:pgpsig}\n' $package`
			if [ -z "$sig" ] ; then
				echo "$package does not have a signature!!!"
			fi
		fi
	done
   Unfortunately there is no known way of verifying this on Debian-based
   systems.

4. To replace a package that you find suspect, uninstall it and install
   it anew from your distro.  For example, if you want to reinstall the
   ssh daemon, you would do:
	$ /etc/init.d/sshd stop
	rpm -e openssh
	zypper install openssh	# for openSUSE based systems
	yum install openssh	# for Fedora based systems

   Ideally do this from a live cdrom boot, using the 'rpm --root' option
   to point rpm at the correct location.

5. From a liveCD environment, look for traces such as:
   a. Rogue startup scripts in /etc/rc*.d and equivalent directories.
   b. Strange directories in /usr/share that do not belong to a package.
      This can be checked on an rpm system with the following bash snippet:
	for file in `find /usr/share/`; do
		package=`rpm -qf -- ${file} | grep "is not owned"`
		if [ -n "$package" ] ; then
			echo "weird file ${file}, please check this out"
		fi
	done
6. Look for mysterious log messages, such as:
   a. Unexpected logins in wtmp and /var/log/secure*, quite possibly
      from legitimate users from unexpected hosts.
   b. Any program trying to touch /dev/mem.
   c. References to strange (non-text) ssh version strings in
      /var/log/secure*.  These do not necessarily indicate *successful*
      breakins, but they indicate *attempted* breakins which means your
      system or IP address has been targeted.

7. If any of the above steps show possible signs of compromise, you
   should investigate further and identify the actual cause.  If it
   becomes clear that the system has indeed been compromised, you should
   certainly reinstall the system from the beginning, and change your
   credentials on all machines that this machine would have had access
   to, or which you connected to through this machine.  You will need
   to check your other systems carefully, and you should almost
   certainly notify the administrators of other systems to which you
   have access.

Finally, please note that these hints are not guaranteed to turn up
signs of a compromised systems.  There are a lot of attackers out there;
some of them are rather more sophisticated than others.  You should
always be on the alert for any sort of unexpected behavior from the
systems you work with.

thanks,

Posteos relacionados:

• III Jornadas de Software Libre en la UNJU – San Salvador de Jujuy 2008
• Webcam Virtual para amsn
• Lanux reunión aniversario
• Linux 3.0.0 crash oflo_sw_cpu_clock_crash
• Auditoria y seguridad en SAP

Metodología o Checklist para auditar un sistema SAP

Hablando con varios amigos, sobre el problema que uno de ellos tenia para auditar un sistema SAP y al buscar para ayudarle con ese problema, nos dimos cuenta de la poca documentación existente para realizar un Pentesting de manera metódica en un sistema SAP, no encontramos fácilmente una guía o checklist a seguir para auditar efectivamente estos sistemas.

Aunque conocíamos buenas herramientas como Sapyto, un framework para auditoria de sistemas SAP del que ya habíamos hablado en la comunidad, y una excelente charla que dio Mariano Nuñez Di Croce, su creador, donde habla de pentesting a sistemas SAP, seguíamos sin encontrar una metodología a seguir, por eso decidimos preguntar en Twitter si alguien conocía alguna metodología para realizar un pentest en sistemas SAP y la respuesta fue tan buena que dio lugar a la creación de este post, donde pretendemos reunir en un solo lugar, los mejores recursos que puedas llegar a necesitar cuando realices una auditoria a sistemas SAP.

El primer recurso que les comparto es la charla de Mariano Niñez sobre Pentesting en Sistemas SAP:

En los aportes que nos realizaron se encuentra la Guía de Seguridad para sistemas SAP NetWeaver, pero también unas directrices para auditar SAP ECC creado en el 2009 por Nishant Sourabh un empleado de IBM, que eran justo lo que necesitábamos:

Descarga las directrices para auditar SAP ECC de este enlace

Pero también documentación creada por la misma SAP con lineamientos para auditar SAP R/3 que nos ayudaran mucho en la tarea de auditar sistemas SAP.

Descarga los lineamientos para auditar SAP R/3 creados por SAP

En español encontramos un portal dedicado enteramente a la seguridad SAP llamado SeguridadSAP.com, el cual recomendamos totalmente desde La Comunidad DragonJAR, también agradecemos Space Cowboy (@EspeisCouboi) y Alberto Hil (@bertico413), por su colaboración.

Si tienes mas aportes en esta materia dejalos en los comentarios, para que juntos construyamos un buen listado de recursos para auditar sistemas SAP.

y tambien :

SAPYTO – Framework para realizar Penetration Tests sobre sistemas SAP

Sapyto SAP R/3 Pentest Tool es un Framework para realizar Penetration Tests sobre sistemas SAP. Permite que profesionales de seguridad lleven a cabo analisis de seguridad de diferentes componentes de implementaciones de SAP R/3.

Sapyto fue Presentado en Blackhat Europe 2007, fue liberado con varios modulos para analizar la seguridad de la implementacion de la interfaz RFC de los sistemas SAP. La arquitectura modular permite que los usuarios desarrollen sus propios modulos, extendiendo la funcionalidad y permitiendo que el Framework detected nuevas vulnerabilidades. Esta herramienta ha sido escrito en Python.

Descargar SAPYTO
Fuente del recurso: CRYPTEX

Tambien enlaces como

Proyecto Inguma

Proyecto Mantra

Aca el link de SAP http://help.sap.com/saphelp_nw04/helpdata/en/ed/18cc38e6df4741a264bddcd4f98ae2/frameset.htm

y los archivos de documentación oficial de SAP y seguridad los subi aca en cayu en la url

http://cayu.com.ar/files/sap/

SAPYTO http://www.cybsec.com/EN/research/sapyto.php

ah y recomendado bajarse los pdf de los slides de Mariano Nuñez en las diferentes ekopartys

POST Original : http://www.dragonjar.org/metodologia-o-checklist-para-auditar-un-sistema-sap.xhtml

ah y no nos olvidemos de usar los plugins de SAP CCMS para Nagios yo hasta ahora los vengo usando desde hace 4 años y tuve buenos resultados, y bueno tener bien armado el contexto de monitoreo y log centralizado

Posteos relacionados:

• Vuelve Kernel.org (parcialmente)
• III Jornadas de Software Libre en la UNJU – San Salvador de Jujuy 2008

III Jornadas de Software Libre en la UNJU – San Salvador de Jujuy

Hace poco pasaron las Jornadas de Software Libre en la Universidad Nacional de Jujuy, en la cuales tuve el honor de participar como disertante.

En las mismas se a convocado a diferentes exponentes del Software Libre que venian de diferentes puntos del pais. Cada uno exponia sobre una tematica diferente, Filosofia del Software Libre, temas tecnicos, programacion, tutoriales, seguridad entre otros. Precisamente stas Jornadas se destacaron porque hubo una variedad de temas muy amplia de temas.

Ademas en lo que refiere a nivel tecnico se destaco en gran manera por la ultimas charlas de seguridad donde se estudiaron y probaron Buffer Overflows, Rootkits, Exploits, SQL Inyeccion y demas cosas todas con su metodo practico de aplicacion je

Para comenzar parti desde Buenos Aires con destino a Jujuy un viaje largo se podria decir, al llegar de dia el Jueves a la tarde fui recibido en la terminal por Cesar, de ahi parti para el Hotel a dejar las cosas, luego fuimos a tomar algo a un cafe local frente a la plaza principal donde ya estaban alli Carolina y Ezequiel

Luego en la Facultad de Ingenieria nos recibio muy amablemente el Decano y estuvimos hablando un rato de lo que iban a ser las Jornadas.

Luego recorrimos parte del centro, la plaza, la peatonal y la casa de gobierno en la cual hay un museo historico sobre la bandera de Belgrano y muchas cosas interesantes, luego visitamos la catedral y otra iglesia historica tambien.

Luego al hotel a enganchar redes WiFi por la zona, cabe destacar que todo el centro de Jujuy esta cubierto de WiFi, asi que geeks, quedensen tranquilos y vayan a Jujuy :p

Y de ahi fuimos a comer un restaurant de la zona

Al otro dia temprano comenzamos las jornadas en el auditorio de la facultad de ingenieria, la concurrencia habra sido de una 120% de lo que soporta la sala

El Decano realizo la apertura del evento y se dio por comenzada la Jornada

El viernes a las 10 am me toco disertar a mi

Estaba repleto el auditorio

bueno luego de las demas charlas segui filmando :p

luego nos fueron entregando los certificados de expositores

El evento fue muy dinamico, hubo buen humor, debate. Ademas la cobertura de los medios locales como algunos diarios y afiches por toda la Universidad ayudo mucho en la asistencia.

Aqui la mayoria de los disertantes

aqui de nuevo casi todos

aqui con parte de la organizacion

a mi lado de izquierda y derecha estan mis dos anfitriones Cesar y Carolin

que me llevaron a recorrer la ciudad y estuvieron pendientes de cada uno de los que participamos

Sin duda la charla que mas entretuvo fue la de seguridad de los Chicos del Chaco

luego de cerradas las jornadas se realizo un installfest

y muy concurrido por cierto

aca con el Tux de las Jornadas

El sitio oficial del evento http://www.fi.unju.edu.ar/jornadas/

La fotos del evento http://picasaweb.google.com/cayuqueo/IIIJornadasDeSoftwareLibreEnLaUNJU

Mi vision personal del evento :

Fue muy activo, el tipo de publico que estuvo presente, espectante escuchaba cada charla, en su mayoria fueron estudiantes de ingenieria de la facultad, despues habia docentes, estudiantes de humanidades, independientes, interesados en el tema etc. Luego la organizacion, todos pendientes de todo y cada uno en su área, durante mi estadia y la estadia de todos estuvieron pendientes de como estabamos y que necesitabamos. Todos pusieron lo mejor de su parte y el nivel fue excelente.

Despues prometo los videos tengo que ver como recortarlos son algo asi como 32 GB de datos :-p

Posteos relacionados:

• IV Jornadas de Software Libre en la UNJU y RMS en Bs As
• IV Jornadas de Software Libre de la UNJU
• Asi fue Conurbania 2010
• Conurbania 2009 – conferencias sobre Software Libre en el conurbano bonaerense
• Barcamp Litoral 2011 un éxito