Guia SYSTEM SAFETY MONITOR - Pruebas, impresiones, recomendaciones

Los usuarios de Kerio PF v4 ya cuentan con el control de aplicaciones que éste proporciona para evitar suplantaciones pero, como se ha podido ver, SSM cuenta con funciones añadidas. Probado junto con Kerio PF v2, forman una pareja muy competente y es de esperar que tampoco cause problemas con otros cortafuegos (aunque a este respecto no hemos realizado pruebas). Con KPF v4 tampoco parece ir mal, pero la v4 consume más recursos que la v2 y debo decir que en equipos activos 24 h / 7 días el consumo de esta beta va aumentando poco a poco, desde sus aprox. 4 ó 5 MB iniciales hasta cifras de dos dígitos, aunque sin apreciar problemas por ello en equipos medianamente modernos. Normalmente los equipos activos 24/7 corren bajo win de núcleo NT que suelen devolver los recursos al finalizar los procesos, de tal manera que en situaciones extremas, cerrar y reiniciar SSM debería bastar para solucionarlo. En cualquier caso, el autor es consciente de ello y tratará de depurar este aspecto para asemejarlo al bajo consumo -tan sólo 4 MB- de la versión anterior.

Aparte de estar testeando esta beta desde que estuvo disponible -Dic. 2003- con el uso habitual de mi equipo, he utilizado diversas herramientas para probar la eficacia de SSM ante situaciones potencialmente peligrosas; desde los conocidos firehole y tooleakey, pasando por copycat , project1, AWFT, etc. y de momento se ha comportado de manera excelente :) ...si añado que no he experimentado problemas de ningún tipo con esta beta, puedo decir que para mi gusto se convierte en un programa altamente recomendable. De todas maneras, no olvidéis que es una beta y lo que ello implica (la responsabilidad ante problemas la asume el usuario al instalarlas).

Pero hablemos de su funcionamiento cotidiano. Cuando nos muestra el típico cuadro de diálogo:

Fig. 13

básicamente sucederá en dos situaciones:
- que nosotros hayamos provocado la llamada, lo que razonaremos sin problemas, dada su inmediatez en el tiempo.
- que cualquier aplicación la llame (por dependencias, plugins integrados, etc. lo que generalmente entra dentro de lo normal ...o quizás por la acción solapada de algún bichejo).

En cualquier caso, como norma general, si la aplicación es de fuente conocida y de confianza, se le podría crear directamente una regla definitiva de permiso (F1). Si existe un atisbo de duda, aunque sea mínimo, mejor darle permiso sólo por esa vez (F4) y tras comprobar que su funcionamiento no es sospechoso, darle permiso definitivo la próxima vez que la llamemos. Huelga decir que si no la hemos solicitado y su procedencia es sospechosa o desconocida, conviene negar por defecto; en principio sólo por esa vez (F5) y si posteriormente comprobáramos su inconveniencia, de manera definitiva (F2). En el caso de ciertos bichejos, podría venirnos bien para frenar alguna de sus actividades mientras tratamos de erradicarlo del equipo.

Ante alertas que os desconcierten, fijaros siempre donde indica la información técnica de ésta (recuadro Technical information, dentro de la propia ventana). Veamos los casos más significativos:

Fig. 26

En ocasiones podrá alertarnos sobre DLL Hooking, como muestra la fig. 26. Nos está informando de que una aplicación está tratando de fijar o añadir alguna *.dll a un proceso ya iniciado. Lo recomendado en estos casos sigue la tónica de las sugerencias anteriores: decidiremos en función del grado de confianza. Si es una aplicación de procedencia segura, uso habitual y hemos comprobado que siempre hace uso de las mismas librerías, lo lógico es crearle una regla de permiso definitiva. En caso de sospecha o duda, seguir el procedimiento ya comentado.
Puede darse el caso de que ciertas *.dll sean llamadas con mucha frecuencia por diversas aplicaciones... se podría elegir la librería en cuestión y crearle una regla permanente, que sería aplicada a dicho módulo independientemente de la aplicación que la solicitara; para ello bastaría con marcar el casillero que vemos en la esquina inferior izda. de la fig. 26: Always apply this rule to this module (application-independently) / Aplicar siempre esta regla a este módulo (independientemente de la aplicación). De hacerlo, dicha *.dll aparecería en el listado de reglas de aplicaciones como si fuera un programa.

Otras veces puede mostrarnos una alerta sobre intento de DLL/Code Injection:

Fig. 27

El poder detectar y frenar ese tipo de acciones sospechosas es una de las bazas fuertes de SSM. Antes hablaba del MD5, empleado para evitar que aplicaciones maliciosas se hicieran pasar por otras y que algunos cortafuegos como Kerio o Zone Alarm también emplean... pero lo cierto es que esta medida, estando bien, no es suficiente. Precisamente porque mediante inyección de código/dll (insertar su propio código en un proceso ya activo o en memoria dentro de una DLL con privilegios de una aplicación trusted), aplicaciones nocivas pueden tomar control total sobre un thread de otro proceso, utilizar para sus propósitos -y sin nuestro conocimiento- a alguna aplicación autorizada de nuestro equipo. Esto es especialmente grave si pensamos que puede ser empleado por ejemplo para conectarse con el exterior, traspasando fácilmente la barrera que suponen la inmensa mayoría de cortafuegos de entornos windows (abusando del permiso que en éste tenemos concedido al navegador). Alguna de las herramientas con las que he probado SSM utilizan esta técnica y me alegra decir que en todos los casos este comportamiento fue detectado satisfactoriamente, permitiendo bloquearlo sin problemas. Buen trabajo, Max ;)

Debo comentar que, aunque muy poco frecuente, servicios de bajo nivel del sistema (como lsass.exe, csrss.exe o smss.exe) podrían llegar a provocar una alerta por intento de code injection, con lo que ordenando su bloqueo podríamos entorpecer el buen funcionamiento del sistema. Pero otro tipo de aplicaciones/procesos normalmente no deberían desencadenar alertas de este tipo y de hacerlo, deberíamos prestarles mucha atención porque es un comportamiento altamente sospechoso. En estos casos la sugerencia es bloquearlo esa vez para comprobar que dicha acción no trae consecuencias negativas para el sistema y, si efectivamente es una aplicación nociva, bloqueo permanente mientras procedemos con su búsqueda y eliminación.

Cuando se empieza a utilizar el programa, lo normal es que se tengan que tomar muchas decisiones para permitir/bloquear, relacionadas con las aplicaciones de uso habitual. Al poco tiempo de usarlo, ya se tendrán esos permisos concedidos y no volverá a molestar más (salvo por el uso de nuevas aplicaciones), permaneciendo en la sombra, pero vigilando y sirviéndonos de protección frente a comportamientos sospechosos.

Siendo sincero, la primera vez que abrí el programa no me agradó especialmente, pero tras dedicarle un poco de tiempo ha ido gustándome cada vez más, hasta el punto de considerarlo hoy día una utilidad residente tan imprescindible en mi equipo como pueda ser una buena pareja de antivirus-cortafuegos. Ha hecho méritos para ello ;^)