Archives for 

seguridad

Atencion:Phishing a Pagina de recargas Movistar

Acabo de recibir un correo con un  claro intento de Phishing a una pagina de recargas on-line de la empresa de telefonia celular Movistar.  Este Phishing me  parecio muy interesante por su elaboracion (se ve que se tomaron el  trabajo de realizar algo bien hecho) y por su innovacion, a decir verdad es primera vez que veo una estafa de este tipo.  ¿Pero, que es el Phishing? Cito la wiki:

Phishing es un término informático que denomina un tipo de delito encuadrado dentro del ámbito de las estafas cibernéticas, y que se comete mediante el uso de un tipo de ingeniería social caracterizado por intentar adquirir información confidencial de forma fraudulenta (como puede ser una contraseña o información detallada sobre tarjetas de crédito u otra información bancaria). El estafador, conocido como phisher, se hace pasar por una persona o empresa de confianza en una aparente comunicación oficial electrónica, por lo común un correo electrónico, o algún sistema de mensajería instantánea[1] o incluso utilizando también llamadas telefónicas.

Ahora que tenemos al definicion clara, debemos hacernos una pregunta interesante. ¿En particular como funciona este phishing a Movistar?

  1. Te llega un mensaje al correo con este asunto: “RECARGA EN LINEA TU MOVISTAR Y OBTEN UNA TRIPICARGA MOVISTAR”.
  2. Cabe resaltar que   gmail te advierte que el contenido de ese mensaje puede ser fraudulento, sin embargo, si haces caso omiso a la advertencia por parte de google,  al darle click a la imagen te envia a la siguiente direccion:
  3. http://sitiosegurnomovistar.co.cc/sitio/recargas/

  4. En esta url sale un pantallazo incial donde nos pregunta, el numero de celular, el valor a recargar y la entidad financiera de la cual se descontara el dinero. (Si somos un poco observadores, nos damos cuenta de que en este campo solo hay bancos Colombianos, lo cual significa y da entender que este Phishing fue desarrollado por personas Colombianas, aunque aclaro que no necesariamente debe ser asi)
  5. En el siguiente pantallazo, nos pide  los datos de la tarjeta de credito o debito y otros datos confidenciales.
  6. Por ultimo despues de ingresar los datos requeridos (sin importar si sean falsos o verdaderos), nos redirige al siguiente pantallazo.

¿Como podemos identificar este tipo de estafas?

  1. Es obvio que una compañia como Movistar nunca va a tener un dominio de tipo .co.cc,  estos dominios son gratuitos,  y nunca una compañia va a utilizar estos dominios gratuitos. Por esta razon siempre visualicen las url y si ven dominios raros, comiencen a sospechar.
  2. Identifiquen en la url el “HTTPS” ya que en todas estas transacciones de dinero se utiliza este protocolo con el fin de evitar algun tipo de estafa o robo, asi que  en todas aquellas paginas para comprar productos y servicios, deberian tener al inicio de la URL “HTTPS”.
  3. Si en algun momento empiezan a sospechar de la pagina, usen el sentido comun, y solo por comprobar, ingresen datos erroneos  e incluso no ingresen nada, se sorprenderan como la pagina fraudulenta los dejara seguir sin ningun problema.
  4. Por ultimo observer el captcha  el cual debe cambiar SIEMPRE que se refresque la imagen, si esto no ocurre, pienselo 2 veces a la hora de continuar.

Espero hayan comprendido un poco este tipo de ataque y no caigan en el mismo, evitese dolores de cabeza, recuerde que en la Internet siempre va haber alguien esperando  alguna oportunidad para robarle su dinero.  Publico este post, con el unico fin de darle a conocer a los usuarios esta nueva forma de phishing.

Seguridad en transacciones de SAP

“She was more like a beauty queen from a movie scene”

Tengo que aceptar que esta canción me recuerda a Campus Party, las pocas veces que la escucho lo hago pero en la versión acústica que tiene Chris Cornell.  Por lo mismo os la recomiendo.

Antes que nada debo disculparme enormemente con las personas que nos leen puesto que llevo mucho tiempo sin escribir en RinconInformatico.NET y sin querer he terminado por acostumbrado a no hacerlo, y eso es un grave error de mi parte.

Hoy quiero hablar un poco de mi trabajo.

SAP como todo (¿Gran?) sistema de administración de empresas (ERP) maneja autorizaciones para los usuarios y esta es una buena parte de la seguridad como tal.  Como bien definida por la etimología de la palabra:

Autorización es la capacidad que se le otorga a un individuo para realizar una actividad.

Las autorizaciones en SAP se manejan por medio de ROLES y dentro de los roles encontramos los PERFILES, en estos perfiles de usuario se almacenan las AUTORIZACIONES y son estas las que configuramos por medio de OBJETOS de AUTORIZACION.

¿Claro?

Espero que sí.  Sin embargo y comenzando por lo pequeño… un objeto de autorización simplemente es un mecanismo usado para INSPECCIONAR los privilegios de un usuario para acceder a determinados datos o ejecutar determinados programas.

Es en los objetos de autorización donde se configuran las ACTIVIDADES permitidas a un usuario, para que modifique determinado campo o cambio una descripción:

Ejemplo 1:

El usuario A, desea cambiar la descripción de un material pues resulta que tiene un error gramatical, el objeto de autorización X controla las modificaciones sobre las descripciones en los textos de los materiales.  Por lo tanto el Usuario A debe tener a X en su ROL configurado de la manera adecuada para que le permita ejecutar el cambio.

¿Qué es un Rol?

El rol de un usuario es un contenedor de perfiles, y los perfiles a su vez (como antes lo indicábamos) son los que contienen a las autorizaciones, y estas son simplemente las configuraciones de los Objetos de autorización.  El Rol es lo que en las últimas versiones SAP a implementado con el fin de que la seguridad de accesos al sistema R/3 de SAP pueda ser administrada por una persona sin grandes conocimientos ni experiencia en este tipo de Sistemas de información.

¿Un usuario puede tener varios Roles?

Completamente, de hecho es lo recomendado para las cosas más genéricas, por ejemplo el permiso para imprimir.

¿Un Rol puede tener varios Perfiles?

No, solo hay un rol por perfil.

Entonces ¿Puede haber varias autorizaciones en un perfil?

Afirmativo.  Cada vez que ingresamos un objeto de autorización en un rol o perfil este crea una nueva autorización, con la configuración que se le de al objeto de autorización.

¿Puede darse ese caso?

Todo el tiempo:

Ejemplo 2:

El mismo usuario A quien tiene permiso de modificar descripciones de textos en los materiales de la empresa, NO debe tener acceso de modificación al rango de materiales 100-200 porque estos son materiales para pruebas de calidad y no es necesario, pero si debe tener acceso a la visualización de estos materiales.  Este tipo de permisos son administrados por el objeto Y el cual tiene la posibilidad de configurar la creación, modificación y la visualización sobre los materiales.  Lo que hace un administrador de accesos es agregar DOS objetos, uno que permita la modificación de los rangos que si tiene acceso y otro donde permita la visualización de todos los materiales.

En este caso tendríamos un Rol, un perfil, pero dos autorizaciones y por lo tanto dos objetos de autorización, iguales; pero de diferente configuración.

¿Puede llegar a ser complicado?

Mi experiencia me dice que sí.  Pues las recomendaciones de “los que saben” siempre es que los roles deben configurarse de manera GENERICA, por si alguien más requiere de estos permisos.  Sin embargo YO personalmente NO comparto esta teoría, puesto que la mayoría de las veces que se requiere restringir un acceso implica tener que modificar estos roles genéricos (Y lo que conlleva con ello, bien sea quitando acceso a TODOS lo que tengan dicho ROL u otorgando mas de los necesario a las mismos que tengan dicho rol) y terminar creando roles particulares.  Resultando en lo mismo que crear Roles particulares desde el principio.

Finalmente, los programas estándar de SAP tienen definida las peticiones de información a los roles de los usuarios, a nivel programacional, es decir, en ABAP la sentencia que verifica las autorizaciones es:

Donde “Z_TCODE” es el nombre del objeto de autorización, ID es el campo que controla y FIELD es la actividad que permitida el usuario.

Esta es una explicación a groso modo y para que la entiendan las personas que no manejan SAP todos los días.  En un futuro si lo creo necesario podemos hablar de cómo se realizan las autorizaciones, es decir, un manual donde veamos paso por paso como asignar permisos en los usuarios de un sistema R/3.  Por ahora no lo creo necesario, pero puede llegar el caso.

Así funciona la seguridad en los accesos de SAP, no es ni más ni menos.

Como hoy para mi persona es un día especial, quería compartir estos pensamientos de un personaje de película, en español es llamada como “Nada es para Siempre”, es la parte final de dicha Historia y dice así:

Claro, ya estoy muy viejo para pescar bien.

Casi siempre voy a pescar solo.  Aunque me dicen que no lo haga.

Pero a solas, en la media luz de la cañada…toda la existencia parece esfumarse y quedan mis recuerdos…y los rumores del río y el ritmo en compás de 4…y la esperanza de que muerdan.

A la larga todos los paisajes se funden…atravesados por un río.

El río se formó del gran diluvio…y corre sobre las piedras del tiempo.

Sobre algunas piedras, hay gotas eternas.

Bajo las piedras, están las palabras.

Y algunas de las palabras son suyas.

El río me consuela.

Artículo enteramente dedicado al Mejor de Todos Los Tiempos a mi Papá, a Don Germán.

Rootkit, un virus espía indetectable

Hace poco, expertos en seguridad informática expusieron públicamente en la conferencia “Black hat cómo funciona el sistema comercialmente denominado “CompuTrace” y que originalmente es un software “antirobo”. Contenido en la memoria del BIOS, el virus se oculta ante el Sistema Operativo siendo casi indetectable e imperceptible, y persiste luego de los típicos “formateos”.

El título de este artículo va a sonar paranoico para el clásico perfil del usuario medio de Internet: Escéptico, exhibicionista, confiado, fan, consumista, conformista, dependiente, etc.

Según ellos (la gran mayoría) en la nueva moral “moderna” la privacidad debe morir… Y todo el mundo debe estar registrado con nombre, apellido, foto, y todos sus datos personales, junto a sus amigos en alguna “Red Social”.

Indirectamente, según la nueva moral, todo aquel que quiera privacidad es un potencial “terrorista”, y nadie quiere estar “marginado fuera del sistema”.

Ojala lo que yo escribiese sería de Ciencia Ficción, o estaría equivocado. (Uno muchas veces se equivoca). Pero en esta temática la cual escribo (política y tecnología) el tiempo y la experiencia no hacen más que comprobar y confirmar la información o los ensayos que vengo publicando en la red.

En este caso, para el lector no informático o tecnofóbico: Nos referimos a BIOS, el Software esencial de toda computadora/ordenador, el cual está grabado en una memoria o chip de todas las mismas, y cuya función es elemental: encender y reconocer el hardware de todas las PC, lo primero que se ejecuta.

Recientemente, unos expertos en seguridad argentinos han mostrado en conferencias públicas cómo funciona el sistema comercialmente denominado “CompuTrace” y que originalmente es un Software “antirobo”. En pocas palabras, han mostrado públicamente como la mayoría de los BIOS populares (AMI, Award, Phoenix) pueden estar infectados fácilmente por un virus Rootkit (un Software que se oculta ante el Sistema Operativo siendo casi indetectable e imperceptible) contenido en la memoria del BIOS, haría a este virus persistente contra los típicos formateos de un disco rígido, y luego enviando conectándose a una casa central, monitoreando con la IP (dirección única en Internet) entre otra información y probablemente dando control remoto a los agentes.

Esta tecnología está patentada por EEUU, teniendo en cuenta las leyes antidemocráticas que hay (como las de las puertas traseras como requisito legal), es un dato importante. Esta línea es experimental sólo la incluí para que sepan que la verdadera fuente de este artículo es http:///http://www.estrellaroja.info

Lo peligroso: Este sistema comenzó a implementarse MASIVAMENTE en las PC y portatiles Notebook’s. Quedando activado o estando ahí posibilitando fácilmente su activación y dejando vulnerable a la privacidad de dicha máquina. El mismo virus rootkit es independiente del Sistema Operativo. La pregunta inevitable, ¿la información de pueblos enteros, de Estados soberanos pueden ser fácilmente también afectadas por este método?

A estilo “bonustrack”, informar también: Emails encriptados gratuitos serían una trampa, era un poco “sospechoso” los servicios de Correo encriptado como Hushmail o S-mail, estarían TAMBIÉN [0] siendo controlados por la NSA [1]. Como también Google estaría empezando a ser informadora de esta agencia [2].

Cuba ya se ha puesto a la defensiva contra el plan imperialista de “exportación de Facebook/MSN” [3], aunque el ALBA recientemente sufre una operación de prensa contra Chávez relacionada con “la censura de Internet”- EEUU: Campaña contra Chávez e Internet http://www.europapress.es/internacional/noticia-venezuela-venezuela-crea-comision-especial-controlar-internet-20100317033647.html

China ha denunciado a EEUU: http://www.jornada.unam.mx/2010/03/13/index.php?section=mundo&article=016n1mun

Información utilizable para la desactivación del BIOS RootKit: http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=publication&name=Deactivate_the_Rootkit

FUENTE

Falla en Microsoft Virtual PC permite eludir las defensas de Windows

Un autor de exploits de Core Security Technologies ha descubierto una seria vulnerabilidad que expone a los usuarios del software de virtualización Microsoft Virtual PC a los ataques de hackers maliciosos.

La vulnerabilidad, la cual no tiene parche, esencialmente permite a un atacante eludir varias de la principales mitigaciones de seguridad — Data Execution Prevention (DEP), Safe Exception Handlers (SafeSEH) y Address Space Layout Randomization (ASLR) — para explotar el sistema operativo Windows.

Como resultado, algunas aplicaciones con fallas que no son explotables cuando corren en un sistema operativo no-virtualizado se vuelven explotables su corren dentro de un SO huésped en Virtual PC, según Ivan Arce, Jefe de Tecnología de Core.

La falla, descubierta por el escritor de exploits Nicolás Enonomou, existe en el administrador de memoria del Monitor de Máquina Virtual. Provoca que las páginas de memoria por encima del nivel de 2GB sean accedidas con privilegios de lectura o lectura/escritura por los programas en espacio de usuario en un sistema operativo huésped.

El software afectado incluye Microsoft Virtual PC 2007, Virtual PC 2007 SP1, Windows Virtual PC y Microsoft Virtual Server 2005. En Windows 7 la característica del modo XP también es afectado por la vulnerabilidad.

En particular, una aplicación vulnerable corriendo en Modo Windows XP en Windows 7 puede ser explotable en un ambiente virtual, en tanto la misma aplicación corriendo directamente en un sistema operativo Windows XP SP3 no.

La tecnología Microsoft HyperV no es afectada por este problema.

Fuente

Como implementar un Firewall en GNU/Linux con Shorewall

En esta oportunidad hablaremos del firewall de Linux más conocido como IPTABLES. Primero daremos algunas definiciones para poner en contexto y por ultimo mostraremos como configurar un firewall utilizando shorewall, teniendo en cuenta que la configuración aquí realizada es pensada para un equipo personal y no para uno que cuidará toda una red.

El firewall es un sistema de control sobre los puertos de nuestro sistema, de tal modo que podemos establecer cuales puertos pueden ser accedidos desde fuera y cuáles no.
El firewall de GNU/Linux es Netfilter, que trabaja en espacio de kernel, no es un servicio en espacio de usuario y se configura por medio de IPTABLES.

IPTABLES según la wikipedia es: iptables es el nombre de la herramienta de espacio de usuario mediante la cual un administrador puede definir políticas de filtrado del tráfico que circula por la red

La herramienta utilizada para configurar estas políticas de seguridad será en este caso Shorewall que en su sitio oficial es definido como: “Una herramienta de alto nivel para la configuración de Netfilter

Bueno y ahora más teoría. No hablaremos con todos lo tecnicismos que algunos les gusta, porque la idea es que todos puedan entender, o por lo menos que sirva de forma de introducción al tema.

Digamos que el kernel le encarga a Netfilter la tarea de recibir y transmitir paquetes y los revisa antes de transmitirlos.

Para revisarlos Netfilter se vale de una serie de “condiciones” que cada paquete debe cumplir. De tal modo que todo paquete que no cumpla con las “condiciones” se tira a la basura.

Estas famosas “condiciones” son las que permiten a Netfilter clasificar cada paquete y hacer con cada uno lo que sea establecido por estas condiciones.

Netfilter necesita que estas “condiciones” sean coherentes, que no sean contradictorias. No podemos decirle “descarta este paquete” y luego decirle “ah, no, mejor transmite este paquete”. Por eso, como no le gusta que le compliquen el trabajo, además de la coherencia, atenderá a cada “condición” en el orden en que fueron declaradas.

¿Y cómo declaramos las “condiciones”?

Nuestro sistema funciona por medio de “servicios” que “escuchan” en un “puerto” del sistema, esperando a que un “cliente” realice una “petición” al “servicio”. Cada “Petición” es “atendida” por el “servicio” que pidió el “cliente”.

Esto es lo que se conoce como un “sistema cliente/servidor” y GNU/Linux respeta este modelo, entonces podríamos decir que Netfilter trabaja capturando las “peticiones” de todos los “puertos” antes de que sean “atendidas” por los “servicios”.

Netfilter maneja esta tarea a través de iptables. Como cada “petición” es esencialmente un “paquete” de datos, diremos que iptables controla paquetes de la siguiente manera:

  1. Iptables maneja tablas, haciendo que los paquetes atraviesen una tabla. (table)
  2. Cada tabla posee cadenas. (chains)
  3. En cada cadena se establece una política general. (policies)
  4. Luego se establecen reglas que saltan (jump) la condición de la política.

Entonces, la tabla actuará como filtro de los paquetes. (Filter)

Sucede que los paquetes pretenden realizar una de tres acciones:

1) Un paquete que quiere salir del sistema. Por ejemplo, solicitar una dirección web en el navegador. Esta petición bajara por las capas OSI, pretenderá salir por un puerto y será “atendida” por Netfilter; si cumple las reglas sale el paquete del sistema.

2) Un paquete que quiere entrar al sistema. Por ejemplo, el resultado de la solicitud anterior. Llega el paquete que quiere entrar por el puerto 80 y será “atendida” por Netfilter; si cumple las reglas entra el paquete y sube por las capas OSI para presentar la página en el navegador.

3) Un paquete que quiere pasar por el sistema. Por ejemplo, si nuestra máquina actúa como proxy. Recibirá paquetes de la LAN queriendo ir a la WAN pasando obligadamente por Netfilter para lograrlo.

En esta tabla de filtro, tendremos una cadena para cada acción:

  1. Un paquete que quiere salir (OUTPUT) de nuestro sistema.
  2. Un paquete que quiere entrar (INPUT) a nuestro sistema.
  3. Un paquete que quiere pasar (FORWARD) por nuestro sistema.

A nivel de política, tendremos dos opciones:

  1. Rechazar todos los paquetes y empezar a construir excepciones a esta política.
  2. Aceptar todos los paquetes y empezar a construir excepciones a esta política.

Una vez que definimos la “política” que aplicará iptables, deberemos empezar con las reglas.

Continuando con un poquito de teoría miremos como es que se establecen las conexiones con un pequeño ejemplo.

Cuando una máquina A quiere acceder a otra máquina B lo hace desde un puerto de A hacia un puerto de B, mandando un saludo.

Entonces B recibe un saludo de A, marcando en su puerto una conexión nueva (NEW) y respondiendo el saludo de A.

Luego A recibe la respuesta de B, marca la conexión del puerto como establecida (ESTABLISHED) y se prepara para comunicarse con B.

Luego B recibe la respuesta de A, marca la conexión del puerto como establecida (ESTABLISHED) y se prepara a recibir datos de A.

Los datos transmitidos por A hacia B y por B hacia A son relacionados (RELATED) a la conexión.

El kernel mantiene un control del estado de éstas conexiones y pueden ser usadas para filtrar paquetes por iptables.

Antes de continuar con la configuración de nuestro firewall demos respuesta a esto: qué es mejor: ¿bloquear un puerto abierto o hacer creer que el puerto está cerrado?

Si el puerto es bloqueado se sabe que está abierto y es néctar tcp para las abejas cracker’s que quieren hacerse un picnic con nuestra maquina, en cambio si un puerto está cerrado no existe fundamento para un ataque. Si “disfrazamos” los puertos abiertos como cerrados no tendremos abejas zumbándonos.

Ahora con esto ya claro pasemos a configurar nuestro firewall personal con shorewall. Esta instalación es pensada para maquinas que tengan como sistema operativo Debian/Squeeze, Cabe aclarar que esta aplicación también está disponible para otros sabores de Linux.

Bueno ya a esta altura se estarán preguntando ¿Por qué shorewall y no directamente con IPTABLES? Básicamente porque es más fácil trabajar con un front-end que directamente con los comandos, y porque así podremos concentrarnos mucho más en las reglas. Shorewall se encargará automáticamente de convertir todo al formato de Iptables. Mucho más práctico ¿no?

Bueno manos a la obra

Para empezar lo primero que hacemos es actualizar nuestra lista de paquetes.

#apt-get update

Despues de que termine de actualizar la lista pasamos a instalar los paquetes necesarios para poder tener shorewall en nuestro sistema.

#apt-get install shorewall shorewall-perl

Cuando termine la instalacion pasamos a realizar configuraciones necesarias. Shorewall trae unos ejemplos para 1, 2 y para hasta 3 interfaces de configuración en /usr/share/doc/shorewall/examples/ que debemos copiar a la carpeta /etc/shorewall para esto ejecutamos los siguientes comandos (en este tutorial solo copiaremos los de una sola interfaz):

#cd /usr/share/doc/shorewall/examples/one-interface/

#cp -p interfaces rules zones policy /etc/shorewall/

Ahora seguimos a configurar estos archivos. Y para eso nos vamos al directorio /etc/shorewall/ donde copiamos todos los archivos de configuracion basica.

Shorewall Zones

El primer archivo de configuración que vamos a modificar es el de “zones”.

Shorewall ve la red donde se encuentra como un conjunto de zonas, para el caso de una sola interfaz de red que estamos haciendo solo vamos a tener dos zonas. Primero ejecutamos el siguiente comando:

#vim zones

Se verificara que el archivo tiene la linea de net ipv4, justo despues de fw firewall debe verse como la imagen anterior, ya los ejemplos lo traen por eso solo se va a verificar.

La zona fw firewall siempre debe existir ya que es la zona que reconoce Shorewall como suya, además será definida como una variable $FW en el shell una vez que ejecutemos el Shorewall y será referida durante toda la configuración.

Para más información de las zonas puedes ejecutar man shorewall-zones

Shorewall interfaces

Ahora debemos de obtener el nombre de la interfaz externa como se muestra en la siguiente imagen.

Por supuesto que la dirección IP de tu computadora puede ser distinta al igual que el nombre de la interfaz en este caso eth1. Fijense que la interfaz externa viene dado por la línea default via 192.168.0.1 dev eth1. Esto es importante si se tiene más de una interfaz de red.

Con esta información procederemos a modificar el archivo “interfaces”, ejecutamos el siguiente comando:

#vim interfaces

Y lo modificamos para que el archivo quede algo parecido a esto:

Breve explicacion de lo anterior

ZONE: Aquí definimos la zona a la cual va a pertenecer la interfaz que vamos a definir, en este caso la zona es net que ya definimos anteriormente

INTERFACE: El nombre de la interfaz

BROADCAST: Es opcional. Aquí definimos que queremos que haga el Shorewall con los paquetes de Broadcast en este caso con la opción detect le decimos que detecte las direcciones de broadcast por nosotros. Tambien podríamos colocar aquí la dirección IP de broadcast de nuestra red.

OPTIONS: Esta es la parte más extensa, así se explicara las opciones utilizadas aquí.

dhcp: Esta opción se debe colocar si tu computadora obtiene su dirección IP vía DHCP, o si tu firewall está instalado en un servidor DHCP.

tcpflags: Esta opción hace que Shorewall revise los paquetes por combinaciones ilegales de FLAGS (o banderas) TCP. Nunca está de más tenerlo.

logmartians: Esta opción hace que Shorewall registre paquetes con direcciones de origen imposibles, para esto tenemos que tener habilitado el routefilter en la interfaz lo cual veremos más adelante como hacerlo.

nosmurfs: Filtra paquetes smurfs (paquetes que tienen como dirección de origen una dirección de broadcast)

blacklist: Analiza los paquetes contra la lista negra que definiremos más adelante en el archivo blacklist del shorewall

routeback:Permite que Shorewall filtre paquetes que se devuelven a esta misma interfaz

Con esto el archivo de interfaces esta listo, lo guardamos y seguimos con la configuración.

Nota: Para más información del archivo de interfaces y sus opciones pueden ejecutar man shorewall-interfaces.

Shorewall Policy

Aqui vamos a definir una política que determina como Shorewall maneja la conexión entre las distintas zonas. Es de destacar que las instrucciones se ejecutan de arriba a abajo por lo que es importante mantener el orden para que se ejecuten adecuadamente.

#vim policy

Y modificamos el archivo para que quede así:

Lo que estamos diciendo aquí es que todo lo que venga de $FW que lo definimos anteriormente es la zona de Firewall de Shorewall sea aceptado y que todo lo demás sea rechazado para que pase por las reglas que crearemos a continuación.

Para más información pueden buscar las páginas de manual ejecutando man shorewall-policy.

Shorewall rules

Las reglas sirven para agregar excepciones a las politicas que declaramos anteriormente, si dejamos las politicas como están sin agregar ninguna regla pues no podremos ni siquiera navegar asi que vamos a modificar el archivo de rules ejecutando para que nos quede de la siguiente manera:

#vim rules

Nombre como Ping, SSH, etc nos describe el protocolo sobre el que vamos a efectuar la acción que puede ser ACCEPT. REJECT, DROP entre otras. Shorewall cuenta con varios MACROS, los MACROS no son más que reglas prehechas que estamos utilizando aquí como Ping, SSH, DNS, etc. Para ver una lista completa de los macros puedes ejecutar shorewall show macros.

Luego de colocar el macro y la Acción pasamos a colocar el destino que en este caso es la zona red que declaramos al principio y luego colocamos el destino que es la zona Firewall en el caso de las conexiones entrantes (net—>firewall) e invertido para las conexiones salientes (firewall–>net).

Si quisieramos aplicar una regla sobre un puerto y protocolo específico la declaramos de la siguiente forma:

ACCEPT          $FW     net             tcp     873

REJECT          $FW     net             udp     443

Ahora los útlimos retoques, vamos a modificar el archivo de configuración de Shorewall:

vim /etc/shorewall/shorewall.conf

Asegurense que los siguientes valores están correctos:

STARTUP_ENABLED=Yes

ROUTE_FILTER=Yes

Con STARTUP_ENABLED le decimos al Shorewall que inicie con el sistema, y con ROUTE_FILTER del cual hablamos ya arriba en la parte de Interfaces

Por ultimo, cambiar la linea startup=0 por startup=1 del archivo /etc/default/shorewall

Para iniciar manualmente a Shorewall y probar nuestra configuración ejecutamos:

shorewall start

Con esto nos dará algo parecido a esto:

Con esto ya tendremos un firewall personal totalmente funcional, asi que ya pueden poner a prueba sus configuraciones.

Shorewall registra todo a través del log del sistema para ver los logs podemos ejecutar los siguientes comandos:

  1. shorewall show log (Muestra los últimos 20 mensajes de netfilter)
  2. shorewall logwatch (Verifica los logs a un tiempo determinado)
  3. shorewall dump (Nos da un amplio reporte de los problemas encontrados por Shorewall)

Bueno esto es todo por el momento, espero y les sea de utilidad, que la fuerza este con ustedes y hasta la proxima.

Fuente 1

Fuente 2

Fuente 3