Databases, Systems & Networks

source: fail2ban.org

Using geolocation to locate your attackers.

I use fail2ban on my servers to protect them from would-be attackers, if you don’t your either insanely nieve to the fact that somebody wants in your system, or your just wanting to see if you can get hacked. Most of the attackers I would assume are just after another « bot » in their « net », or maybe a place to host files.

Durzo hosts a script that allows you to log the attacks on you into a mysql database with geocoding, I thought this would be cool to use as I could see from where I was being attacked. I then got this working and another script to display the table in a web page so I could view the data easily.

I then found some scripts from Google to pull data from MySQL in a geolocation table and generate an XML file used to import into Google Maps. With some tweaking and customizing, I now have a map with the geolocation data as markers on the map. Not all the markers are right on a building, but they are close enough for me to see the areas from which attacks are coming.

Now on to the good stuff… Lire la suite…

Parfois que nous avons besoin de vous connecter via SSH à un autre ordinateur, nous trouvons que cet ordinateur que nous comptions SSH dans (ce que nous allons appeler « destiny ») peuvent utiliser NAT et, par conséquent, il doesn ' t compte avec une adresse IP publique que nous pourrions utiliser pour se connecter à lui, ou il peut être derrière un pare-feu qui a gagné ' t permettent l'accès de l'extérieur.

Si le « destin » peut réussir à établir une connexion SSH vers un autre ordinateur qui n'est accessible, nous pouvons utiliser ce deuxième ordinateur afin d'établir un tunnel SSH inverse à notre ordinateur « destiny », nous allons appeler ce deuxième ordinateur « origine » (même si elle n'est pas réellement l'ordinateur que nous allons utiliser pour gérer à distance les « cibles », mais qu'un pont).

Un tunnel SSH inverse fonctionne en connectant « destinée » à « l'origine » et puis en se servant cette connexion SSH dans « destin » de n'importe quel ordinateur connecté à « l'origine ». Ce tunnel SSH inverse devrait fonctionner dans la plupart des distributions Linux sans problème.

Alors, laisse supposer que nous avons à présent deux ordinateurs :

« L'origine » IP : aaa.bbb.ccc.ddd

« Destiny » IP : inconnue ou non disponible

Tout d'abord, nous établissons la connexion SSH de "destinée" à « l'origine », qui permet la fonctionnalité SSH inverse avec le paramètre – r :

SSH r 61999:localhost:22 [email protected]

Le premier nombre (61999) indique quel port on va pour utiliser « origine » pour vous connecter à « destiny », localhost est le nom de domaine que nous utiliserons pour cela aussi bien, et le dernier numéro (22) indique quel port est le « destin » écouter pour SSH.

Une fois que cette connexion est établie, et être connecté à le "origine" (peu importe si nous sommes connectés local ou à distance), nous pouvons établir la connexion au « destin » :

SSH p 61999 destiny_user@localhost

Effectivement, nous pouvons utiliser un ordinateur avec un accès SSH permanent comme un pont entre des ordinateurs qui ne sont pas autrement accessibles par l'intermédiaire de SSH. N'importe quel ordinateur connecté à le « origine » peut se connecter à autres ordinateurs avec inversion de tunneling SSH activé.

Saving iptables rules for reboot

On a server, iptables rules don’t reload automatically at reboot. You need to reload the rules using ax executable shell scripture a dedicated utility that will load them at the same time as the program itself, i.e. with the kernel.

Depending of the version of Linux you use, you can select different methods:

sudo su
iptables-save > /etc/iptables.rules

In /etc/network/if-pre-up.d/iptables, put:

#!/bin/sh
iptables-restore < /etc/iptables.rules
exit 0

After, in /etc/network/if-post-down.d/iptables, put:

#!/bin/sh
iptables-save -c > /etc/iptables.rules
if [ -f /etc/iptables.rules ];
       then iptables-restore < /etc/iptables.rules
fi
exit 0

After, give permission to the scripts:

sudo chmod +x /etc/network/if-post-down.d/iptables sudo chmod +x /etc/network/if-pre-up.d/iptables

Another scenario is to is to install iptables-persistent:

sudo apt-get install iptables-persistent

After it’s installed, you can save/reload iptables rules anytime:

    sudo /etc/init.d/iptables-persistent save 
    sudo /etc/init.d/iptables-persistent reload

Or if you use Ubuntu server 16.04, things are simpler:

    sudo netfilter-persistent save
    sudo netfilter-persistent reload

Using VMWare ESXi and PFsense as a network firewall/router

In most networks, you will have dedicated hardware to function as your “edge” (firewall/router). This is typically for the best, but there are always cases where you can’t put out that dedicated hardware. Sometimes it’s for cost reasons and sometimes it’s for complexity. In my particular case, I was installing an ESXi server in a datacenter and only had 2 amps of power to work with, of which my server took up ~1.8amps at peak load. So cost came into play and we simply couldn’t afford to put in dedicated hardware that could push enough bits. In such cases, it is possible the setup ESXi on the network edge, in a reasonably secure fashion, with PFSense acting as a firewall.

The most important requirement to this project is that your VMWare ESXi server has at least two network ports on it. One will be the WAN port, one will be the LAN port. Also throughout this tutorial I will use PFSense as my firewall/router OS of choice, however it is just an example that can be easily swapped out with any other virtualized firewall product. Some options include Palo Alto Networks, Fortinet, and even generic *NIX operating systems with the right forwarding/firewall setup.

Section 1 – VMWare Setup

Step 1 – Install & Connect to ESXi You should already have ESXi setup and connected via the VSphere client on Windows. It’s recommended that you static the IP address of the VMWare Management interface, if you’ve not done so already. Go to Configuration > Networking Rename the vSwitch interface you’re using to “LAN”
Step 2 – Add new interface You want “Virtual Machine” type
Step 3 – Select NIC You want to select your unused NIC (assuming you only have two)
Step 4 – Name it This is your “WAN” interface
Step 5 – Confirm you’ve got two networks You’ll notice that we’ve got two vSwitches now. The “LAN” switch has the Management network and is connected currently. The “WAN” switch has nothing, and the adapter is disconnected.

Section 2 – Virtual Machine Setup

Step 1 – New VM
Step 2 – Typical Setup
Step 3 – Name your VM
Step 4 – Select Datastore
Step 5 – OS Type If you’re using PFSense, select “Other” and “FreeBSD 64bit”
Step 6 – Two NICs Unlike most VMs with 1 NIC, add 2 NICs to this VM. Make sure one adapter is on “WAN” network and one adapter is on “LAN” network.
Step 7 – Allocated HD PFSense doesn’t need much space, but it should be allocated a 2:1 for swap (e.g. 4096 MB swap file for 2048 MB of RAM), plus some extra space for packages and logs may be useful.
Step 8 – Edit before completion
Step 9 – Final settings As this is my firewall, I want to make sure it is plenty fast. So I opted for 4 cores and 2 GB RAM. Also attach the CD drive to PFSense installer (be it datastore ISO or real USB/Optical drive).
Step 8 – Verify Network Hop back to Configuration > Networking and you should see something like this. Note: various VMs are all attached to the LAN vSwitch, however only PFsense VM is attached to both WAN & LAN (just like a real firewall).
Step 9 – VM Startup Go to Configuration > VM Startup/Shutdown Click Properties
Step 10 – Set PFSense to first boot order You may have other VMs that you want to auto-start, but as this is your firewall, it should be the first to start.

Section 3 – PFSense

Step 1 – Install PFSense Once you’ve installed PFSense, it will automatically configure its local interface to 192.168.1.1
Step 2 (Optional) – Change local network You can reconfigure the local network either via web interface (at the aforementioned IP: http://192.168.1.1) or command line
Step 3 – Configure WAN Again, this can be configured either via the web, or command line.
Step 4 – Plug in WAN cable
Step 5 – Test If you’ve got the ports configured properly (i.e. WAN hardware is WAN in VMWare and WAN in PFSense), you should be able to connect to the internet.

There are two big questions after building a setup like this, the first is security. Since PFSense is the host to provide an interface on the WAN, it should be the only method of ingress into your network. With no VMware management interface on the WAN, there should be no way for an outside party to access ESXi directly. I’ve used this setup successfully (and safely) before, as have others. However, you always need to balance your particular security concerns with the cost of dedicated devices.

The second question is remote management/maintenance/failure. Managing ESXi remotely is easy, if you setup a VPN on your PFSense VM. Without that (or similar) you will not be able to remotely manage the box (by design). But what happens if there is a failure either in the VMWare hardware or the PFSense virtual machine? That’s the big failing point of this setup – you’re down. If, for whatever reason, PFsense dies – your network is offline and you cannot remotely manage it. If this hardware is installed in a dateacenter, you’d need to either get in there yourself or remote hands reboot. Something to keep in mind when balancing the cost issue. OF course, if it’s local (say you use this at home), then it’s not such a big deal.
I will note that this is the setup I use in my home network, which doubles as my homelab. Having a VM for a firewall gives me a lot of flexibility, like adding an entirely separate vSwitched network for experimental VMs. I can also swap out the firewall VM for another one with next to no downtime. It also allows me to skip one more piece of hardware at home which would add to my otherwise hefty powerbill.

Source: obviate.io