Ajax es el nombre de una familia de vehículos de combate blindados de orugas que están siendo desarrollados por General Dynamics UK para el ejército británico y el de la variante principal de esta familia de vehículos, un blindado de reconocimiento y ataque que a su vez tendrá algunas subvariantes.

 

El peso de estos blindados es de 38 toneladas con un potencial de 42 toneladas, su longitud es de 7,62 metros, su ancho es de 3,35 metros y su altura de 3 metros. La tripulación de la variante principal (el Ajax propiamente dicho) será de 2 efectivos, su armamento principal un cañón CT40 de 40 mm de CTA International y su armamento secundario una ametralladora coaxial de 7,62 mm L94A1. El motor es MTU 600 kW 8V, provisto por Rolls-Royce.

 

El lector podrá ver la variante principal en el video oficial de  General Dynamics UK:

www.youtube.com/watch?v=Kg9O90IiB10

 

Las otras variantes de la familia serán: Ares, un vehículo blindado de transporte de personal que también tendría una subvariante para vigilancia de formaciones de reconocimiento; Athena, que será de comando y control; Argus, para reconocimiento de ingenieros; Atlas, de recuperación y Apolo, de reparaciones. Según el fabricante cada variante de AJAX será un vehículo blindado ágil y de gran alcance.

 

Los vehículos AJAX se desarrollan sobre una plataforma base común altamente adaptable, maximizando las características comunes en movilidad, arquitectura electrónica y capacidad de supervivencia. Cada variante de la plataforma AJAX tendrá capacidades extensas que incluyen detectores acústicos, un sistema de alerta láser, un sistema de estado situacional local, un sistema electrónico de contramedidas, un sistema de marcado de ruta y arquitectura electrónica avanzada.

 

En septiembre del corriente año General Dynamics Land Systems-UK  presentó dos vehículos a Pruebas de aceptación del gobierno (GAT por sus siglas en inglés) para realizar pruebas de seguridad antes de la entrega al Ejército Británico.

Una de las razones por las que debería evitarse el uso  de archivos .htaccess a menos que sea totalmente inevitable recurrir a los mismos es el rendimiento. Cuando AllowOverride está configurado para permitir el uso de estos archivos .htaccess, httpd los buscará en cada directorio provocando una pérdida de rendimiento. Ver más detalles al respecto en:

httpd.apache.org/docs/2.4/es/howto/htaccess.html

 

 

Otra de las razones es la seguridad. Como lo mencionamos en el artículo anterior sobre el tema, en determinadas circunstancias estos archivos pueden convertirse en una herramienta de los hackers.

 

Por otra parte el uso de estos archivos es relativamente sencillo cuando se escriben con pocas directivas pero se va complicando cuando se van agregando otras. Además un archivo .htaccess puede sobrescribir directivas que se encuentran en archivos .htaccess que se encuentran en directorios previos del árbol de directorios.

 

¿Cómo evitar estas complicaciones? Daremos un ejemplo muy sencillo. Para evitar el listado de directorios podemos crear un .htaccess con la siguiente directiva:

 

Options -Indexes

 

Hasta podríamos permitir el listado de directorios con un directiva que excluyera de la lista solo algunos tipos de archivos:

 

IndexIgnore *.php

 

Con un archivo que conste de esa única directiva se mostrará el listado de directorios pero quedarán sin listar los *.php.

 

Para evitar el uso del .htaccess con al directiva Options -Indexes basta con crear en cada directorio y subdirectorio un archivo en blanco con el nombre de index.php. ¿Suena engorroso o tedioso? Es mucho más engorroso y tedioso lidiar con un servidor que ha sido comprometido.

 

En determinadas circunstancias los archivos .htaccess puede ser útiles, en algunas su uso es inevitable. Quien quiera o necesite aprender ausarlos debería hacerlo en un servidor desconectado de Internet, es decir usando una computadora anfitrión local (localhost). 

 

Artículo relacionado: 

geoestrategia.webnode.es/news/los-archivos-htaccess-pueden-ser-vulnerados-por-piratas-informaticos/

 

En el año 2012, siguiendo los planes establecidos en la Revisión Estratégica de la Defensa y la Seguridad, se dispuso que el Ejército Británico fuera reducido de 102.000 a 82.000 soldados.

En ese momento muchos alzaron la voz alarmados por una reducción tan fuerte. Los problemas no terminaron ahí.

 

Hoy por hoy el Ejército Británico cuenta con unos 78.400 efectivos. Eso no es lo peor. De ese número casi 7.900 efectivos no están en condiciones médicas de ser desplegados y otros 10.000 no están en condiciones médicas de ser desplegados a cualquier zona de conflicto y sólo podrían ser enviados a determinadas zonas.

 

En definitiva, el Reino Unido sólo tiene 60.000 efectivos en condiciones de ser desplegados de inmediato. Si a eso se le descuenta el número mínimo necesario para defender el propio territorio británico, esa cifra cae a un número muy bajo.

 

Gran Bretaña se encuentra ahora en la situación de que podría perder sus buques de asalto anfibio, tiene sus seis destructores tipo 45 en puerto y con severos problemas de propulsión y de todos modos la Royal Navy no tiene tripulantes suficientes a pesar de la reducción en el número de unidades navales. El Ejército Británico cuenta con un número mínimo de efectivos disponibles para su despliegue al extranjero. Eso sí, parece que dos grandes portaaviones (sin aviones) resoverán todos los problemas de la Defensa británica. Alguien planficó muy mal.

 

 

Mientras Brasil inicia las tratativas formales para la adquisición del portahelicópteros y buque de asalto anfibio británico HMS Ocean y cuando la Royal Navy está considerando seriamente la posibilidad de deshacerse también de los buques de asalto anfibio HMS Albion y HMS Bulwark, los ingleses habrían recibido una oferta para que los Royal Marines puedan - en caso de aceptar la propuesta - usar los buques franceses de la clase Mistral para misiones de entrenamiento y para despliegues conjuntos.

 

Empujada por la falta de fondos (los proyectos farónicos británicos dejaron exhaustas las arcas de la Defensa, por más que se niegue la situación) la Royal Navy estudia la posibilidad de deshacerse de sus buques de asalto anfibio por cuestiones meramente econónomico-financieras.

 

La propuesta francesa podría convertirse en un salvavidas de plomo para la marina de guerra británica. Si se habla de entrenamiento y de despliegues conjuntos se puede inferir que en caso de necesitar buques de asalto para un despliegue exclusivamente británico la Royal Navy podría quedarse de a pie.

 

Como si la situación no fuera suficientemente compleja algún alto mando de la Marina Real amenaza con retirarse si la decisión termina siendo la de desprenderse del Albion y del Bulwark. El portaaviones HMS Queen Elizabeth que debería sustituirlos no estará plenamente operativo antes del 2020 y a nuestro entender hasta es es una fecha tremendamente optimista.

 

Con el regreso prematuro a la Base Naval del Portsmouth del destructor Type 45 HMS  Diamond, los seis destructores de esta clase se encuentran ahora en esa base. La ociosidad de estas naves debida a los conocidos problemas en su planta de poder alarma a los británicos.

 

El destructor Diamond debió abandonar un despliegue en el Golfo Pérsico que debió durar nueve meses a sólo dos de haber permanecido en la región, a raíz de algunos problemas de propulsión. Existen versiones aparentemente contradictorias respecto a la exacta naturaleza del desperfecto que obligó a esta nave a emprender un regreso prematuro y accidentado.

 

Si bien algunos atribuyen el retorno del Diamond a un problema de propulsión diferente al de los del conjunto de la clase otros hacen una afirmación opuesta: el HMS Diamond sería el primer destructor de su tipo en haber sido modificado para resolver el problema que se origina en la planta de poder de los buques antiaéreos británicos y al parecer la corrección no habría funcionado como debería.

 

Si se analizan detenidamente las dos afirmaciones podría no haber ninguna contradicción. El Diamond podría haber sido modificado por lo cual sus problemas efectivamente serían diferentes al del resto de los buques de su tipo, pero el origen del problema es común a todos.

 

Recordemos que el hecho de que todos los tipo 45 estén en puerto al mismo tiempo no es novedoso, hay un antecedente. En julio del 2016 se dio una situación similar. La clases "Daring" terminó siendo tan problemática como costosa.

 

Artículos relacionados:

geoestrategia.webnode.es/news/el-destructor-hms-diamond-debio-abandonar-una-mision-en-el-golfo-persico-por-problemas-de-propulsion/

geoestrategia.webnode.es/news/urgente-la-royal-navy-paralizada-los-seis-type-45-estan-en-puerto-y-el-hms-ambush-enfrenta-costosas-reparaciones/

geoestrategia.webnode.es/news/la-royal-navy-sin-destructores%3a-¿un-descanso-navideno-en-julio-no/

No es el propósito de este artículo detallar la forma en que los piratas informáticos puede aprovechar los archivos .htaccess para fines malignos. El hecho concreto es que si estos ficheros no están bien redactados, si no cuentan con todas las directivas necesarias para proteger íntegramente un sitio web o si están mal ubicados pueden convertirse en un instrumento más de los hackers.

 

A veces se puede ver en la barra de estado del navegador que un sitio web extraño está intentando cargar contenido en nuestro sitio. También puede notarse que ha caído nuestro ranking en los motores de búsqueda. A veces simplemente el archivo .htaccess no está cumpliendo con el cometido para el que fue escrito. Estos pueden ser signos de que un archivo .htaccess fue hackeado.

 

Remitimos al lector al sitio oficial del Proyecto Servidor HTTP Apache invitándolo a leer detenidamente el apartado "Cuando (no) usar ficheros .htaccess".

httpd.apache.org/docs/current/es/howto/htaccess.html

 

Recomendamos usar los archivos .htaccess sólo cuando no hay otro recurso disponible o como una medida realmente transitoria. Hay que tener mucha experiencia para redactar directivas correctas y completas para proteger nuestro sitio eficazmente. Hacerlo de otra forma es - en demasiados casos - peor remedio que la enfermedad.

 

Artículos relacionados:

geoestrategia.webnode.es/news/servidores-apache-bloqueando-robots-mediante-archivos-htaccess/

geoestrategia.webnode.es/news/servidores-apache-bloqueo-de-varios-robots-y-bloqueo-temporario-de-los-mismos-mediante-archivos-htaccess/

geoestrategia.webnode.es/news/servidores-apache-archivos-htaccess-para-proteccion-basica-con-contrasena-y-proteccion-de-los-propios-htaccess/

 

 

Esta serie de artículos no pretende ser una introducción al uso de archivos .htaccess sino que quiere enseñar algunas medidas puntuales de optimización del uso de servidores Apache y de protección de sitios web alojados en los mismos. Insistimos en que en una gran proporción de los casos hay medidas más adecuadas que pueden ser implementadas, pero a menudo un archivo .htaccess puede sacarnos de un apuro.  

 

Así podríamos proteger con contraseña un subdominio, un directorio o incluso solo un archivo.

 

#PROTECCION CON CONTRASEÑA DE UN DIRECTORIO

AuthType basic

AuthName "Acceso restringido"

AuthUserFile /ruta/a/.htpasswd

AuthGroupFile /dev/null

Require valid-user

 

Si bien el archivo .htaccess que pusimos como ejemplo no podrá ser visualizado otros podrían serlo, por lo tanto conviene proteger este archivo y los otros de este tipo que se encuentran más abajo en el árbol de directorios agregando al fichero original esta directiva:

 

#PROTEGER .htaccess

<Files ~ "^.*\.([Hh][Tt][Aa])">

Order allow,deny

Deny from all

Satisfy all

</Files>

 

El archivo final podría ser como el siguiente:

 

#PROTECCION CON CONTRASEÑA DE UN DIRECTORIO

AuthType basic

AuthName "Acceso restringido"

AuthUserFile /ruta/a/.htpasswd

AuthGroupFile /dev/null

Require valid-user

 

#PROTEGER .htaccess

<Files ~ "^.*\.([Hh][Tt][Aa])">

Order allow,deny

Deny from all

Satisfy all

</Files>

 

Siempre conviene hacer pruebas exhaustivas de los resultados para asegurarnos que los mismos se correspondan con lo que deseamos lograr. Recordemos que para que los cambios en los archivos .htaccess tengan efecto debe reiniciarse el servidor.

 

Para bloquear varios robots con un archivo .htaccess mediante una lista negra debemos crear un archivo como el siguiente:

 

#Deshacerse de varios robots no deseados

RewriteEngine on

RewriteCond %{HTTP_USER_AGENT} ^Robot_maligno [OR]

RewriteCond %{HTTP_USER_AGENT} ^Robot_maligno2 [OR]

RewriteCond %{HTTP_USER_AGENT} ^Robot_maligno3

RewriteRule ^(.*)$ https://fuerade.aqui/

 

Ubicamos el archivo en el directorio al que queremos bloquear el acceso.

 

En determinadas circunstancias podríamos querer bloquear el ingreso de robots temporariamente. Por ejemplo, sabiendo que en determinado día vamos a tener un alto volúmen de tráfico, no queremos saturar el servidor o sitio permitiendo el ingreso de robots ese día. Podríamos crear un archivo .htaccess como el siguiente:

 

ErrorDocument 503 "Site temporarily disabled for crawling"

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} ^.*(bot|crawl|spider).*$ [NC]

RewriteCond %{REQUEST_URI} !^/robots\.txt$

RewriteRule .* - [R=503,L]

 

Las palabras bot,crawl y spider aparecerán en el agente de ususario (user-agent) de la mayoría de los robots de buscadores por lo que quedarán incluidos en la regla.

 

El código 503 hará saber al robot que el servidor no puede responder a la petición porque está congestionado o está realizando tareas de mantenimiento. De todos modos no conviene bloquear el acceso de los robots por mucho más de dos días para que el programa de búsqueda no interprete la situación como un apagón o mantenimiento extenso y deje de visitar el sitio con la frecuencia habitual. Suponemos que es un tanto indistinto poner el mensaje "Site temporarily disabled for crawling" en inglés o en castellano (español) pero ante la duda optamos por el inglés.

 

Artículo relacionado:

geoestrategia.webnode.es/news/servidores-apache-bloqueando-robots-mediante-archivos-htaccess/

 

 

El estándar de exclusión de robots es un método para evitar que ciertos bots que exploran los sitios web agreguen en los resultados de búsqueda información que el administrador de un sitio no quiere hacer pública. Un archivo robots.txt en un sitio web funcionará como una petición que solicita que los robots o determinados robots no hagan caso a archivos o directorios específicos en su búsqueda. 

 

El problema radica en que el protocolo es consultivo. Se confía en que los programas robóticos tendrán en cuenta los límites especificados en robots.txt de modo que se marca una o más áreas de un sitio fuera de los límites de búsqueda, pero eso no necesariamente será tenido en cuenta por los programas de exploración. Más aún, el archivo robots.txt puede poner en evidencia precisamente directorios que no queremos mostrar, lo cual eventualmente puede ser aprovechado por piratas informáticos.

 

Si queremos asegurarnos de que determinado robot no explorará nuestro sitio web podemos echar mano a diferentes recursos, uno de ellos es el uso de archivos .htaccess.

 

"Generalmente, solo debería usar ficheros .htaccess cuando no tiene acceso al fichero principal de configuración del servidor. Hay, por ejemplo, una creencia errónea de que la autenticación de usuario debería hacerse siempre dentro de ficheros .htaccess, y, más recientemente, otra creencia errónea de que las directivas de mod_rewrite deben ir en ficheros .htaccess. Esto sencillamente no es el caso. Puede poner las configuraciones de autenticación de usuario en la configuración principal del servidor, y esto es de hecho, el método preferido de configurar Apache. Del mismo modo, las directivas mod_rewrite funcionan mejor, en muchos sentidos, en el fichero de configuración principal del servidor."

httpd.apache.org/docs/2.4/howto/htaccess.html

 

Sin embargo el uso de estos archivos es bastante sencillo y puede ser el primer recurso que aprendemos a utilizar. Más adelante convendrá reemplazarlo por otra técnica. Para evitar el ingreso de un robot no deseado podemos crear un archivo .htaccess con un código de este tipo en el directorio en que corresponda:

 

#Deshacerse de un robot no deseado

RewriteEngine on

RewriteCond %{HTTP_USER_AGENT} ^Robot_maligno

RewriteRule ^(.*)$ https://fuerade.aqui/

 

También podemos dar la indicación de modo opuesto, permitiendo el ingreso de un robot (quedará excluido el resto):

 

#Permitir el ingreso de determinado robot

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} !Robot_benigno [NC]

RewriteRule ^ - [F,L]

 

"El Ministerio de Defensa y la Armada Argentina, como autoridad de aplicación del Convenio Internacional sobre Búsqueda y Salvamento Marítimo, informa que hoy jueves 30 de noviembre a las 16:20 hs. declaró finalizado el caso SAR (de Búsqueda y Rescate) del submarino ARA “San Juan”, cambiando a la fase de búsqueda del mismo." - Gacetilla de prensa N°50 de la Armada Argentina

 

 

Cuarenta y cuatro argentinos ofrendaron su vida por la Patria. Por mucho que nos duela dar la noticia del cierre del caso SAR del submarino ARA "San Juan" no podemos dejar de sentir un profundo orgullo de ser argentinos. Los efectivos a bordo del ARA "San Juan" conocían los riesgos de ser submarinistas y los asumieron con profesionalismo y abnegación.

 

Es prematuro hablar de responsabilidades, eso deberá desprenderse de una investigación seria y exhaustiva. Podrá decirse que las Fuerzas Armadas argentinas sufren de décadas de desinversión y de horfandad política pero no es ese el tema de esta nota.

 

Cuarenta y cuatro argentinos dieron su vida por la Patria y queremos darles las gracias. Queremos elevar nuestras oraciones por el eterno descanso de sus almas y por la fortaleza de sus seres queridos.

 

Cuarenta y cuatro argentinos dieron su vida por la Patria. Que Dios los tenga en Su Gloria y que la Patria los guarde en un lugar privilegiado de su memoria. A nosotros solo nos cabe darles las gracias. ¡Dios y Patria - o muerte!