Verify

Checks

Now we are going to Check all configration applied by Lupael (Bangladesh)

Phase 1

Verification from Network Client

To do this, we just set up a computer in virtualbox, in this case a Ubuntu desktop, and the fundamental thing is that in the Network part, it is on the internal network and the name corresponds to the LAN to which we have set up the dhcp service.

Red interna cliente Virtualbox

In the network configuration we leave everything in automatic, in the ipv4 tab

Configurar ip en automatico

And then in the details tab we can see how the ip, the gateway and the dns correspond to what we previously defined in the DNS server

IP del cliente dada por dhcp

Finally we check that it has ping from the terminal and that it can surf the internet.

Ping a internet y navegación

Verification from Network Client by vlan

Now we try to enter a client from vlan 10, for this from virtualbox we will have our CHR ova with an internal interface called vlan 10 as shown below.

Ruter red vlan en virtualbox

And a ubuntu desktop with an interface that belongs to that same internal network

Cliente red vlan en virtualbox

Once inside our ubuntu OS we go to the network configuration to see if it has given us our ip by dhcp in vlan 10

IP en cliente por vlan

We can also check from Mikrotik that he has given an IP to a device by going to the Leases tab from the Dhcp server window, where it gives us information about the device such as the IP assigned to it, the MAC, the hostname of the device, the time in which the leased ip expires, etc.

Winbox ver arrendamiento de ip por dhcp

We tried pinging from the terminal.

Ping a internet

And to surf the internet.

Navegar por internet

Firewall rule checks configured for the DMZ

First we will start with the administrator of the services of the lan2 whose ip is 192.168.20.2, he must have internet access, be able to ping the dmz, connect by ssh to the dmz, but he must not have access to the lan1.

Lan2 salida a internet

Ping one of the dmz servers

Ping de lan a dmz

Ssh connection to one of the dmz servers

Conexion por ssh a la dmz

No connection with a lan1 worker

No hay ping a la lan1

On the other hand, the other administrator of the lan2 whose ip is 192.168.20.3 and who is in charge of the lan1 network if it will have a connection to it and to the internet but not to the dmz or by ssh.

IP of the lan2 administrator who is in charge of maintaining the lan1

IP del administrador de la lan2 que se encarga de mantener la lan1

No connection to dmz

Sin conexión a la dmz

Connecting to a worker on the lan1 network

Conexión a la red lan1

Testing with a dmz server whose ip will be 192.168.30.3, which must have internet access, connection with the lan2 server administrator, and everything else denied.

IP de servidor de dmz

Ping with LAN2 Network Manager

Ping con el Administrador de la red lan2

No connection to the lan1 network

No conexión con la red lan1

Now we will test that the lan1 network will not have a connection with anyone except the lan2 administrator, the ip of one of the lan1 workers will be 192.168.10.254.

IP de un equipo de la lan1

No connection to dmz

Sin conexión a la dmz

No connection to the lan2 server manager

Sin conexión al administrador de servidores de la lan2

No internet connection

Sin conexión a internet

Connection to the LAN2 network administrator who maintains the LAN1

Conexión con el administrador de la red lan2

Finally we will do the configuration of the last NAT rule that we add to do the port redirection check, for this we can use the host machine in this case a windows 10, so the test will be carried out from the powershell.

IP del equipo anfitrión de Windows 10

Configured IP of the mikrotik router where we can see the IP of the wan and the different LANES

IP del router

IP of the dmz server computer to which we are going to enter by ssh

Ip del equipo servidor de la dmz al cual vamos a entrar por ssh

Entering by ssh to the dmz server, using the wan ip of the mikrotik router

SSH de anfitrión a dmz

Checking that we are on the dmz server by seeing its ip

Comprobación de que estamos en el servidor de la dmz viendo su ip

Try with tracepath from the dmz server being ssh from the host

Tracepath

Try with traceroute from the dmz server being ssh from the host

Traceroute

Vpn checks over ipsec

One of the checks that we can do to see if the tunnel works is from Winbox we go to the left menu, we click where it says Tools and then to Ping . In this window we must define in the General tab in the Ping To section , the address to which we want to ping, which in this case will be the gateway interface of the local network of the router with which we have established the tunnel, then we go to the Advanced tab and in the Src section. Address we write the ip of the router interface where we are right now that gives the lan network of this. Once both IPs are configured, we will click the Start button and the screen below should see if there is a response.

Pestaña General, ip de la lan del router destino, conexión establecida

Pestaña Advanced, ip de la lan del router origen, conexión establecida

The next connection will be from a client on one network to another client on a different lan network, in this case the client's IP will be 192.168.20.254 as shown in the following image.

IP de cliente

And first we will try to ping the 192.168.10.1 address that corresponds to the router's lan interface that is on the other side of the tunnel.

Ping a la interfaz del ruter de la otra sede

And then we will do the same but with the ip of a client that belongs to the lan network that is on the other side of the tunnel.

Ping a un equipo de la otra sede

Phase 2

Check Failover

To carry out this test we will enter one of the company's routers through Winbox, we will have on the screen the terminal pinging 8.8.8.8 constantly, the traceroute tool pinging 8.8.8.8 and the route list window.

Conexión con el isp principal

Next we disconnect ISP1, which is the one we define as the main one, and we will observe how the connection is lost, until after a while it will automatically connect to ISP2 and have a connection again, it will not only be visible because it re-ping 8.8.8.8 from the terminal, but because it will be reflected in the Router list window, changing the color of the route that was previously in blue to black and the acronym will also change defining that it will be active.

Perdida de conexión con el isp principal

Reconexión con el isp secundario

Finally, we reactivate the ISP1 that was previously turned off, as soon as it starts, it must go back to the Route List as the main one, and in the traceroute window, where all the connection was lost, it must be activated again.

Reconexión con el isp principal

Check VRRP

To check the vrrp, we will enter a client computer with Ubuntu desktop OS, we will check its ip and gateway, to confirm that it is configured according to the Vrrp associated with the Router.

Preparación de Prueba comprobando ip y gateway del equipo cliente

The next step will be to be playing a YouTube video and pinging 8.8.8.8 continuously from the client computer, there will also be two Winbox windows where we will see both the router, the master and the backup, and within each of these windows we will see the ip and interfaces of both routers, where we will check that the traffic circulates through the ether6-LAN of the master router.

Prueba de conexión

Next, in order not to lose the connection with Winbox of the master router, instead of turning it off, we disconnect the ether6-LAN interface, which is the one connected to the client computer.

Desconectar interfaz ether6-LAN del router maestro

We can check how vrrp 1 of the backup router jumps quickly, because the response is about 3 seconds, this can be confirmed by seeing the window of the client computer that pings where there is a stop of the sequence from 41 to 45, hardly noticeable . Then we will see how the connection begins to circulate through the ether6-LAN interface of the backup router.

Activacion del router de respaldo por vrrp1

Now we reconnect the ether6-LAN cable of the master router.

Conectar interfaz ether6-LAN del router maestro

And in a few moments the backup vrrp 1 changes from black to red again, and the connection goes back to the ether6-LAN of the master router.

Reconexión del vrrp1 del router maestro

Check Bandwidth

The tests will be carried out from an Ubuntu desktop that is in the LAN2 network, in which the IP of the equipment will be shown in an image that must correspond to that of the assigned network, and the speed test.

Prueba de velocidad antes de la regla

Next, another speed test will be carried out on the same equipment with the bandwidth rules already defined in the router and where the IP of the equipment must correspond to one of the rules defined in the router.

Prueba de velocidad después de la regla

As can be seen in the previous images, at the beginning it had 1Mb of upload and download, and then with the rule that was defined in the router it has an upload of 0.3Mb and a download of 0.8Mb.

Check load balancing by PCC

For this check, it is based on an ubuntu desktop, belonging to the dmz network, in the image it is shown that the IP of the computer corresponds to that network, it will also be seen in the image that there are two internet tabs where videos are played on YouTube and since Winbox being connected to the main router that gives the dmz network, there must have been packets flowing through both WAN interfaces. What cannot be appreciated is the relative sum of the load balancing on the interface that provides the network to the dmz, this is due to 2 factors:

• As a virtualization is being used with the CHR OVA, it is restricting the connection to 1Mb

• Also, as it is a virtualization, two internet providers are required giving internet access, when in this example we only have the home network.

Comprobacion de balanceo de carga con PCC

Phase 3

Check Port Knocking

To check the port knocking operation, we will first show the rules created in an image, to check the number of knocks to be made and through which ports we must enter. The interfaces and ip will also be seen, in this case we will connect through the ip 192.168.0.23/24.

Reglas firewall, interface he ip del router

Then we will be in the address list tab being connected to the router from Winbox, I will try by ssh and by winbox to the router, giving us an error.

Error de conexión al router

In the following images we will see how we go step by step connecting by ssh to the ports defined in the rules, and the ip of our host machine will appear in the addresslist that corresponds to each defined rule.

First touch, port 2000

Llamando al puerto 2000

Second touch, port 4000

Llamando al puerto 4000

Third touch, port 8000

Llamando al puerto 8000

Once it is in the last address list we can enter by ssh without having to define any port. You can also see the time that the IP of our host machine will be in each address list, when the time of the last address list expires, the one that gives secure access to the router, it will kick us out of the router, having to repeat the sequence.

Connection by ssh without the need of the port because it is already in the address list that has connection permission.

Entrando al router sin necesidad de puertos por estar en la lista de direcciones con permisos

Inside Mikrotik from SSH, to confirm it you can see the name of the router, the interfaces and ip both on the side of the winbox on the left and on the side of the connection by ssh on the right of the image.

Conexión establecida por ssh, y comprobación de que estamos en el router, mostrando sus ip e interfaces

Note the color change of the powershell is due to the fact that once inside Mikrotik by ssh the letters could not be seen well, it must have changed to another color.

Check the sending of mail by gmail

To test that the sending of mail works correctly we go to Tools → Email and in the window that appears we click Send Email , a new window will appear, we fill in the fields where the first ones refer to our account with mikrotik, and then we define to which email we are going to send it and who sends it, as shown in the following image.

Envió de correo manualmente desde Mikrotik

After giving it to send, we check our mail to see if the message has reached us and to check that it works correctly.

Correo recibido

Check the dispatch of assigned logs

As a test to see if the error notice and dhcp created in the router work, we are going to have the logs open, the rules created and we are going to disconnect one of the wan interfaces that are as client dhcp.

Prueba de envío de errores por correo

As we can see in the logs, an email has been sent to notify us of a dhcp problem.

Desconexión del interfaz 3, y comprobación del envío de correo desde el log

If we now go to our email we can see how several emails have reached us, notifying us of what happened in the router with both the dhcp service and the interface, giving us various details each email.

Comprobación de la llegada de los correos

Check the automation of backup shipments

To test that both the scripts created and the scheduled tasks work correctly, we can modify the time of one of the files to correspond with the time we have at that time.

Modificar horario de la tarea para que concuerde con la hora actual

Or from the Script window we can select one of them and then click on the Run Script button.

Activar el Botón Run Scrip

The Run Count corresponds to the times the script has been mailed, or the times it has been executed. Keep in mind that in the period of time that we define in the tasks it is possible that there is an error or that some mail does not arrive if both scripts must be sent at the same time, so I recommend giving a margin between one email and another.

Next we check the emails that have reached us.

Correos recibidos del router con las tareas programadas

And the file that has come to us from this

Archivo de Bachup dentro del correo que ha llegado desde el router

Check meerkat performance

We are going to test how the meerkat works, for this we will first see the different meerkat logs and what each one of them gives us.

• suricata.log: Collects the events of the Suricata itself: initializations, reloads, errors, etc.

• stats.log: Collects regular statistics about the traffic that has been analyzed so far.

• fast.log: Collect the events triggered by the rules. It aims to give a quick and direct impression of events.

• eve.json: It collects, like the previous one, the events triggered by the rules, but it does so in JSON format, which allows it to be interpreted much easier later by external programs.

Well, once the different log files have been explained a bit, to do a little test we will create our own rule, for this we can do it in several ways, the most logical is to create a new text file in the default path that suricata currently uses which is / var / lib / suricata / rules , or we can also create a text file in the path / etc / suricata / rules which is created automatically when installing suricata-update, the problem with this is that we must specify its path in the configuration file of suricata in the section of default-rule-path , therefore it is more advisable to create it in the default path of / var / lib / suricata / rules .

Creando el archivo custom.rules

Once the text file has been created, which we can define as custom.rules , within this we add the following line “alert icmp any any -> any any (msg:" ICMP detected "; sid: 1000001;)” we exit and save, what the previous rule will do is create an alert (visible in the logs) every time it detects an ICMP packet.

Insertando la regla en custom.rules

Once the alert is created, we will define it in the suricata.yaml configuration file, look for rule-files , and add our rule which we define as custom.rules under suricata.rules . We save the file and restart suricata to load the new rules.

Agregando la regla creada manualmente al archivo suricata.yaml

Now we start meerkat with the following command

suricata -c /etc/suricata/suricata.yaml -i enp0s3

With the -c option we define the path of the configuration file, and with -i we define that it runs in PCAP mode, with which we define the name of the interface, which in case is enp0s3

Note . Before executing the above command, it is advisable to disable the packet download functions on the network interface on which Suricata listens with the following command.

ethtool -K enp0s3 gro off lro off

If we don't have the ethtool tool, we can install it with.

sudo apt-get install ethtool

Instalación de la herramienta ethtool

If when executing the command a line appears commenting Cannot change large-receive-offload, it means that our interface is not compatible with this function and therefore it will ignore it. However, we can verify this by running the following command.

ethtool -k enp0s3 | grep large

Which should respond to us with.

large-receive-offload: off [fixed]

Ejecución de los comandos ethtool

Once the above is done and confirmed, we execute the command

suricata -c /etc/suricata/suricata.yaml -i enp0s3

Arrancando suricata en modo PCAP

And we open two new terminals, in one of them we will execute the command tail -f /var/log/suricata/fast.log and in the other terminal we will execute the command tail -f /var/log/suricata/eve.json .

Having everything ready, we open a new terminal and ping 8.8.8.8 for example or we can also ping from a different computer to the computer that has suricata installed, if everything has gone well we should skip the information of the captured icmp.

Ping at 8.8.8.8 from the same machine.

Prueba ping 8.8.8.8 desde mismo equipo

Ping from a windows 10 to the computer that has suricata installed with ip 192.168.0.23.

Prueba ping desde diferente equipo a Suricata

Check operation of Suricata with Mikrotik

To carry out the test, we will start from the Phase 2 diagram with the Suricatas teams each linked to the master router and the other to the backup router.

Diagrama fase2 con Suricatas conectados a los Routers

Once Mikrotik is configured, we return to our Suricata, the first thing to do will be to create a folder, for example within the mikrotik folder created where we download the trafr tool, which we will call records .

Creando carpeta registro y cambiando a root

Inside this folder we execute the following command being as root since the rules of suricata are in a directory where only root has access. / usr / local / bin / trafr -s | suricata -c /etc/suricata/suricata.yaml -v -r / dev / stdin With this we start the trafr tool that is currently in / usr / local / bin, and what it collects is sent to suricata which will be running in pcap mode, sending everything to the directory defined with the -r option and processing them in order. The reason for executing the command in the created folder is because when using the -r option in pcap (offline) mode, suricata creates new .log files in the path where that command is executed, therefore instead of displaying the files in meerkat that by default are in the path / var / log / meerkat we visualize the new ones created.

Nuevos Logs creados al ejecutar Suricata en la carpeta registros

We open two new terminals, and we go to the route / mikrotik / registries , to be able to see the traffic that arrives we can use

tail -f fast.log

Or if we want more information we can use

tail -f eve.json | grep "ICMP detected"

Having our Suricata team ready to listen to the packets that arrive, we turn on from GNS3 a team of each local network that has internet access, in this example the pc of the lan2 network is turned on with ip 192.168.20.3 and a team of the dmz with ip 192.168.30.4 .

Preparando Suricata para recibir paquetes de Mikrotik

We check from Suricata if it collects the icmp that are sent, using the alert “alert icmp any any -> any any (msg:" ICMP detected "; sid: 1000001;)” and seeing it from the fast.log and eve.json .

First we ping from the computer whose ip is 192.168.20.3 .

We ping 1.1.1.1 .

ping al 1.1.1.1

We ping the www.marca.com page.

ping a marca

We ping the other computer on whose ip is 192.168.30.4 .

ping to gns3

Now we have to ping from the other computer whose ip is 192.168.30.4 . We first leave some separation in the two log files, to differentiate the new traffic captures.

We ping the www.google.com page.

ping google

We ping 9.9.9.9

ping al 9.9.9.9

We ping the previous computer whose ip is 192.168.20.3 .

ping al otro equipo de gns3

Check Layer 7 operation

To check the operation of layer 7, images will be captured where on the left side we will have the router with the mangle tab, which will be able to see how the packet counter increases in the 2 mangrove rules that were created for this purpose. And on the right side you will have an Ubuntu computer browsing the internet, in which it will try to enter the youporn and facebook page, which are blocked and will not have access, but will be able to enter another that is not defined in layer 7, such as the branding page.

Trying to get into youporn.

Block youporn

Trying to enter facebook, increase of counters of the mangle rules, which are underlined to differentiate them from the others.

Bloqueo a facebook

Attempt to enter brand.

Permitido marca