Blog

EL PORTAAVIONES HMS QUEEN ELIZABETH PRESENTA SU PRIMER PROBLEMA TÉCNICO

19.12.2017 08:09
El portaaviones HMS Queen Elizabeth que fue aceptado y formalmente puesto en servicio en la Marina Real británica hace apenas dos semanas presenta su primer problema técnico, una filtración a través de los sellos de los ejes de sus hélices. Los mismos dejan pasar 200 litros de agua de mar por hora.
 
Quien escribe éste artículo tiene cierta experiencia en materia de sellos y conoce las dificultades de lograr la hermeticidad de los mismos, algo que rara vez es total incluso en los equipos más delicados. Aún así una filtración de 4.800 litros de agua salada por día representan un problema; se prevé que será reparado a la brevedad.
 
Hay dos cuestiones, sin embargo, que preocupan a los altos mandos de la Royal Navy. La primera es que el portaaviones ya presentaba el problema al momento de haber sido formalmente aceptado. La segunda es la posibilidad de que éste sea sólo el primero de una lista de problemas. La mala experiencia con los destructores tipo 45 (Type 45) seguramente crisparía los nervios del más optimista.  
 
Se afirma que los costos de reparación del inconveniente técnico ascenderán a una cifra millonaria en libras. Como el portaaviones ya presentaba el problema al momento de la entrega, el monto deberá ser absorbido por los fabricantes.
 

CUIDADO! APACHE HTTPD.CONF SERVERSIGNATURE OFF NO RESUELVE TODO

18.12.2017 06:44
En uno de nuestros últimos artículos sobre el tema decíamos que para un pirata informático podría ser útil conocer la versión de nuestro servidor Apache. Agregábamos que la versión del servidor, nuestra versión de PHP y otros datos quedan expuestos cada vez que se muestra un mensaje de error generado por el servidor. Para ocultarlos habíamos apelado al archivo htppd.conf. Al final del mismo habíamos agregado las siguientes dos líneas:
 
ServerSignature Off
ServerTokens Prod
 
Daremos un ejemplo muy burdo de cómo un hacker puede obtener parte de la información que intentamos ocultar a través de alguna vulnerabilidad en el código de nuestras aplicación.
 
Supongamos que en algún lugar de nuestro servidor existe el siguiente código:
 
<?php
$string = $_GET['nombre']; 
eval ( "echo ". $string .";" );
?>
 
Si se ingresa como dato un nombre de usuario el mismo será impreso en pantalla. Si en cambio en la barra de direcciones del navegador escribimos lo siguiente: 
 
https://127.0.0.1/inyeccion_de_codigo/vulnerable.php?nombre=phpinfo();
 
obtendremos una jugosa cantidad de datos. Es cierto, la versión de Apache no aparecerá, sin embargo sí veremos la de PHP y una gran cantidad de información sobre el servidor, el sistema operativo y otros. La defensa en capas no es un capricho, es una necesidad siempre que pueda ser implementada. Un servidor con estrictas medidas de seguridad seguirá siendo vulnerable con un código mal escrito. Un código bien escrito es una capa más en el sistema de seguridad.
 

NAVIDAD: UN BUEN MOMENTO PARA QUE LA EMPRESA DIGA GRACIAS

17.12.2017 07:30
Es típico que una empresa al cerrar un periodo organice para sus empleados algún tipo de reconocimiento, la clásica cena, brindis o fiesta de fin de año; esto es muy beneficioso para mejorar el clima laboral ya que la Navidad trae alegrías y es un buen momento para compartir y también es un termómetro para medir el grado de compromiso del personal.
 
Tomando en consideración lo indicado, la empresa en la que trabajo organizó este año un almuerzo para el personal en un restaurante, nos sorprendió gratamente la concurrencia con casi el 100% de asistencia; se preparó con anticipación concursos entre los presentes y tuvieron buena acogida, hubo premiaciones y sorteos, en fin se sintió el entusiasmo de todos, el que se vió reflejado en fotos y videos.
 
Para este tipo de eventos hay detalles que se deben tener en cuenta, como el tipo de reunión que se quiere ofrecer a los trabajadores, por ejemplo si hay música que anime a bailar y el sonido es alto, todos entenderán que es una fiesta y pueden beber más o menos y divertirse y si se quiere un almuerzo sólo para departir y conversar el acompañamiento musical debe ser acorde; esto no lo tomamos en cuenta y mientras el sonido de la música era muy fuerte y muchos se animaban a bailar la plana gerencial se incomodó.
 
También, se debe considerar regalos para los trabajadores, pero si por cuestión de costos resultarían muy modestos, sería mejor pensar en sorteos con productos superiores que serán mejor apreciados.

SERVIDORES APACHE: LOS ARCHIVOS .HTACCESS COMO MEDIDA DE SEGURIDAD TEMPORARIA

16.12.2017 11:23
Dado que escribir y probar las directivas del archivo httpd.conf suele ser más complejo que escribir algunos archivos .htaccess, éstos podrían ser considerados como una medida de seguridad válida hasta que se adquiera el dominio del httpd.conf, se escriban adecudamente las directivas necesarias y se las pruebe exhaustivamente para la versión de servidor que manejamos, su configuración y entorno. 
 
De todos modos debemos insistir en la baja del rendimiento del servidor y en la aparición potencial de algunas vulnerabilidades. Daremos un ejemplo muy sencillo de esto último, queremos enseñar a prevenir, no a atacar.
 
Consideremos el siguiente archivo .html alojado en nuestro servidor:
 
<!doctype html>
<html>
<body>
    <form action="atras.php" method="POST">
        Elija un color:
        <select name="color">
          <option value="verde.php">green</option>
          <option value="azul.php">blue</option>
          <option value="celeste.php">red</option>
        </select>
        <input type="submit"> 
    </form>
</body>
</html>
 
y el correspondiente archivo atras.php:
 
<?php
    if(isset($_POST["color"]))
    {
        include($_POST["color"]);
    }
?>
 
Bastará que un pirata informático cliquée en "inspeccionar elemento" y cambie "verde.php" por ".htaccess" y podrá ver el archivo .htaccess correspondiente a ese directorio y eventualmente aprovecharse de esa información. El ejemplo es un caso muy burdo de inclusión local de archivos, pero muestra a las claras como diferentes deficiencias de seguridad se van potenciando entre sí.
 
Artículo relacionado:
 

LA MARINA REAL BRITÁNICA SE DESPRENDERÁ DE HASTA NUEVE BUQUES

15.12.2017 11:24
Los proyectos faraónicos de la Royal Navy y la paupérrima planificación de la Defensa británica tendrán consecuencias graves. Ayer dos dragaminas de la clase Hunt fueron formalmente retirados del servicio en una ceremonia en la que los medios británicos estuvieron ausentes porque no se les permitió asistir.
 
Las tratativas británicas con Brasil por la venta del portahelicópteros y buque de asalto anfibio HMS Ocean están avanzando. Los siguientes en la lista podrían ser los buques de asalto anfibio HMS Albion y HMS Bulwark y dos fragatas Type 23. Chile y Brasil ya fueron notificados de que esos cuatro buques podrían quedar disponibles para la venta. En el 2023 los británicos podrían desprenderse de otras tres fragatas tipo 23.
 
Con los seis destructores tipo 45 con problemas de propulsión y con el programa de las fragatas Type 26 retrasado es difícil asegurar que los portaaviones británicos tendrán una escolta adecuada. Además se alzan voces que advierten que los Clase Queen Elizabeth son incapaces de cumplir el rol de buques de asalto anfibio. De todos modos eso parece tener una importancia relativa: los Royal Marines están en la lista de posibles recortes.

SERVIDORES APACHE: CÓMO PREVENIR EL CROSS-SITE SCRIPTING (XSS)

14.12.2017 07:33
Seguimos mejorando la seguridad de nuestro servidor.
 
XSS, del inglés Cross-site scripting es un tipo de vulnerabilidad típica de las aplicaciones Web, que permite a una tercera persona inyectar en páginas web visitadas por el usuario, código JavaScript o en otro lenguaje similar, dándole la oportunidad de aprovechar esa acción con diferentes fines malignos.
 
El Cross Site Scripting se previene mediante un sistema de seguridad de defensa por capas. En ese sistema de seguridad quedan incluidos, entre otros, el programador de la aplicación, el navegador y eventualmente un cortafuegos para aplicaicones web (WAF, por sus siglas en inglés). También es posible habilitar la protección contra este ataque en el propio servidor.
 
Para eso abrimos el archivo httpd.conf y agregamos la siguiente directiva:
 
<IfModule mod_headers.c>
    Header set X-XSS-Protection "1; mode=block"
</IfModule>
 
Recordamos que deberá reiniciarse el servidor para que la medida se haga efectiva.
 
CUIDADO, ESTA DIRECTIVA POR SÍ SOLA NO IMPIDE TODA FORMA DE XSS.
Acabamos de probarla en nuestra versión del servidor y logramos encontrar una "carga útil" que la burló. Es necesario implementar el sistema de seguridad de defensa por capas.
 
Artículo relacionado:
 

SERVIDORES APACHE: CÓMO OCULTAR LA VERSIÓN DEL SERVIDOR

13.12.2017 15:33
Continuamos mejorando la seguridad de nuestro servidor (en inglés el conjunto de estos procedimientos se conoce como "hardening" - endurecimiento).
 
Para un pirata informático podría ser útil conocer la versión de nuestro servidor Apache y así intentar aprovechar las vulnerabilidades conocidas del mismo que no hayas sido subsanadas con un parche informático. La versión queda expuesta - por dar un ejemplo - cada vez que se muestra un mensaje de error generado por el servidor. Para ocultarla apelamos al archivo htppd.conf. Al final del mismo agregamos las siguientes dos líneas:
 
ServerSignature Off
ServerTokens Prod
 
Reiniciamos el servidor para que los cambios tengan efecto y podemos comprobar que si intentamos acceder a una página inexistente se nos mostrará el código de error 404 sin detalles de la versión del servidor ni del sistema operativo ni de la versión de PHP que estemos usando.  

SERVIDORES APACHE: CÓMO DESHABILITAR LOS ARCHIVOS .HTACCESS

12.12.2017 12:09
Ya vimos que el rendimiento y la seguridad son las dos razones fundamentales por lo cual será conveniente, siempre que sea posible, deshabilitar por completo los archivos .htaccess.
 
Daremos un ejemplo muy sencillo de cómo hacerlo que el lector podrá adaptar a sus necesidades sin mayores dificultades.
 
Tomemos el caso de un servidor instalado para el aprendizaje de su administración, en nuestro caso un servidor preconfigurado Apachefriends XAMPP. Busquemos la siguientes líneas:
 
DocumentRoot "C:/xampp/htdocs"
<Directory "C:/xampp/htdocs">
 
Algunos renglones por debajo de ellas encontraremos un comentario muy claro:
 
# AllowOverride controls what directives may be placed in .htaccess files.
 
Lo traducimos para el lector
 
"AllowOverride controla qué directivas pueden ser ubicadas en los archivos .htaccess".
 
Apenas unas líneas debajo de la anterior encontramos la siguiente directiva:
 
AllowOverride All
 
Cambiamos All por None y queda así:
 
AllowOverride None
 
Las directivas de los archivos .htaccess que pudiera haber quedarán sin efecto. Borramos esos archivos y la tarea queda lista.
 

SERVIDORES APACHE: USANDO EL ARCHIVO HTTPD.CONF PARA BLOQUEAR EL ACCESO DESDE DETERMINADA IP A TODOS LOS DIRECTORIOS DE UN SITIO

11.12.2017 18:19
En el archivo httpd.conf buscamos las siguientes líneas. 
 
<Directory />
    AllowOverride none
    Require all denied
</Directory>
 
Si las hemos modificado de acuerdo al artículo "SERVIDORES APACHE: PROTECCIÓN DE UN DIRECTORIO CON CONTRASEÑA VÍA HTTPD.CONF" las mismas habrán quedado así:
 
<Directory />
    AllowOverride none
    Require all granted
</Directory>
 
Las modificamos para incluir las IP a bloquear:
 
<Directory />
    AllowOverride none
    Order allow,deny
    Allow from all
    Deny from 127.0.0.1  
</Directory>
 
Estas directivas funcionarán correctamente en un servidor que aloja un sólo sitio web o más de uno, pero todos con la misma configuración.
 
Aconsejamos INSISTENTEMENTE que siempre prueben exhaustivamente los cambios antes de implementarlos. Diferentes plataformas, versiones y configuraciones pueden requerir de algunas modificaciones a estas directivas.
 
Artículos relacionados:
 

SERVIDORES APACHE: USANDO EL ARCHIVO HTTPD.CONF PARA BLOQUEAR EL ACCESO DESDE DETERMINADA IP A UN DIRECTORIO DETERMINADO

11.12.2017 13:29
En nuestro último artículo sobre el tema dijimos que "las etiquetas <Directory /ruta/a/directorio> y </Directory> se usan para crear un contenedor que se utiliza para cercar un grupo de directrices de configuración que sólo se aplican a un directorio y sus subdirectorios específicos. Cualquier directriz aplicable a un directorio puede usarse en las etiquetas Directory."
 
 
Así para bloquear el acceso a un directorio determinado desde determinada IP (o desde más de una) abrimos el archivo httpd.conf y creamos las siguientes directivas entre las mencionadas etiquetas <Directory /ruta/a/directorio> y </Directory>:
 
<Directory "C:\xampp\htdocs\test">
        Order Allow,Deny
        Allow from all
        Deny from 127.0.0.1
</Directory>
 
Hemos puesto la dirección IP de la computadora anfitrión local (localhost) para que el lector pueda comprobar el bloqueo en su propio servidor, en caso de contar con uno.
 
Al igual que en el ejemplo del artículo anterior aclaramos que las directivas funcionarán correctamente en un servidor que aloja un sólo sitio web o más de uno, pero todos con la misma configuración. En uno que aloja más de uno con diferentes configuarciones habrá que modificar apenas un poco más la configuarción original del servidor mediante el archivo htppd.conf.
 
Artículo relacionado:
 
 
<< 121 | 122 | 123 | 124 | 125 >>

Etiquetas

  1. portaaviones
  2. Wehrmacht
  3. Luftwaffe
  4. Tempest
  5. blindados
  6. bombarderos
  7. artillería
  8. Brasil
  9. submarinos
  10. RAF
  11. patrulleros
  12. British Army
  13. ejercicios
  14. misiles y cohetes
  15. IMARA
  16. EA
  17. portahelicópteros
  18. clase Queen Elizabeth
  19. F-35
  20. avisos
  21. fragatas
  22. tipo 45
  23. destructores
  24. helicópteros
  25. FAA
  26. Orion P3
  27. COAN
  28. ARA
  29. Royal Navy
  30. Malvinas