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.
In the network configuration we leave everything in automatic, in the ipv4 tab
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
Finally we check that it has ping from the terminal and that it can surf the internet.
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.
And a ubuntu desktop with an interface that belongs to that same internal network
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
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.
We tried pinging from the terminal.
And to surf the 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.
Ping one of the dmz servers
Ssh connection to one of the dmz servers
No connection with a lan1 worker
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
No connection to dmz
Connecting to a worker on the lan1 network
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.
Ping with LAN2 Network Manager
No connection to the lan1 network
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.
No connection to dmz
No connection to the lan2 server manager
No internet connection
Connection to the LAN2 network administrator who maintains the LAN1
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.
Configured IP of the mikrotik router where we can see the IP of the wan and the different LANES
IP of the dmz server computer to which we are going to enter by ssh
Entering by ssh to the dmz server, using the wan ip of the mikrotik router
Checking that we are on the dmz server by seeing its ip
Try with tracepath from the dmz server being ssh from the host
Try with traceroute from the dmz server being ssh from the host
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Now we reconnect the ether6-LAN cable of the master router.
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.
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.
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.
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.
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.
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.
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
Second touch, port 4000
Third touch, port 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.
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.
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.
After giving it to send, we check our mail to see if the message has reached us and to check that it works correctly.
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.
As we can see in the logs, an email has been sent to notify us of a dhcp problem.
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.
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.
Or from the Script window we can select one of them and then click on the Run Script button.
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.
And the file that has come to us from this
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 .
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.
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.
Now we start meerkat with the following command
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.
If we don't have the ethtool tool, we can install it with.
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.
Which should respond to us with.
Once the above is done and confirmed, we execute the command
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.
Ping from a windows 10 to the computer that has suricata installed with ip 192.168.0.23.
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.
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 .
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.
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
Or if we want more information we can use
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 .
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 .
We ping the www.marca.com page.
We ping the other computer on whose ip is 192.168.30.4 .
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.
We ping 9.9.9.9
We ping the previous computer whose ip is 192.168.20.3 .
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.
Trying to enter facebook, increase of counters of the mangle rules, which are underlined to differentiate them from the others.
Attempt to enter brand.
Last updated
