Tag: IT

  • IPSec configuration Ubuntu and Debian

    IPSec configuration Ubuntu and Debian

    What is happening with IPSec?

    Maybe you noticed, or not, but Fortinet company is abandoning SSL VPN and pushes IPSec VPN. They reason it with SSL VPN not being secure anymore. Which is fine, I guess? Maybe your company already moved to new versions of FortiVPN and you are now dealing with this, or it awaits you.

    Better security is great, right? Well, if you are using Windows or MacOS, you will likely face very few issues. If you are Linux user, you will be facing problems.

    While Fortinet pushed this change, they didn’t put advanced IPSec capabilities from their free FortiVPN clients, for Linux. Those configurations are behind a PAYWALL. You are required to purchase 50 licences / year, to get this thing. It’s truly “Create problem, sell solution thing”, but fret not!

    Challenges

    For Windows and MacOS users, new model comes with some benefits. Authentication can be tied with EntraID MFA and so on. But, on Linux it is bit trickier. So far, to my knowledge, only working way how to connect to IPSec VPN from Linux is by using Strongswan.

    Strongswan is TUI based package to configure and connect to VPNs. Now you probably start to see the problem. If your company will be using EntraID, even Strongswan is not going to help you. You will have hard times to conjure pop up Microsoft Account login window. So, when using Linux, you better hope, your company uses only basic IPSec.

    Another challenge you will be facing, is that every distribution has different approaches/packages. Fedora might use libreswan instead of strongswan and donn’t make started on NixOS.

    Let’s hope you are not System Administrator in some Software company, which has many Developer contractors and every has own distro, haha!

    IPSec and Debian?

    When this change first hit me, I was truly struggling to find way how to connect to VPN. I was trying Libreswan, Strongswan and it took me several days. We were going back and forth. But, I finally succeeded and found way, how to make Strongswan work on Debian based distros.

    Note: This what I will show you, is ONLY for specific configuration. That configuration is, as follows.

    • Debian based distribution (Frankly it goes same on every debian based distro)
    • IPSec with EAP and PSK configured.
    • Alignment of Jupiter and Saturn.

    How to configure IPSec on Debian.

    Let’s start with preparation of packages and our service:

    apt update
sudo apt install strongswan libstrongswan-extra-plugins libcharon-extra-plugins
sudo ipsec start

    Now, in your /etc directory, you will have two files ipsec.conf and ipsec.secrets.

    Those are your main files that will interest you.

    For EAP/PSK configuration you will first want to edit ipsec.conf file. Paste in this:

    Note: left = client, right = remote gateway.

    Config files

    #ipsec.conf
conn ipsecvpn
  keyexchange=ikev2 <RECOMMENDED TO USE ikev2>
  ike=<IKEV 1st PHASE PROPOSAL - CYPHER>
  esp=<IPSEC/ESP PHASE 2 PROPOSAL - CYPHER>
  dpdaction=<DEAD PEER DETECTION - CAN USE "clear">
  dpddelay=<HOW OFTEN CLIENT CHECKS IF ALIVE IN "s,h">
  dpdtimeout=<HOW LONG CLIENT WAITS BEFORE DC IN "s,h">
  rekey=<ALLOW RENEW KEYS "yes/no">
  left=%defaultroute <LEAVE AS IS>
  leftid=@<DOMAIN OR LOCAL FORTIGATE USERNAME>
  leftauth=eap-mschapv2 <AUTH METHOD FOR CLIENT Authenticate the Linux client using EAP-MSCHAPv2 username/password.>
  eap_identity=%identity <LEAVE AS IS>
  leftsourceip=%config <REQUEST VIRTUAL IP FROM FG>
  right=<PUBLIC IP OF YOUR FORTIGATE>
  rightid=<PUBLIC IP OF YOUR FORTIGATE>
  rightauth=<AUTH METHOD FOR FG SIDE CAN "psk">
  rightsubnet=<SUBNET YOU WILL BE USING>
  auto=add <CAN LEAVE AS IS>
  ikelifetime=86400s
  keylife=43200s

    Green is name of your connection.

    Yellow is guide what to fill, you can figure it out.

    Once you have these set, let’s go on ipsec.secrets

    # ipsec.secrets
<USERNAME HERE> : EAP "<PASSWORD HERE>"
@<USERNAME HERE> <DNS OF FORTIGATE HERE ex.vpn.example.com> : PSK "<PRESHARED KEY HERE>"

    VPN operation

    Now when you have your configuration files ready, you can start to operate your VPN. 

    # Let's load your configurations first.
sudo ipsec update
ipsec rereadsecrets
systemctl restart strongswan-starter

# ==Start==.Remember in ipsec.conf the green name?
ipsec up ipsecvpn

# ==Turn Off==
ipsec down ipsecvpn

    Conclusion

    And there you have it! It will really depend on your configuration and how complicated you have it.

    This article should serve you only as baseline from where to start. It can also serve as template, for your FortiGate configuration, so transition is painless for MacOs, Windows and even Linux.

    If I could choose, I wouldn’t buy/use Fortinet at all.

  • 7 useful security headers for NGINX.

    7 useful security headers for NGINX.

    So! I saw amazing video on the YouTube, which explains beautifully something obscure about NGINX, and that is headers. I had quite problem to understand headers, as in NGINX lore, they are quite on background. You will learn how to set it as reverse proxy, and then you just stop thinking about it. Only after some time, you will understand that there is more to NGINX as a whole. I stumbled across this video, and I found it super helpful. So, you do not have to watch it (I recommend you should), I wrote down most important headers and you can just copy, paste them into your configuration. Video link is down bellow!

    server_tokens off;

    Hides the NGINX version from HTTP headers. This makes it harder for attackers to identify the exact NGINX version and search for version-specific vulnerabilities.

    Place this in `/etc/nginx/nginx.conf`, inside the `http` block.

    more_clear_headers Server;

    Completely removes the `Server` header from HTTP responses.

    Requires the headers-more module:

    apt install libnginx-mod-http-headers-more-filter

    Place this in the public-facing NGINX `server` block, usually in `/etc/nginx/sites-available/*.conf`.

    add_header Content-Security-Policy “default-src ‘self’;” always;

    Restricts the browser to loading content only from the same origin as the website, unless other CSP rules allow additional sources. This helps control where scripts, images, styles, and other resources can be loaded from.

    Place this on the public-facing NGINX reverse proxy, usually inside the website’s `server` block.

    add_header X-Frame-Options “DENY” always;

    Prevents the website from being loaded inside an iframe. This helps protect against clickjacking attacks.

    Place this in the public-facing NGINX `server` block, or globally in the `http` block if it should apply to all sites.

    add_header X-Content-Type-Options “nosniff” always;

    Stops browsers from guessing file types. This prevents files from being interpreted as something else, such as treating an uploaded image or CSS file as executable JavaScript. This helps reduce some XSS risks.

    Place this in the public-facing NGINX `server` block, or globally in the `http` block if it should apply to all sites.

    proxy_hide_header X-Runtime;

    Removes the `X-Runtime` header from backend responses. This hides backend request processing time from clients.

    Use this on the reverse proxy, inside the relevant `location` or `server` block.

    proxy_hide_header X-Powered-By;

    Removes the `X-Powered-By` header from backend responses. This avoids exposing backend technologies such as PHP, Express, ASP.NET, Laravel, or framework versions.

    Use this on the reverse proxy, inside the relevant `location` or `server` block.

    Original explanation on YouTube:

    This text I wrote based on amazing video by The Lazy SysAdmin