Publicado el Dejar un comentario

Configurar una tarjeta de red con WPA desde la línea de comandos en Ubuntu

configurar una tarjeta de red con WPA desde la línea de comandos

En mi oficina, tengo una vieja laptop a la cual, el monitor de cuando en cuando deja de funcionar sin forma de volver a encenderlo nuevamente. Con ello en consideración, decidí tomar esta laptop para configurarme un modesto servidor conUbuntu Server 14.04 LTS en el cual tengo habilitado Apache, PHP y MySQL principalmente con la cual te mostraré cómo conigurar una tarjeta de red con WPA desde la línea de comandos en Ubuntu.

Es pertinente comentar en este que punto que para el presente tutorial, procedí a realizar una instalación limpia de Ubuntu Server 14.04, configuré mi tarjeta de red, particiones y demás, pero al concluir el proceso de reinicio posterior a la instalación.

Así, para lograr que Ubuntu “inicie” y se “conecte” automáticamente a una red WPA, tenemos que seguir los siguientes pasos desde la consola o línea de comandos:

1.- Averiguamos en primer lugar el nombre de nuestra interface de red inalámbrica (generalmente es wlan0):

iwconfig

2.- Creamos el archivo de configuración del demonio de administración de redes wpa_supplicant…

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

…y guardamos dentro del mismo los siguientes valores:

ctrl_interface=/var/run/wpa_supplicant
network={
ssid="NOMBRE-DE-RED-WIFI"
key_mgmt=WPA-PSK
psk="CONTRASEÑA-WIFI"
}

3.- Ahora, iniciamos el demonio wpa_supplicant mediante el siguiente comando:

sudo wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -B

4.- “Levantamos” nuestra tarjeta de red…

sudo ifconfig wlan0 up

5.- Pedimos ahora una dirección IP al servidor DHCP activo:

sudo dhclient wlan0

6.- Con ello, si hacemos un ping a google.com, deberías de obtener ya una respuesta. Pero bien, para que nuestra configuración se cargue en cada reinicio, abrimos el archivo /etc/network/interfaces…

sudo nano /etc/network/interfaces

…y nos aseguramos de añadir lo siguiente:

auto wlan0
iface wlan0 inet dhcp
wpa-ssid NOMBRE-DE-RED-WIFI
wpa-psk CONTRASEÑA-WIFI

7.- Para comprobar que el demonio wpa_supplicant se iniciará automáticamente en cada inicio del sistema, ejecutamos los siguientes comandos:

sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start

¡Y es todo!

Si deseas profundizar mucho más en el tema u obtener información para realizar un proceso similar para redes WEP, te recomiendo hacer clic en este enlace, el cual te llevará a un excelentísimo artículo que habla con gran detalle sobre este proceso.

Publicado el Dejar un comentario

Infografía de la misión Apolo 11 y el viaje a la luna

Un 16 de julio como hoy, pero del año 1969, en punto de las 12:32:00 hrs., dio inicio la misión definitiva que hizo posible la hazaña de posicionar al primer ser humano en la luna: la misión Apolo 11.

En este sentido, y teniendo en consideración que el 21 de julio de 1969 a las 2:56:00 hrs. (hora international UTC), el Instituto Smithsoniano, un centro de investigación y educación estadounidense que cuenta con una influyente red de museos, estará recordando y conmemorando este “pequeño salto para el hombre, pero un gigantesco salto para la humanidad” mediante el cual Neil Armstrong logró pisar por primera vez nuestro satélite, en compañía de Buzz Aldrin y Michael Collins.

Para ello, comparto en este espacio, una interesantísima infografía desde la cual podrás realizar un recorrido guía sobre la línea de tiempo en torno a los principales hitos que tuvo esta historia. Muy recomendable para recordar y conmemorar este singular evento.

La liga directa a este material imperdible es: https://airandspace.si.edu/amp-stories/journey-and-spacecraft/

Fly me to the moon, journey to the moon and back.

Si deseas saber más, te sugiero visitar:

Publicado el Dejar un comentario

Bloquear accesos por país con Firewall CSF

Bloquear accesos por país con Firewall CSF

Para todos aquellos que en algún momento tengan la necesidad de desarrollar actividades de administración de un servidor Web bajo GNU/Linux, descubrirán que Internet es un entorno más que propicio tanto para la colaboración o distribución de contenidos, como también, para prácticas maliciosas o ataques informáticos por lo que seguramente te resultará de gran utilidad el aprender a bloquear accesos por país con firewall CSF.

En este sentido, les comento que en mi práctica profesional, y concretamente, para el caso de una tienda en línea administrada con Magento, comencé a notar una baja en el performance impresionante, al punto tal en que las peticiones al servidor, se resolvían muy lentamente.

En este contexto, una solución “rápida” y “lógica” era incrementar los recursos del VPS contratado (más memoria RAM, más procesador), con el respectivo costo asociado.

Al revisar los logs de Apache (siempre es una buena práctica, algo tediosa) y las estadísticas del sitio en mi panel de control (con AW Stats o Webanalizer) y las visitas de Google Analytics, descubrí que tenía visitas en varias horas del día, y con distinta intensidad, del robot del buscador Chino llamado Baidu.

Con esta información en consideración, mi primer “movimiento” lógico, fue deshabilitar la indexación del agente/bot Baidu en el home de mi servidor, pero, el problema persistía: Baidu maneja diversos agentes (de contenidos, de imágenes, de video, etc.) para indexar un sitio, y para serles francos, aún y cuando Baidu tiene documentadas las medidas para el manejo de sus bots mediante el archivo robots.txt (puedes consultarlas aquí: http://help.baidu.com/question?prod_en=master&class=498&id=1000973), me dio la impresión de que sus bots no respetaban las instrucciones contenidas en el mismo, por lo cual, teniendo en consideración que el público de la tienda en línea era solo mexicano, procedí a realizar un bloqueo mediante reglas de un Firewall basado en software, inicialmente a China, con posibilidades de extenderlo a todo el mundo y permitir solo IP´s de México y Estados Unidos. Es importante destacar que Baidu, tiene una “página” en la cual uno puede “retroalimentar” y reportar incidentes; la liga es: http://webmaster.baidu.com/feedback/index. Aquí puedes encontrar más información sobre el “bloqueo” a Baidu Spider mediante el archivo robots.txt: http://www.baidu.com/search/robots_english.html

Consideraciones

Este “truco” te funcionará si tienes una distribución Linux en la cual tengas acceso como root o usuario con privilegios. Si tienes un VPS, asegúrate que si realizas por accidente un “bloqueo” a la IP desde la cual te conectas, podrás acceder nuevamente mediante una terminal o consola Web que te ofrezca tu propio proveedor.

Primeros pasos

CSF (ConfigServer Security & Firewall), es un poderoso conjunto de scripts que nos permiten disponer reglas de iptables para constituir un Firewall SPI (Stateful Packet Inspection) basado en software, con detector de intrusiones y seguridad en aplicaciones para servidores Linux.

Si actualmente tienes reglas de IPtables aplicadas en tu server, es muy probable que vayas a tener conflicto con las mismas, por lo cual, es muy probable que decidas qué solución de Firewall pretendes usar, o bien, analizar si CSF puede hacer por tí lo que actualmente estás haciendo con otra solución. Desde mi punto de vista personal, CSF es uno de los Firewalls para servidores Linux más potentes, transparentes y sencillos de usar que he visto.

Puedes conocer más a fondo las características de CSF visitando este link: http://configserver.com/cp/csf.html

Para este tutorial, estaré trabajando sobre Ubuntu Server 14.04.01 de 64 Bits.

De igual manera, la documentación oficial para la instalación de CSF la puedes encontrar aquí: http://download.configserver.com/csf/install.txt

Comentado lo anterior, primero vamos “actualizar” un poco algunas dependencias y paquetes de Perl requeridos:

sudo apt-get install libwww-perl liblwp-protocol-https-perl

Posteriormente, vamos a proceder a descargar y descomprimir el conjunto de scripts de CSF mediante el siguiente comando:

cd /usr/src
sudo wget https://download.configserver.com/csf.tgz
sudo tar -xzf csf.tgz

Ahora, procedemos a realizar la ejecución del script de instalación de CSF:

cd csf
sudo sh install.sh

Si no ha habido mayores problemas, podrás leer en tu pantalla algo como esto:

TCP ports currently listening for incoming connections:
     22

UDP ports currently listening for incoming connections:
     68,45861

Note: The port details above are for information only, csf hasn't been auto-configured.

Don't forget to:
     1. Configure the following options in the csf configuration to suite your server: TCP_*, UDP_*
     2. Restart csf and lfd
     3. Set TESTING to 0 once you're happy with the firewall, lfd will not run until you do so
     «lfd.sh» -> «/etc/init.d/lfd»
     «csf.sh» -> «/etc/init.d/csf»
     el modo de «/etc/init.d/lfd» permanece como 0755 (rwxr-xr-x)
     el modo de «/etc/init.d/csf» permanece como 0755 (rwxr-xr-x)
     Removing any system startup links for /etc/init.d/lfd ...
     Removing any system startup links for /etc/init.d/csf ...
     Adding system startup for /etc/init.d/lfd ...
     /etc/rc0.d/K20lfd -> ../init.d/lfd
     /etc/rc1.d/K20lfd -> ../init.d/lfd
     /etc/rc6.d/K20lfd -> ../init.d/lfd
     /etc/rc2.d/S80lfd -> ../init.d/lfd
     /etc/rc3.d/S80lfd -> ../init.d/lfd
     /etc/rc4.d/S80lfd -> ../init.d/lfd
     /etc/rc5.d/S80lfd -> ../init.d/lfd
     Adding system startup for /etc/init.d/csf ...
     /etc/rc0.d/K80csf -> ../init.d/csf
     /etc/rc1.d/K80csf -> ../init.d/csf
     /etc/rc6.d/K80csf -> ../init.d/csf
     /etc/rc2.d/S20csf -> ../init.d/csf
     /etc/rc3.d/S20csf -> ../init.d/csf
     /etc/rc4.d/S20csf -> ../init.d/csf
     /etc/rc5.d/S20csf -> ../init.d/csf
     «/etc/csf/csfwebmin.tgz» -> «/usr/local/csf/csfwebmin.tgz»

Installation Completed

Lo que debemos saber

CSF es una colección de scripts muy potente, que en un momento determinado, puede inclusive “impedirnos” la conexión remota al servidor si no tenemos muy claro lo que hacemos.

En este sentido, la ruta para la edición de su archivo de configuración, es:

/etc/csf/csf.conf

Dentro del mismo, tenemos 2 líneas que son muy interesantes:

  1. TESTING = “1” – Si está activida esta regla así, es porque tu Firewall está en “modo de prueba” con lo cual, en función del valor asignado en el siguiente punto (testing_interval), pasado ese tiempo, te “borrará” todas las reglas de Firewall con el propósito de “regresar” a la normalidad. En otro caso, si has quedado conforme con la configuración de Firewall, puedes ponerle el valor de “0”, con lo cual, quedará aplicado este sistema.
  2. TESTING_INTERVAL = “5” – Si las reglas de Firewall están en modo de prueba (testing), pasado número de minutos, se “limpiarán” del sistema, volviendo todo a la normalidad.

Bloquear accesos por país con firewall CSF y asignación de permisos de conexiones por país

Particularmente, CSF utiliza los 2 caracteres de país del código ISO de países CIDR (Classless Inter-Domain Routing – enrutamiento entre dominios sin clases) mediante el cual, se “clasifican” los rangos de direcciones IP de cada país. Como comenta CSF en el archivo de configuración, esta lista no es 100% segura ya que algunos ISPs, usan designaciones de IP para sus clientes mediante criterios no geográficos, lo cual dificulta su ubicación.

Por otra parte, la creación de reglas asociadas a grandes rangos de direcciones IP, pueden representar una disminución en el performance del servidor, con lo cual, no es muy recomendado para servidores VPS; aunque en mi caso, lo he usado en VPS de 1 GB de RAM y me fue muy bien, inclusive, me ayudó con tráfico indeseado.

Con ello en consideración, CSF se apoya en los 2 caracteres de país para la asignación en las reglas de Firewall, a partir de los bloques CIDR administrados por Maxmind GeoLite Country, el cual puedes consultar aquí: http://dev.maxmind.com/geoip/legacy/geolite/ (te sugerimos descargar el archivos CSV disponible para crear tus reglas con mayor seguridad y certeza).

Ahora bien, ¿qué haré? Permitiré el tráfico a México y Estados Unidos, y bloquearé al resto del mundo. Para ello, deberemos editar el archivo de configuración de CSF:

sudo nano /etc/csf/csf.conf

Ahora, buscamos las líneas:

CC_DENY = ""
CC_ALLOW = ""

Y nos aseguramos que queden algo así como:

CC_DENY = "AU,CN,JP,TH,IN,MY,KR,SG,HK,TW,PH,VN,RU,FR,EU,DE,IL,SE,IT,NL,GR,ES,AT,GB,BE,AE,KZ,PT,SA,DK,IR,NO,CA,SY,UA,CY,CZ,CH,IQ,TR,RO,BZ,PA,BR,CL,AR,CO,PL,LB,GE,AZ,A2,PS,LT,OM,SK,RS,FI,IS,HU,BG,SI,MD,MK,LI,JE,HR,BA,PY,EE,LV,JO,A1,KG,RE,IE,IM,LY,LU,AM,VG,YE,BY,GI,QA,KW,GP,MQ,GF,ZA,EG,ID,PK,DO,GU,VI,PR,MN,NZ,NP,PG,AP,CR,PE,NG,VE,BS,MA,SC,BB,KE,BN,BH,AW,LC,BD,TK,KH,MO,MV,AF,NC,FJ,WF,AL,UZ,ME,KP,VA,AQ,BM,CW,EC,KN,WS,GG,MT,TJ,ZW,LR,GH,TZ,ZM,MG,AO,NA,CI,SD,CM,MW,MU,GA,ML,BJ,TD,BW,CV,RW,CG,UG,MZ,GM,LS,DZ,GN,CD,SZ,BF,SL,SO,NE,CF,TG,BI,GQ,SS,SN,MR,DJ,KM,TN,YT,LA,MM,LK,NR,VU,BT,FM,PF,TL,TO,ER,ET,TM,GL,KY,JM,GT,MH,MC,AI,GD,MS,TC,AG,TV,SB,BO,SR,CK,NU,TF,NF,PN,SM,AX,FO,SJ,CC,GS,UM,SX,GW,MF,VC,PM,BL,DM,ST,FK,MP,BQ,AS,KI,PW,GY,HN,NI,SV,AD,HT,TT,UY,CU,SH,CX,IO"
CC_ALLOW = "MX,US"

Ahora, guardamos el archivo, y reiniciamos el CSF:

sudo csf -r

Y revisamos las reglas aplicadas:

sudo iptables -L -n

Pasos finales

Por otra parte, con el objetivo de que nuestro Firewall tome acciones a partir de “falsos positivos” o “información confusa” proporcionada por los registros del sistema (syslog/rsyslog), en el archivo /etc/csf/csf.conf, debemos cambiar esto:

# 0 = Allow those options listed above to be used and configured
# 1 = Disable all the options listed above and prevent them from being used
# 2 = Disable only alerts about this feature and do nothing else
# 3 = Restrict syslog/rsyslog access to RESTRICT_SYSLOG_GROUP ** RECOMMENDED **
RESTRICT_SYSLOG = "0"

Por esto:

# 0 = Allow those options listed above to be used and configured
# 1 = Disable all the options listed above and prevent them from being used
# 2 = Disable only alerts about this feature and do nothing else
# 3 = Restrict syslog/rsyslog access to RESTRICT_SYSLOG_GROUP ** RECOMMENDED **
 RESTRICT_SYSLOG = "3"

Con lo anterior, evitarás también “molestas” alertas del tipo:

*WARNING* RESTRICT_SYSLOG is disabled. See SECURITY WARNING in /etc/csf/csf.conf.

Goodie

CSF es un estupedísimo Firewal; para el caso de este material, podría decir que no está reservado solamente para “bloquear” rangos de IP´s de países sino para implementar un cortafuego por software a tu computadora o servidor.

Por ello, si modificas, en el siguiente conjunto de líneas, puede “decidir” qué puertos deseas mantener abiertos y en qué dirección:

# Allow incoming TCP ports
TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995"

# Allow outgoing TCP ports
TCP_OUT = "20,21,22,25,53,80,110,113,443,587,993,995"

# Allow incoming UDP ports
UDP_IN = "20,21,53"

# Allow outgoing UDP ports
# To allow outgoing traceroute add 33434:33523 to this list
UDP_OUT = "20,21,53,113,123"

…e inclusive, si permitirás que hagan “ping” a tu equipo:

# Allow incoming PING
ICMP_IN = "1"

Si has despertado la curiosidad con respecto a las capacidades de CSF, te recomendamos encarecidamente dar un vistazo a todo el fichero de configuración para hacer pruebas y descubrir sus posibilidades. ¡Te encantará! Cpanel lo integra generalmente a través de WHM, lo cual nos “garantiza” en cierto sentido su mejora y mantenimiento constante.

Nota final

Si al aplicar tus reglas de Firewall con CSF te aparece el mensaje de error:

*WARNING* URLGET set to use LWP but perl module is not installed, reverting to HTTP::Tiny

Es probable que te hayas olvidado de instalar paquetes de Perl de apoyo, con lo cual, solo hace falta instalar un módulo faltante mediante lo siguiente:

sudo apt-get install libwww-perl liblwp-protocol-https-perl

¿Qué pasa en este punto? Según comentan en algunos sitios, CSF implementó el procesamiento de peticiones para HTTP y HTTPS, con lo cual, el modelo LWP::UserAgent procesa muchísimo mejor HTTPS que el modelo HTTP::Tiny.

Si quisieramos evitar usar LWP, hay que buscar la línea:

# "1" = HTTP::Tiny
# "2" = LWP::UserAgent
URLGET = "2"

Y dejarla en algo como esto:

# "1" = HTTP::Tiny
# "2" = LWP::UserAgent
URLGET = "1"
Publicado el Dejar un comentario

Análisis de logs de Apache con Scalp!

Análisis de logs de Apache con Scalp!

En temas de seguridad y protección de servidores, no existe nada mejor que proteger los mismos con aplicaciones de detección de intrusiones como Snort (https://www.snort.org/) o Suricata (http://suricata-ids.org/) u otras ofertas comerciales basadas tanto en hardware (firewalls) como Software (http://www.acunetix.com/) o servicios en la nube (https://www.cloudflare.com/) que actualizan con mayor regularidad sus bibliotecas y/o diccionarios de ataques, y están “más preparados” ante estas amenazas de la red Internet, por los que reaizar análisis de logs de Apache con Scalp! es una fantástica idea para prevenir y/o anticipar amenazas.

En esta ocasión les comparto un analizador de Logs muy sencillo, el cual propiamente, no es el más recomendado para “prevenir” ataques a un servidor Apache sino que más bien, su propósito es el de analizar potenciales huecos de seguridad o vulnerabilidades apoyándose de los registros (logs) que ha dejado atrás Apache para detectar aquellas áreas de oportunidad, mejora, e inclusive, vulnerabilidades propias de sistemas o aplicaciones desarrollados en PHP.

Scalp!, es un script analizador de logs del servidor Apache desarrollado en Phyton, que tiene como objetivo buscar problemas de seguridad. Su idea principal, es “leer” dentro de los registros de accesos al servidor para buscar patrones ataques potenciales mediante el envío de peticiones por los métodos HTTP/GET y HTTP/POST.

El sitio Web oficial de Scalp! es https://code.google.com/p/apache-scalp/.

Primeros pasos

Para los propósitos de este post, he de comentar que estoy realizando pruebas sobre Ubuntu Server 14.04. En este caso, tengo una instalación con Apache 2, PHP5 y MySQL para un servidor Web, en donde mis “logs”, se encuentran dentro del directorio /var/logs/apache2/access.log.

Con esto en consideración, lo primero que tenemos que hacer, es “descargar” el script de Scalp! en nuestro directorio favorito:

wget https://apache-scalp.googlecode.com/files/scalp-0.4.py

(Nota: te sugiero que visites regularmente la página de Scalp! para descargar la última versión actualizada).

Ahora, descargamos el archivo de expresiones regulares que utiliza PHP-IDS (otra estupenda herramienta para proteger a nuestras aplicaciones PHP) para combinarlo en su uso con Scalp! mediante el siguiente comando:

wget https://dev.itratos.de/projects/php-ids/repository/raw/trunk/lib/IDS/default_filter.xml --no-check-certificate

Ahora bien, con estos dos archivos descargados, vamos a hacer nuestro primer análisis de logs:

python scalp-0.4.py -l /var/log/apache2/access.log default_filter.xml -o scalp-output --html

En este caso, al ejecutar Scalp! por primera vez, me arrojó este mensaje de error:

The directory %s doesn't exist, scalp will try to create it
 Loading XML file 'default_filter.xml'...
 The rule '(?i:(\%SYSTEMROOT\%))' cannot be compiled properly

“Tuneando” nuestro fichero de patrones

Con respecto a la primera y segunda línea de error, no tenemos mayor problema. Más bien, el detalle que tenemos que resolver es que al parecer Phyton, no es capaz de “procesar” correctamente parte del contenido XML que descargamos de PHP-IDS. Para ello, la solución es muy sencilla, abrimos el archivo default_filter.xml con nuestro editor favorito:

nano default_filter.xml

Y alrededor de la línea 741, hay que cambiar (referencia: https://code.google.com/p/apache-scalp/issues/detail?id=8) esto:

(?i:(\%SYSTEMROOT\%))

…por esto:

(?:(\%[sS][yY][sS][tT][eE][mM][rR][oO][oO][tT]\%))

Iniciando Scalp!

Con lo anterior, guardamos los cambios, y volvemos a ejecutar el comando de Scap!

python scalp-0.4.py -l /var/log/apache2/access.log default_filter.xml -o scalp-output --html

A continuación, les aparecerá un mensaje como este, ante el cual, solo tenemos que esperar un poco (en función del tamaño de archivo de tu log o de las reglas que hayas pedido ejecutar):

Loading XML file 'default_filter.xml'...
 Processing the file '/var/log/access.log'...
 Scalp results:
 Processed 491229 lines over 491413
 Found 3175 attack patterns in 177.725208 s
 Generating output in scalp-output/access.log_scalp_*

Ahora, solo tienes que ir al directorio scalp-output y “visualizar” en tu navegador en archivo generado para visualizar el reporte completo de patrones de ataque observados.

¡Esta herramienta es genial!

Goodie

Tecleando el comando:

python scalp-0.4.py --help

…podrás obtener la ayuda relacionada con otros patrones de uso de Scalp!.

Scalp the apache log! by Romain Gaucher - http://rgaucher.info
 usage: ./scalp.py [--log|-l log_file] [--filters|-f filter_file] [--period time-frame] [OPTIONS] [--attack a1,a2,..,an]
 [--sample|-s 4.2]
 --log |-l: the apache log file './access_log' by default
 --filters |-f: the filter file './default_filter.xml' by default
 --exhaustive|-e: will report all type of attacks detected and not stop
 at the first found
 --tough |-u: try to decode the potential attack vectors (may increase
 the examination time)
 --period |-p: the period must be specified in the same format as in
 the Apache logs using * as wild-card
 ex: 04/Apr/2008:15:45;*/Mai/2008
 if not specified at the end, the max or min are taken
 --html |-h: generate an HTML output
 --xml |-x: generate an XML output
 --text |-t: generate a simple text output (default)
 --except |-c: generate a file that contains the non examined logs due to the
 main regular expression; ill-formed Apache log etc.
 --attack |-a: specify the list of attacks to look for
 list: xss, sqli, csrf, dos, dt, spam, id, ref, lfi
 the list of attacks should not contains spaces and comma separated
 ex: xss,sqli,lfi,ref
 --output |-o: specifying the output directory; by default, scalp will try to write
 in the same directory as the log file
 --sample |-s: use a random sample of the lines, the number (float in [0,100]) is
 the percentage, ex: --sample 0.1 for 1/1000

Si te interesa el tema, aquí puedes encontrar un estupendo artículo (en inglés) sobre una comparativa entre Snort y Suricata, los IDS (intrusion detection system) Open Source más populares. La liga es: http://wiki.aanval.com/wiki/Snort_vs_Suricata

Publicado el Dejar un comentario

ThingLink

ThingLink es una plataforma para la creación de gráficos interactivos, la cual está preparada para su integración en redes sociales. Particularmente, solo debemos cargar una imagen para comenzar a crear “etiquetas” las cuales, pueden contener texto, imagenes, video, audio y links, principalmente.

La versión gratuita es muy funcional; no obstante, la versión de paga te permite la integración y personalización de tus interacciones mediante el uso de otro tipo de recursos como iconos y analítica de datos.

Es una plataforma ideal para presentar tareas, productos, servicios, etc. ¡La imaginación es el límite!

En todo caso, pueden crear una cuenta en: http://www.thinglink.com/

A continuación, podrán ver algunos ejemplos de interacciones que he desarrollado en la plataforma.

Publicado el Dejar un comentario

Sponsors of Tomorrow

Este año, Intel ha tenido la fantástica idea de lanzar un campaña publicitaria llamada “Sponsors of Tomorrow” que, para los que nos encontramos involucrados en la cultura hacker, explorando horizontes y buscando de soluciones tecnológicas simples para la vida cotidiana de las personas, nos permite dibujarnos una gran sonrisa, recordar quiénes somos e inspirarnos para ser mejores cada día. En el primer spot, con mucho humor Intel nos presenta a Ajay Bhatt, co-inventor del puerto USB (el estándar) como un rockstar de la ingeniería. Disfruta la lista completa de videos de la serie de Intel Sponsors of Tomorrow, ¡que la disfrutes!

Publicado el Dejar un comentario

Yellow Dog Linux en una iMac G3

El día de hoy, recuperé una memoria USB en la cual tengo varios screenshots, documentos y curiosidades que vengo guardando de hace algunos años. Así pues, encontré algunas capturas de pantalla y fotografías de cuando, hace aproximadamente unos 5 años, instalé Yellow Dog Linux 2 Pomona en un iMac G3 a 233 mhz con 32 MB de memoria RAM. La verdad, KDE corría lentísimo, pero vale, queda para la historia, y como mera curiosidad: Linux funciona casi donde sea y con los recursos que sean.

yellow dog linux
Aquí, iniciando el sistema operativo…
Aquí, iniciando el escritorio KDE…
…y aquí puedes ver los recursos de la iMac G3 de mi distro Yellow Dog Linux para Mac.

Publicado el Dejar un comentario

Requiem por un desarrollador

Hago el Requiem por un desarrollador debido a que el día de ayer, se hizo eco en algunos blogs especializados y servicios de noticias, un ataque de día cero en contra de algunos proveedores de Hosting (y la triste historia de un desarrollador) que ofrecían servidores VPS (servidores privados virtuales dedicados) que utilizaban el panel de control LxAdmin e HyperVM para administrar planes con Xen y OpenVZ de la empresa hindú LxLabs.

Requiem por un desarrollador, LXLabs, Kloxo

El resultado: más de 100,000 sitios web destruidos junto con sus respectivos backups. La empresa que más afectada se vio con esta situación, fue la Vaserv.com junto con sus compañías CheapVPS y FSCKVP.

Por otra parte, se reportó que tan solo horas después del incidente, el genio desarrollador del entorno de administración de servidores VPS, creador y dueño de LxLabs, K.T. Ligesh se suicidó sin más, presumiblemente aquejado, por el desastre ocasionado, derivado de la vulnerabilidad usada en su aplicación.

desarrollador fundador de LxLabs.com, creador de HyperVM y de la solución LxAdmin/Kloxo llamado K.T. Ligesh.

En días anteriores, LxLabs había comentado que tenían reportes de contar con más de 30 000 servidores VPS en el mundo administrados con HyperVM, y más de 8 mil trabajando con Kloxo, otra plataforma de hosting de su creación. ¿Por qué era tan popular HyperVM? Sencillamente, por su extraordinario manejo de los recursos de memoria y procesamiento que permite que tan solo Kloxo, funcione sin problema alguno con 15 MB de memoria. En verdad, ésta compañía ofrecía un sistema de administración de servidores a un muy pero muy bajo costo, comparado con los precios de un servidor dedicado.

Caramba, la verdad, ufff, poco se puede hacer en situaciones así; sucesos que en verdad, están más allá de nuestro alcance, aún y cuando mediante algunas prácticas, es posible reforzar la seguridad hasta cierto punto. Hay quienes comentan que los respaldos, se creaban en el mismo servidor en el cual se configuraban las máquinas virtuales, lo cual hizo que al momento, poco se pueda hacer para restaurar los datos.

Según tengo entendido, algo similar ocurrió en México a la empresa TecnoBit.com.mx, quienes a ésta hora, continúan caídos e intentando recuperar sus datos. No estoy muy seguro de si haya sido en realidad un ataque y/o cómo haya sido. Lo que sin duda alguna queda, es el sabor amargo de los terroristas digitales. Al día de hoy, ya existe en Internet un reporte completo sobre el exploit en el cual se basaron para realizar el ataque.

Fue un desastre, un día triste el de ayer.

Publicado el Dejar un comentario

Mi primer esquema de servidor Web

Hace ya algunos años, creo que por ahí del 2003, intentando encontrar la manera de aprovechar mi “nueva” conexión a Prodigy Infinitum de 512 mb, me puse a estudiar el proceso de configuración e instalación de servidores. Mi primer experimento, fue con el IIS que viene por defecto con Windows XP Professional, pero no me gustó. Entonces, decidí migrar a Apache, MySQL y PHP ¡sobre Windows!, y lo logré. No obstante, sentía que hacía falta algo, hacía falta automatizar, y otros detalles más, por lo que experimenté con CDMon para jugar con los DNS´s por primera vez (o cuando menos, de manera más formal) y mi primer panel de control 100% Open Source para Windows: The Z Panel. El resto es historia. Aquí te comparto la fotografía del esquema de servidor web para la organización de sus recursos, requerimientos y tecnología.

esquema de servidor web
Esquema de servidor web con panel de control open source o de código abierto.

Actualización 23 de mayo de 2021: Hoy en día, realizamos instalaciones a nuestros clientes de un servidor web con un panel de control completo para que puedan disponer de esa autonomía institucional en la administración de sus recursos, como la facilidad de uso y configuración de sus recursos disponibles. Por ejemplo: podemos realizar una integración completa de Google Workspace for Education (antes conocido como GSuite for Education y después como G Suite for Education) en el nombre de dominio *.edu de tu escuela, ya sea en una instancia de servidor VPS contratado en Digital Ocean o bien, utilizando una PC en desuso con GNU/Linux Debian o Ubuntu instalado tras una conexión doméstica o empresarial de Prodigy Infinitum de Telmex o TotalPlay con el propósito de que puedas disponer de:

  • Servidor Web Apache
  • Bases de datos MySQL
  • PHP 7.x o superior
  • Panel de control ISPConfig
  • Administración de DNS en ISPConfig o con Dynu
  • Servidor de correo electrónico
  • Acceso remoto
  • Aplicaciones en la nube como: Moodle, WordPress, WooCommerce, OSTicketSupport, etc.

¡Tú eliges! ¡Tenemos experiencia!

Publicado el Dejar un comentario

Configuración de un Servidor Proxy Squid + Script de Iptables

En este tutorial, te enseñaré a realizar la configuración de un servidor proxy Squid + script de iptables.

Actualización 20210619.- Esta es una entrada de una publicación antigua en donde, para tener contexto de la época, casi todas las conexiones a sitios web se hacían mediante HTTP (80) y muy pocas sobre HTTPS (443). A pesar de ello, es muy probable que este script y archivo de configuración siga funcionando, así como también, te puede servir de base y referencia para jugar con tus propias configuraciones. KW.

Contexto

Resulta que cuando recién llegué a laborar en una organización, la misma tenía una red de aproximadamente 60 computadoras con una conexión a internet tipo ADLS de 2048 kbps (2 mbps) de bajada, y 256 de subida (0.25 mbps). Como ya imaginarán, la velocidad de conexión era lentísima, por lo cual me dí a la tarea de configurar un servidor Proxy Squid con reglas de Iptables para que pudieramos todos trabajar a gusto, bloquear algunas urls para los usuarios ociosos (juegos, pornografía, videos), etc. En fin, en ese entonces, trabajé sobre OpenSuSE 10.0 como sistema operativo y vale, ahora que tengo Internet en casa, me he configurado un servidor Proxy para mi red casera.

En fin, con todo lo anterior, pongo en sus manos una modesta configuración para Squid 2.6 STABLE5 sobre Debian 4 Etch junto con su respectivo Script de IPTables para que lo echen a andar en su casa o red. Debo mencionar que la configuración de estos servicios, podrían resultar ser no tan sencillos para el usuario novato, más sin embargo, les comentaré lo siguiente:

¿Qué es un servidor Proxy?

En el ámbito de las redes informáticas, el término proxy hace referencia a un programa o dispositivo que realiza una acción en representación de otro. La finalidad más habitual de un servidor proxy, es el de permitir el acceso a Internet a todos los equipos de una organización cuando sólo se puede disponer de un único equipo conectado, esto es, una única dirección IP.

Fuente: http://es.wikipedia.org/wiki/Servidor_proxy

¿Qué es y para qué funciona el programa Squid?

Squid es un popular programa de software libre que implementa un servidor proxy y un demonio para caché de páginas web, publicado bajo licencia GPL. Tiene una amplia variedad de utilidades, desde acelerar un servidor web, guardando en caché peticiones repetidas a DNS y otras búsquedas para un grupo de gente que comparte recursos de la red, hasta caché de web, además de añadir seguridad filtrando el tráfico. Está especialmente diseñado para ejecutarse bajo entornos tipo Unix.

Fuente: http://es.wikipedia.org/wiki/Squid

¿Qué es Netfilter/Iptables?

Netfilter es un framework disponible en el núcleo Linux que permite interceptar y manipular paquetes de red. Dicho framework permite realizar el manejo de paquetes en diferentes estados del procesamiento. Netfilter es también el nombre que recibe el proyecto que se encarga de ofrecer herramientas libres para cortafuegos basados en Linux.

El componente más popular construido sobre Netfilter es iptables, una herramientas de cortafuegos que permite no solamente filtrar paquetes, sino también realizar traducción de direcciones de red (NAT) para IPv4 o mantener registros de log. El proyecto ofrecía compatibilidad hacia atrás con ipchains hasta hace relativamente poco, aunque hoy día dicho soporte ya ha sido retirado al considerarse una herramienta obsoleta. El proyecto Netfilter no sólo ofrece componentes disponibles como módulos del núcleo sino que también ofrece herramientas de espacio de usuario y librerías.

Iptables es el nombre de la herramienta de espacio de usuario mediante la cual el administrador puede definir políticas de filtrado del tráfico que circula por la red. El nombre iptables se utiliza frecuentemente de forma errónea para referirse a toda la infraestructura ofrecida por el proyecto Netfilter. Sin embargo, el proyecto ofrece otros subsistemas independientes de iptables tales como el connection tracking system o sistema de seguimiento de conexiones, o que, que permite encolar paquetes para que sean tratados desde espacio de usuario. iptables es un software disponible en prácticamente todas las distribuciones de Linux actuales.

Fuente: http://es.wikipedia.org/wiki/Iptables

Utilidad y funcionamiento

Ahora bien, se preguntarán seguramente, ¿para qué sirve Squid + Iptables en la red de una casa, empresa u organización? Mmmm, de mucho. Intentaré explicarlo de manera sencilla:

Imaginen que tienen 20 computadoras conectadas en su red mediante un switch directamente al modem ADSL de la compañía de su preferencia (Prodigy Infinitum de Telmex, por ejemplo), y resulta que esos 20 usuarios requieren entrar a una página como Hotmail, la cual tiene un peso específico (imágenes, documentos html, animaciones, etc.) de 300 kb cada vez que se conectan a ella. Como muchos seguramente sabrán, todos los navegadores destinan una carpeta en su disco duro para almacenar información en algo que llaman “caché”, el cual es un concepto que tiene como principal objetivo, “acelerar” la descarga en el futuro, y solo para esa PC cuando accedan más adelante a la misma página Web. Así pues, bajo nuestro escenario, si tenemos 20 usuarios que entren a Hotmail al mismo tiempo, estaríamos “descargando” entre todos, 6000 kb de información (20 usuarios X 300 kb = 6,000 kb) o lo que es lo mismo, 5.8 megas de información aproximadamente. ¿Qué sucedería en esta situación? Básicamente, que la conexión se alentaría para todos aún y cuando estén bajando todos lo mismo.

configuración de un servidor proxy squid

Y viene aquí la magia de Squid e Iptables (no puede vivir el uno sin el otro, eh), ya que, suponiendo que hemos destinado una vieja PC para hacerla de “proxy” y/o “router” mediante un servidor DHCP (ya platicaré de él en un post posterior), y conectándole un switch de 20 puertos para esas 20 pc´s, lo que sucedería es que la primer PC de nuestra red que intente establecer una conexión a Hotmail, le enviaría la petición a nuestro proxy para que haga una consulta,  en la cual éste revisaría si está “almacenada” en la caché del servidor, y en caso de no ser así, se conectaría a Internet para “descargar” todos los elementos básicos del sitio (imágenes, scripts, animaciones, etc.), con el fin de devolver “la misma respuesta” a todas las demás computadoras. En otras palabras: si una computadora ha “accedido” con anterioridad a Hotmail, habrá “descargado” seguramente a nuestro proxy esos 300 kbs de los que hablaba, evitando “saturar” nuestra con “otras conexiones” similares, ahorrándonos así 5700 kb.

Instalación de un Servidor Proxy Squid

En mi caso, tengo una PC HP Pavilion a110m con un procesador AMD Atlhon a 1.67 mhz, 512 megas de memoria RAM, dos tarjetas de red PCI y disco duro de 40 gb. Mis tarjetas de red están configuradas de la siguiente manera:

  • ETH0 – Tiene una IP del tipo 192.168.1.XX, y está conectada directamente a mi a mi Modem ADLS Prodigy Infinitum
  • ETH1 – Tiene una IP fija del tipo 192.168.0.254, la cual conecta a mi switch (y la hace de servidor DHCP en la clase 192.168.0.x) y que funciona de “puerta de enlace” a los equipos que tengo conectados.

Para instalar Squid en Debian 4 Etch, solo tienen que hacer lo siguiente:

apt-get install squid

Y ¡listo!

Solo deberán acceder a la carpeta:

/etc/squid/

Renombrar el archivo squi/d.conf y “copiar” o dejar en su lugar el mío (o el que ustedes deseen configurar manualmente).

En el caso de mi Script de Iptables, yo lo he guardado en el directorio:

/etc/init.d/fw_squid

Y le he asignado permiso de ejecutable (chmod 777 /etc/init.d/fw_squid)

Ahora, hago que se cargue al inicio, agregándolo en el nivel 3 mediante el enlace simbólico:

ln -s /etc/init.d/fw_squid /etc/rc5.d/S20fw_squid

Y listo!

Caramba, en verdad podría elaborar todo un tutorial sobre esto, pero, vale, por cuestión de tiempo me resulta un poco difícil. Sin embargo, pongo a su disposición mis archivos de configuración a fin de que puedan hacer uso de ellos; en verdad, deseo que les sirvan:

Con los siguientes comandos:

  • /etc/init.d/squid restart – reiniciamos el servidor proxy squid
  • tail -fv /var/log/squid/access.log – “miran” en tiempo real las páginas que visitan las PC´s de su red
  • /etc/init.d/fw_squid.sh – ejecutan el script de iptables
  • iptables -L -n – sirve para ver qué puertos tienen cerrados, abiertos, bloqueados, etc.

¡Hasta pronto!

PD.- Se me olvidaba. Mi script de Iptables para proxy transparente con Squid, es también una joyita que los sacará de muchos apuros. En otra entrega les platicaré más sobre él. ¡Saludos!