Description of the situation - target

  • In my current network I have placed several web servers (e.g. Joomla! or Nextcloud) in the DMZ behind the firewall (OPNSense).

  • As the SSL certificates are managed by the OPNSense, I use "HAProxy" on the OPNSense as a reverse proxy to redirect the requests to the corresponding web server.

  • I would like to protect the web servers against brute force attacks and want to use "fail2ban" for this purpose.

Problems

Following problems / steps must be done:

  1. the login job is done by the app (Joomla) and not by the web server
    => fail2ban must look after the logs of the webapp ans not after the logs of the web server

  2. the web servers get requests only from the OPNSense.
    In the stock configuration the logs of the servers only show the IP of the OPNSense for the incomming connection.
    So fail2ban would block the HAProxy, it means all incomming connections. It is good for protection, but makes troubles for the "good" requests!!
    => As fail2ban runs on the web servers, we must find a way to transmit the real IP of the requesting machine (can bee the attacker too!) through the OPNSense to the servers

  3. installation and configuration of fail2ban on the web servers

  4. Make the web servers and OPNSense work together:
    The logs of the web servers show now the IP of the requesting/attacking machine. It is good but this doen't allow fail2ban to block the incomming traffic from this machine because viewed for the iptables of the servers, the traffic is further comming from the OPNSense.
    With other words, Apache kowns the "external IP" from the request, but the request continues to arrive from the OPNSense => so fail2ban will block over the iptables the traffic comming from the "external IP" as if the "external IP" would connect directely to the web servers. But as the traffic comes from the HAProxy, it is not blocked by the iptables => fail2ban would ban nothing in reality.
    => Therefore. the blocking action can't be done by the web servers, but it must be done "earlier", therefore by the OPNSense. The web servers must also be able to tell OPNSense "please be so kind and don't forward requests coming from "external IP", this is a mess maker".

Make it run

 Please read my notes (currently in french!!) into the wiki for the different steps explained above - I'm too lazy to rewrite them here.

Even if it looks confusing, it makes sense (for me!) to configure the different machines in a different order than the above "logical" sequences.

  1. step one is the installation and the basic configuration of fail2ban on the web server
    ⇒ can be tested # fail2ban-client set <one_of_the_enabled_jail> banip 192.168.1.1 with for exemple
  2. step two forwards the IP of the requesting machine trough the OPNSense to the Joomla machine
    ⇒ the logs of the web server and of Joomla should show another IP than the one of the HAPRoxy
  3. step three concists into making a new jail looking after the logs of joomla giving the IP of the connecting machine and running a script for communication with the OPNSense
    ⇒ can be tested by taking a wrong password by trying to login into Joomla
  4. step four configures the OPNSense to block the IP given by fail2ban of the web server
  5. step five is communicating the IP to ban from the web server to the OPNSense

Conclusion

A lot of things, but all is logical and should do the job in a correct way.

The pfSense is the central point of the network and allows, or not, the machines to communicate together and restrict access to only what is necessary.

pfSense is an absolutely amazing distribution:

  • on one hand it is very powerfull, has got a very good web-interface, gives best possibilities of settings, is absolutely compatible with a professional use
  • and on the other hand it is accessible for hobbyists and no skilled admins. The only 3 main things you have to understand for the beginning are:
    • don't modify the settings that you don't understand what they do => pfSense has go a very good (and safe!) default configuration.
    • making a NAT-rule makes (if checked) the corresponding firewall rules
    •  the firewall rules are applied from the top to the bottom.
  • very stable, runs days after days without any problem, needs nearby no administrative task between the rare updates, so that you can almost forget the machine!

I run the pfSense on a dedicated miniPC: several network interfaces, fanless, storage on integrated SSD, power consumption =~8-10W

Splitted internal network LAN

The top target of this "project" is quite to make the opposite of a SME-server!
SME-server is a very good "all-in-one" solution and now I wanted to build a "all-in-many" solution with following specifications:

  • achieve at least all the functions implemented into my running SME
  • achieve them with at least the same level of security (= no dirty "solution")

why?

One day, due to the breakdown of the maionboard of the SME without any warning, I had to use suddenly such a decentralized network in a productiv way.

After it was clear that the hardware of the SME was broken, I tried to run the backup server as a production server by using "affa --rise". Unfornately, because of Murphy's law, it didn't work as expected this time (inspite I had positivly tested previously the conversion of the server), about 1/3 of the services couldn't be used.
I restored by hand in a dirty way the main fonctions of the SME server to get the time to build something different.
It was for me clear that "all-in-one" is too risky: "loosing one" can result in "loosing all" and this produces .......some stress!

How?

Steps:

  • In a first time, I used the (low power) Proxmox testing machine to build a virtual network an to test the architecture: how many machines? Which OS? Which services/functions done by which machine? What is the strategy for backups?
  • Then I ran the Proxmox testing machine in a productive way to confirm that the strategy is OK or in order to correct some unexpected problems. In addition, I wanted to shutdown the SME as soon as possible and reuse the hardware to achieve backups of the Proxmox.
    In the meantime the hardware of the "old" production SME has been repaired I could use it for a NAS.
  • Finally I bought new hardware for the pfSense and for the Proxmox.

The general concept:

The general concept is in fact very simple: (diagram coming soon!!)


Architecture:

  • very basic with WAN, DMZ and LAN. A router/firewall managing the communication between the parts of the network.
  • DMZ is accessible from the WAN only on the ports that are in use.
  • no communication from WAN to LAN and from DMZ to LAN

Distributions:

I tried to use the "best" (in my point of view!) specific distribution to achieve each group of fonctions.

  • Router/firewall: pfSense
  • Email-staff: NethServer as a VM
  • Main web applications: Nethserver as a VM
  • Secondary web applications: over Docker containers on a Debian VM
  • Files and storage: FreeNAS
  • Host for VMs: Proxmox

Targets of the first steps:

  • to configure the hypervisor
  • install and update the "basic" machines
  • reach the WAN from the LAN
  • be able to ping the WAN interface from the internet.

Joomla templates by a4joomla
modifié par GuedeL
Joomla3 Appliance - Powered by TurnKey Linux