One place for hosting & domains

      Configure

      Install and Configure Hubzilla


      Recent developments have led to a renewed interest in federated web applications. Much of the interest centers around the Twitter alternative Mastodon. However, there are many other federated applications worthy of attention. For example, the federated Hubzilla application allows users to create interconnected websites and channels. This guide provides an introduction to the Hubzilla application and explains how to install and configure it.

      What is the Federated Web?

      The federated web is also known as the Fediverse, which stands for “federated universe”. It is a collection of servers that are independent, but can communicate and interact with one another. The Fediverse is commonly used to host web content, including websites, social networks, and blogs. Some examples of federated web applications include Hubzilla, Friendica, Mastodon, and Pleroma.

      Communication protocols based on open standards allow the servers and users to communicate with each other across software boundaries. A user account or identity can potentially be used to create or access content on any server within the federation. In most cases, access control lists are used to control distribution and content creation rights.

      What is Hubzilla?

      Hubzilla is a highly versatile, free, and open source application. It allows users to create connected websites and tools in a modular fashion. Some of the main Hubzilla features include websites, social media, file sharing, photo sharing, forums, chat rooms, and calendars.

      In Hubzilla, all communications, content, permissions, and user identities are distributed across the federation. Hubzilla uses the ZOT web framework to enable these secure decentralized services. ZOT is a JSON-based communication framework designed with decentralization in mind. Hubzilla channels use the Open Web Auth (OWA) protocol to silently identify and authenticate themselves and access server resources. OWA is similar to OpenID but it is more efficient and does not require the Domain Name System (DNS). However, Hubzilla allows users to use OpenID to log in to off-grid sites.

      Hubzilla requires common web server technologies to operate, including a Linux LAMP stack or equivalent. A typical LAMP stack includes the Apache web server, the MySQL or MariaDB relational database management system (RDBMS), and the PHP programming language.

      Hubzilla uses a specific terminology to describe the relationship between servers and application users.

      • Hub: This is an individual server running Hubzilla. Each hub can host users and web content. Hubzilla allows anyone to run their own hub.
      • Grid: This is a decentralized network of hubs. A grid allows hubs, and therefore individual users, to connect with each other. Hubs communicate using the ZOT protocol and Hubzilla’s messaging system. However, a hub can be used as a stand-alone system. Hubs are not required to connect to the wider grid.
      • Channel: This is a Hubzilla entity within the grid. A channel can be an application or user, but it can also be a web page, blog, or forum. A user interacts with the Hubzilla grid using their own personalized channel called the me channel. Each channel has its own stream and can also connect to other channels. For example, a person can subscribe to a forum, and blog updates can be funneled to a web page. A channel can be identified through its unique tag [email protected]. Every channel is cryptographically secured and has its own set of authentication rights.

      Hubzilla follows the key federated principle of nomadic identity. This means a channel or account is not tied to a particular server and does not have a traditional server-based account. Channel authentication happens independently across the grid. This means users can move their identity from one hub to another, taking their data and connections with them. In addition, Hubzilla allows channels to clone themselves on multiple hubs. This enhances resiliency against external threats, including power failures and censorship.

      Hubzilla includes a sophisticated access control mechanism. It allocates grid-wide user permissions on a granular level. The various content channels are identity-aware. This allows for a single sign-on (SSO) service across the various channels. This is a huge difference from traditional websites, which authenticate users independently. All channel content includes access control permissions, so it is possible for different users to see dramatically different channel feeds. It is also possible to set permissions for users on an entirely different hub.

      Hubzilla is a complicated and multi-faceted application. It provides many features, including:

      • A wide variety of plug-ins for creating channel content and web applications. The Comanche description language provides a toolkit for building web pages, and users can apply customizable interface, themes, and widgets to their pages.
      • Built-in social network capabilities, including chat rooms. Hubzilla provides federation support to connect to Diaspora, GNU Social, Mastodon, and other applications. Hubzilla can also serve as a client application for Twitter, WordPress, and other applications, and distribute copies of a new update.
      • Cloud file storage functionality. Files can be shared or published using Hubzilla’s access control mechanism.
      • The ability to create a Wiki page for each channel.
      • An affinity slider allows users to determine how close they are to another connection or channel. This allows users to select what content they want to see. Only channels within the range of the affinity slider are displayed.
      • Connection filtering based on user-defined criteria.
      • Single sign-on across the grid.
      • An access-controlled photo album feature.
      • A powerful calendar feature, allowing users to share events and coordinate attendance. Hubzilla supports most popular calendar formats.
      • A flexible API for third-party use to configure and access hubs and create content.

      There are also a few drawbacks to using Hubzilla, including:

      • Some of the features and tools are not intuitive.
      • Documentation on Hubzilla is fragmented, disorganized, and incomplete.
      • Hubzilla lacks a solid mobile implementation.
      • It has a smaller user base than Mastodon or other federated applications.

      For more information about Hubzilla and its features, see the Hubzilla Documentation.

      Before You Begin

      1. If you have not already done so, create a Linode account and Compute Instance. See our Getting Started with Linode and Creating a Compute Instance guides.

      2. Follow our Setting Up and Securing a Compute Instance guide to update your system. You may also wish to set the timezone, configure your hostname, create a limited user account, and harden SSH access.

      3. Assign a domain name for the Hubzilla hub and point it to the IP address of the server. For information on domain names and pointing a domain name to a Linode, see the Linode DNS Manager guide.

      4. Enable email on the Linode server to allow Hubzilla to send out registration emails containing verification codes. Hubzilla requires a working mail server to authenticate new users. For more information on setting up a mail server, see our guides on email.

      Note
      This guide is written for a non-root user. Commands that require elevated privileges are prefixed with sudo. If you are not familiar with the sudo command, see the Users and Groups guide.

      How to Install Hubzilla

      Before downloading and installing Hubzilla, Linux users must install and configure some form of LAMP stack. A virtual host for the Hubzilla site is also mandatory. The following instructions are designed for Ubuntu 22.04 LTS, but are generally applicable to most Linux distributions.

      Install the LAMP Stack

      Hubzilla relies upon a LAMP stack consisting of the Apache web server, the MariaDB database, and the PHP programming language. The MySQL database can be substituted for MariaDB. Other substitutions are possible and might improve performance, but Hubzilla does not explicitly support them.

      1. Ensure the Ubuntu packages are up to date. Reboot the system if advised to do so.

        sudo apt-get update -y && sudo apt-get upgrade -y
      2. Install the Apache web server and the MariaDB RDBMS.

        sudo apt install apache2 mariadb-server -y
      3. Install PHP, including all required PHP libraries, along with some additional utilities.

        Note

        Hubzilla requires PHP release 8.0 or higher. The following command installs the current PHP release 8.1. To confirm the release of PHP in use, run the command php -v.

        sudo apt install openssh-server git php php-fpm php-curl php-gd php-mbstring php-xml php-mysql php-zip php-json php-cli imagemagick fail2ban wget libapache2-mod-fcgid -y
      4. Use the systemctl command to ensure Apache and MariaDB are running and configured to start automatically at boot time.

        sudo systemctl start apache2
        sudo systemctl enable apache2
        sudo systemctl start mysql
        sudo systemctl enable mysql
      5. Verify Apache is running using the systemctl status command.

        sudo systemctl status apache2
        apache2.service - The Apache HTTP Server
            Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
            Active: active (running) since Wed 2022-11-16 13:38:25 UTC; 10min ago
            
      6. Configure the firewall to allow Apache connections. Ensure SSH connections are also allowed.

        Note

        If you intend to use SSL to secure the Hubzilla installation, use the Apache Full profile. Otherwise, enable the Apache profile. Hubzilla tests the well-known HTTPS port first, so this port must not be open unless HTTPS is used. HTTPS is highly recommended for enhanced security. For conciseness, this guide does not configure HTTPS. However, the basic Hubzilla installation process is the same in both cases.

        sudo ufw allow OpenSSH
        sudo ufw allow in "Apache"
        sudo ufw enable
      7. Ensure the firewall is enabled.

        Status: active
        
        To                         Action      From
        --                         ------      ----
        OpenSSH                    ALLOW       Anywhere
        Apache                     ALLOW       Anywhere
        OpenSSH (v6)               ALLOW       Anywhere (v6)
        Apache (v6)                ALLOW       Anywhere (v6)
            
      8. Visit the IP address or domain name of the server. The Apache2 Default Page should be displayed.

      Configure the LAMP Stack

      1. Enhance security for the MariaDB installation using the mysql_secure_installation utility. When prompted, answer the questions as follows:

        • For Enter current password for root (enter for none): enter the database password for the root account. If there is no password, hit the Enter key.

        • For Switch to unix_socket authentication and Change the root password?, enter n.

        • For Remove anonymous users?, Disallow root login remotely?, Remove test database and access to it? and Reload privilege tables now?, enter Y.

          sudo mysql_secure_installation
      2. Log in to MariaDB. Provide the root password if necessary.

      3. Create a hubzilla database for the application to use.

        CREATE DATABASE hubzilla;
      4. Create a user for the new database. Supply a unique password in place of mypassword.

        CREATE USER 'hubzilla'@'localhost' IDENTIFIED BY 'mypassword';
      5. Grant all privileges for the hubzilla database to the new user. Flush the privileges and exit.

        GRANT ALL PRIVILEGES ON hubzilla.* TO 'hubzilla'@'localhost';
        FLUSH PRIVILEGES;
        EXIT;
      6. Hubzilla requires the mpm_event module. To enable this module, first stop Apache and disable php-8.1 and mpm_prefork.

        Note

        Disable the php module associated with the current PHP release. The format of the module name is php-releasenumber, where the release number is the major and minor release of PHP. Use the command php -v to find this release information.

        sudo systemctl stop apache2
        sudo a2dismod php8.1
        sudo a2dismod mpm_prefork
      7. Enable the PHP rewrite and mpm_event modules.

        sudo a2enmod rewrite
        sudo a2enmod mpm_event
      8. Connect Apache to the fpm mechanism. Enable the following modules and configurations.

        sudo a2enconf php8.1-fpm
        sudo a2enmod proxy
        sudo a2enmod proxy_fcgi
      9. Restart Apache and verify it is active. If the restart fails, run the sudo apachectl configtest command. Review and correct any errors.

        sudo systemctl restart apache2
        sudo systemctl status apache2

      Configure A Hubzilla Virtual Host

      Hubzilla requires its own virtual host to function properly. Create a new hubzilla.conf file inside etc/apache2/sites-available and then enable it. To create the virtual host file, follow these steps.

      1. Change to the /etc/apache2/sites-available/ directory and create the new hubzilla.conf file.

        cd /etc/apache2/sites-available
        sudo nano hubzilla.conf
      2. Add the following information to the file. For the ServerAdmin and ServerName fields, replace example.com with the name of the Hubzilla domain. In the ProxyPassMatch variable, use the release number of the local instance of PHP in place of 8.1 for php8.1-fpm. Save and close the file.

        File: /etc/apache2/sites-available/hubzilla.conf
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        
        <VirtualHost *:80>
            ServerAdmin [email protected]
            ServerName example.com
            DocumentRoot /var/www/html/hubzilla
            ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/run/php/php8.1-fpm.sock|fcgi://localhost/var/www/html/hubzilla
            <Directory /var/www/html/>
                Options Indexes FollowSymLinks
                AllowOverride All
                Order allow,deny
                allow from all
            </Directory>
            ErrorLog ${APACHE_LOG_DIR}/hubzilla_error.log
            LogLevel warn
            CustomLog ${APACHE_LOG_DIR}/hubzilla_access.log combined
        </VirtualHost>
      3. Enable the new site.

      4. Optional For extra security, disable the default Apache site.

        sudo a2dissite 000-default.conf
      5. Restart Apache and verify its status.

        sudo systemctl restart apache2
        sudo systemctl status apache2

      Installing and Configuring Hubzilla

      The LAMP stack is now fully configured and ready for Hubzilla. Use git to download Hubzilla and install the add-ons. Before Hubzilla is ready for use, some permissions must also be changed. A cron job for proper Hubzilla maintenance must also be added.

      1. Change directory to /var/www/html.

      2. Use git to clone the latest release of Hubzilla from the code base.

        sudo git clone https://framagit.org/hubzilla/core.git hubzilla
      3. Change to the hubzilla directory and install the add-ons.

        cd hubzilla
        sudo util/add_addon_repo https://framagit.org/hubzilla/addons addons-official
      4. Create the store directory and ensure it is writable.

        sudo mkdir -p "store/[data]/smarty3"
      5. Change ownership and permissions for the hubzilla directory.

        sudo chown -R www-data:www-data /var/www/html/hubzilla/
        sudo chmod -R 755 /var/www/html/hubzilla/
      6. Optional To access Hubzilla using HTTPS, which Hubzilla recommends, install certbot and use it to request and install a Let’s Encrypt certificate. For further instructions, see the Linode guide on How to Use Certbot to Enable HTTPS.

      7. Add a cron task to update the site every 10 minutes. Run the crontab -e command to edit the list of root cron jobs.

      8. Add the following line to the end of the cron file. usr/bin/php represents the path to the PHP installation. Before proceeding, confirm the location of PHP using the command which php.

        */10 * * * *    cd /var/www/html/hubzilla; /usr/bin/php Zotlabs/Daemon/Master.php Cron > /dev/null 2>&1

      Configuring Hubzilla

      To initialize Hubzilla and get it ready for deployment, use the simple web interface. Follow these steps to configure Hubzilla.

      1. Using a web browser, navigate to the domain name of the Hubzilla server. Use the https prefix if TLS is enabled, otherwise use http.

      2. The web server displays the Hubzilla Server - Setup page. Ensure all options are selected and click Next.

        Hubzilla Server Setup

      3. Hubzilla displays the Database Connection page. Enter the login name, password, and database name for the MariaDB database. The login name and database name are both hubzilla. For the password, enter the password for the hubzilla user. Select the Submit button to proceed.

        Hubzilla Database Setup

      4. Hubzilla proceeds to the Site settings page. Enter an email address for the site administrator and select the default time zone. The Website URL must be set to the domain name for the Hubzilla server. Click Submit to continue.

        Note

        The administration email must contain a valid email address. Hubzilla sends a verification email to the account to confirm the registration.

        Hubzilla Site Settings

      5. Hubzilla confirms the installation is successful. This page also provides a link to the registration page to register as a new member. You must register for an account before you can use Hubzilla. Click the link to register now. To register later, visit the domain name of the Hubzilla server.

        Hubzilla Setup Confirmation

      6. On the Registration page, enter an account name, a short nickname to represent the channel on the site, a valid email address, and a password. If registering as an administrator, use the administrator email provided earlier in the Hubzilla site settings. Select the checkbox to agree to the terms of service and click Register.

        Note

        After selecting Register, Hubzilla must send an email to the email address of the account. The Linode must have email turned on to complete this process.

        For non-production Hubzilla testing, it is possible to remove the mail server requirements by editing a Hubzilla configuration file. To do so, open the .htconfig.php file located at /var/www/html/hubzilla and change the 1 in the following line:

        File: /var/www/html/hubzilla/.htconfig.php
        1
        
        App::$config['system']['verify_email'] = 1;

        To instead be a 0:

        File: /var/www/html/hubzilla/.htconfig.php
        1
        
        App::$config['system']['verify_email'] = 0;

        This configuration change is not recommended on production installations.

        Hubzilla Registration

      7. Hubzilla sends an email with a verification token to the account address. Enter the registration token on the next page to complete the registration.

        Hubzilla Verification

      For information on how to use Hubzilla’s features, see the Hubzilla user guide.

      Conclusion

      Hubzilla is a federated web site that allows users to create shared interconnected web pages, blogs, social media feeds, and other interactive material. Each Hubzilla hub is connected to other hubs to form a grid. Hubzilla is based around channels. A channel can represent either users or web entities. Hubzilla uses a nomadic identity that allows users to access different hubs through an independent account. A fine-grained access control system determines who can create or view channel content.

      To use Hubzilla, first install and configure a LAMP stack, including Apache, MariaDB, and PHP. Then use git to install Hubzilla. Configure Hubzilla and create an administrator account using Hubzilla’s online interface. For more information on Hubzilla, see the Hubzilla website.

      More Information

      You may wish to consult the following resources for additional information
      on this topic. While these are provided in the hope that they will be
      useful, please note that we cannot vouch for the accuracy or timeliness of
      externally hosted materials.



      Source link

      Configure Linux as a Router (IP Forwarding)


      A computer network is a collection of computer systems that can communicate with each other. To communicate with a computer that’s on a different network, a system needs a way to connect to that other network. A router is a system that acts as a intermediary between multiple different networks. It receives traffic from one network that is ultimately destined for another. It’s able to identify where a particular packet should be delivered and then forward that packet over the appropriate network interface.

      There are lots of options for off-the-shelf router solutions for both home and enterprise. In most cases, these solutions are preferred as they are relatively easy to configure, have lots of features, tend to have a user-friendly management interface, and may come with support options. Under the hood, these routers are stripped down computers running common operating systems, like Linux.

      Instead of using one of these pre-built solutions, you can create your own using any Linux server, like a Linode Compute Instance. Using routing software like iptables, you have total control over configuring a router and firewall to suit your individual needs. This guide covers how to configure a Linux system as a basic router, including enabling IP forwarding and configuring iptables.

      Use Cases for a Cloud-based Router

      Many workloads benefit from custom routing or port forwarding solutions, including those workloads hosted on cloud platforms like Linode. For example, it’s common practice for security-minded applications to connect most of their systems together through a private network, like a VLAN. These systems might need access to an outside network, like other VLANs or the public internet. Instead of giving each one their own interface to the other network, one system on the private network can act as a router. The router is configured with multiple network interfaces (one to the private VLAN and one to other network) and forwards packets from one interface to another. This can make monitoring, controlling, and securing traffic much easier, as it can all be done from a single system. Linode Compute Instances can be configured with up to 3 interfaces, each connecting to either the public internet or a private VLAN.

      • Connect systems on private VLAN to the public internet.
      • Connect systems on two separate private VLANs.
      • Forward IPv6 addresses from a /56 routed range.

      Configure a Linux System as a Router

      1. Deploy at least 2 Compute Instances (or other virtual machines) to the same data center. All systems should be connected to the same private network, like a
        VLAN. One system should be designated as the router and should also be connected to the public internet or a different private network. See
        Deploy Compute Instances.
      2. Enable IP forwarding on the Compute Instance designated as the router. See
        Enable IP Forwarding.
      3. Configure the routing software on that same instance (the router). This guide covers using iptables, but you can also use other software. See
        Configure iptables.
      4. Define a gateway on each system other than the router. This gateway should point to the router’s IP address on that network. See
        Define the Gateway.

      Deploy Compute Instances

      To get started, you can use the Linode platform to deploy multiple Compute Instances. These can mimic a basic application that is operating on a private VLAN with a single router. If you already have an application deployed and just wish to know how to configure ip forwarding or iptables, you can skip this section.

      1. Deploy 2 or more Compute Instances and designate one as the router. Each of these should be deployed to the same region. On the deployment page, you can skip the VLAN section for now. See
        Creating a Compute Instance to learn how to deploy Linode Compute Instances.

      2. On each Compute Instance other than the router, edit the instance’s configuration profile. See
        Managing Configuration Profiles for information on viewing and editing configuration profiles.

        • On the Compute Instance designated as the router, leave eth0 as the public internet and set eth1 to be configured as a VLAN. Enter a name for the VLAN and assign it an IP address from whichever subnet range you wish to use. For instance, if you wish to use the 10.0.2.0/24 subnet range, assign the IP address 10.0.2.1/24. By convention, the router should be assigned the value of 1 in the last segment.
        • On each Compute Instance other than the router, remove all existing network interfaces. Set eth0 as a VLAN, select the VLAN you just created, and enter another IP address within your desired subnet (such as 10.0.2.2/24 and 10.0.2.3/24).
      3. Confirm that
        Network Helper is enabled and reboot each Compute Instance for the changes to take effect.

      4. Test the connectivity on each Compute Instance to ensure proper configuration. Log in to each instance and confirm the following is true:

        • Ping the VLAN IPv4 address of another system within the same VLAN. Each Compute Instance should be able to ping the IP addresses of all other instances within that VLAN.

          ping 10.0.2.1
          
        • Ping an IP address or website of a system on the public internet. This ping should only be successful for the Compute Instance configured as the router.

          ping linode.com
          

      Enable IP Forwarding

      IP forwarding plays a fundamental role on a router. This is the functionality that allows a router to forward traffic from one network interface to another network interface. In this way, it allows computers on one network to reach a computer on a different network (when configured along with routing software). Forwarding for both IPv4 and IPv6 addresses are controlled within the Linux kernel. The following kernel parameters are used to enable or disable IPv4 and IPv6 forwarding, respectively.

      • IPv4: net.ipv4.ip_forward or net.ipv4.conf.all.forwarding
      • IPv6: net.ipv6.conf.all.forwarding

      By default, forwarding is disabled on most Linux systems. To configure Linux as a router, this needs to be enabled. To enable forwarding, the corresponding parameter should be set to 1. A value of 0 indicates that forwarding is disabled. To update these kernel parameters, edit the /etc/sysctl.conf file as shown in the steps below.

      1. Log in to the Linux system you intend to use as a router. You can use
        SSH or
        Lish (if you’re using a Linode Compute Instance).

      2. Determine if IPv4 forwarding is currently enabled or disabled. The command below outputs the value of the given parameter. A value of 1 indicates that the setting is enabled, while 0 indicates it is disabled. If you intend to configure IPv6 forwarding, check that kernel parameter as well.

        sudo sysctl net.ipv4.ip_forward
        

        If this parameter is disabled (or otherwise not in the desired state), continue with the instructions below.

      3. Open the file /etc/sysctl.conf using your preferred command-line editor, such as
        nano.

        sudo nano /etc/sysctl.conf
        
      4. Find the line corresponding with the type of forwarding you wish to enable, uncomment it, and set the value to 1. Alternatively, you can add the lines anywhere in the file.

        File: /etc/sysctl.conf
        1
        2
        3
        4
        5
        6
        7
        
        ...
        ## Configure IPv4 forwarding
        net.ipv4.ip_forward = 1
        
        ## Configure IPv6 forwarding
        net.ipv6.conf.all.forwarding = 1
        ...
      5. After the changes have been saved, apply the changes by running the following command or by rebooting the machine.

        sudo sysctl -p
        

      Configure iptables

      The iptables utility can serve as both a firewall (through the default filter table) and as a router (such as when using the nat table). This section covers how to configure iptables to function as a basic router. If you prefer, you can use any other firewall or routing software, such as
      nftables or a commercial application.

      1. Log in to the Linux system you intend to use as a router. You can use
        SSH or
        Lish (if you’re using a Linode Compute Instance).

      2. Review the existing iptables rules. If you are on a fresh installation of Linux and do not have any preconfigured rules, the output of the below command should by empty.

        iptables-save
        

        If do receive output, look for any rules that might interfere with your intended configuration. If you are unsure, you may want to consult your system administrator or the
        iptables documentation. If needed, you can flush your iptables rules and allow all traffic.

        iptables -F
        iptables -X
        iptables -t nat -F
        iptables -t nat -X
        iptables -t mangle -F
        iptables -t mangle -X
        iptables -P INPUT ACCEPT
        iptables -P OUTPUT ACCEPT
        iptables -P FORWARD ACCEPT
        
      3. Configure iptables to allow port forwarding. This is the default setting for many systems.

        iptables -A FORWARD -j ACCEPT
        
      4. Next, configure NAT (
        network address translation) on iptables. This modifies the IP address details in network packets, allowing all systems on the private network to share the same public IP address of the router. Add the following iptables rule, replacing 10.0.2.0/24 with the subnet of your private VLAN.

        iptables -t nat -s 10.0.2.0/24 -A POSTROUTING -j MASQUERADE
        

        You can also forgo specifying any specific subnet and allow NAT over all traffic by using the command below.

        iptables -t nat -A POSTROUTING -j MASQUERADE
        
      5. By default, iptables rules are ephemeral. To make these changes persistent, install the iptables-persistent package. When you do this, the rules saved within /etc/iptables/rules.v4 (and rules.v6 for IPv6) are loaded when the system boots up. You can continue making changes to iptables as normal. When you are ready to save, save the output of
        iptables-save to the /etc/iptables/rules.v4 (or rules.v6) file. For more information, see the relevant section with the
        Controlling Network Traffic with iptables guide.

        iptables-save | sudo tee /etc/iptables/rules.v4
        

      Define the Gateway

      The last step is to manually adjust the network configuration settings for each Compute Instance other than the router.

      1. Log in to the
        Cloud Manager and disable
        Network Helper for each non-router Compute Instance you’ve deployed. While Network Helper was useful for automatically configuring the VLAN IP addresses, the configuration files controlled by Network Helper now need to be manually edited.

      2. Log in to each Linux system that is not designated as the router. You can use
        SSH or
        Lish (if you’re using a Linode Compute Instance).

      3. Edit the configuration file that contains the settings for the private VLAN interface. This name and location of this file depends on the Linux distribution you are using. See the
        Manual Network Configuration on a Compute Instance series of guides and select the specific guide for your distribution. For a system running
        ifupdown on Debian 10, the network configuration is typically stored within /etc/network/interfaces.

        sudo nano /etc/network/interfaces
        
      4. Within this file, adjust the parameter that defines the gateway for the VLAN interface. The value should be set to the IP address assigned to the router’s VLAN interface, such as 10.0.2.1 if you’ve used the example in this guide. For a system running
        ifupdown on Debian 10, you can add the gateway parameter in the location shown in the example below.

        File: /etc/network/interfaces
        1
        2
        3
        4
        
        ...
        iface eth0 inet static
            address 10.0.2.2/24
            gateway 10.0.2.1
      5. After those settings have been saved, restart the Compute Instance or run the corresponding command to apply the changes. Continuing to use
        ifupdown as an example, run the command below to apply the new network configuration settings.

        sudo ifdown eth0 && sudo ip addr flush eth0 && sudo ifup eth0
        

      Test the Connection

      To verify the configuration settings are correct, run the same tests that were used within the last step of the
      Deploy Compute Instances section. Specifically, ping a public IP address or domain from a Compute Instance within the private VLAN (that’s not designated as the router). This ping should now complete successfully, indicating that the network traffic was successfully forwarded through the router to the public internet.

      ping linode.com



      Source link

      How To Configure Suricata as an Intrusion Prevention System (IPS) on Rocky Linux 8


      Not using Rocky Linux 8?


      Choose a different version or distribution.

      Introduction

      In this tutorial you will learn how to configure Suricata’s built-in Intrusion Prevention System (IPS) mode on Rocky Linux 8. By default Suricata is configured to run as an Intrusion Detection System (IDS), which only generates alerts and logs suspicious traffic. When you enable IPS mode, Suricata can actively drop suspicious network traffic in addition to generating alerts for further analysis.

      Before enabling IPS mode, it is important to check which signatures you have enabled, and their default actions. An incorrectly configured signature, or a signature that is overly broad may result in dropping legitimate traffic to your network, or even block you from accessing your servers over SSH and other management protocols.

      In the first part of this tutorial you will check the signatures that you have installed and enabled. You will also learn how to include your own signatures. Once you know which signatures you would like to use in IPS mode, you’ll convert their default action to drop or reject traffic. With your signatures in place, you’ll learn how to send network traffic through Suricata using the netfilter NFQUEUE iptables target, and then generate some invalid network traffic to ensure that Suricata drops it as expected.

      Prerequisites

      If you have been following this tutorial series then you should already have Suricata running on a Rocky Linux 8 server.

      • If you still need to install Suricata then you can follow How To Install Suricata on Rocky Linux 8

      • You should also have the ET Open Ruleset downloaded using the suricata-update command, and included in your Suricata signatures.

      • The jq command line JSON processing tool. If you do not have it installed from a previous tutorial, you can do so using the dnf command:

      You may also have custom signatures that you would like to use from the previous Understanding Suricata Signatures tutorial.

      Step 1 — Including Custom Signatures

      The previous tutorials in this series explored how to install and configure Suricata, as well as how to understand signatures. If you would like to create and include your own rules then you need to edit Suricata’s /etc/suricata/suricata.yaml file to include a custom path to your signatures.

      First, let’s find your server’s public IPs so that you can use them in your custom signatures. To find your IPs you can use the ip command:

      You should receive output like the following:

      Output

      lo UNKNOWN 127.0.0.1/8 ::1/128 eth0 UP 203.0.113.0.5/20 10.20.0.5/16 2001:DB8::1/32 fe80::94ad:d4ff:fef9:cee0/64 eth1 UP 10.137.0.2/16 fe80::44a2:ebff:fe91:5187/64

      Your public IP address(es) will be similar to the highlighted 203.0.113.0.5 and 2001:DB8::1/32 IPs in the output.

      Now let’s create the following custom signature to scan for SSH traffic to non-SSH ports and include it in a file called /var/lib/suricata/rules/local.rules. Open the file with nano or your preferred editor:

      • sudo vi /var/lib/suricata/rules/local.rules

      Copy and paste the following signature:

      Invalid SSH Traffic Signature

      alert ssh any any -> 203.0.113.0.5 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000000;)
      alert ssh any any -> 2001:DB8::1/32 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000001;)
      

      Substitute your server’s public IP address in place of the 203.0.113.5 and 2001:DB8::1/32 addresses in the rule. If you are not using IPv6 then you can skip adding that signature in this and the following rules.

      You can continue adding custom signatures to this local.rules file depending on your network and applications. For example, if you wanted to alert about HTTP traffic to non-standard ports, you could use the following signatures:

      HTTP traffic on non-standard port signature

      alert http any any -> 203.0.113.0.5 !80 (msg:"HTTP REQUEST on non-HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000002;)
      alert http any any -> 2001:DB8::1/32 !80 (msg:"HTTP REQUEST on non-HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000003;)
      

      To add a signature that checks for TLS traffic to ports other than the default 443 for web servers, add the following:

      TLS traffic on non-standard port signature

      alert tls any any -> 203.0.113.0.5 !443 (msg:"TLS TRAFFIC on non-TLS HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000004;)
      alert tls any any -> 2001:DB8::1/32 !443 (msg:"TLS TRAFFIC on non-TLS HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000005;)
      

      When you are done adding signatures, save and close the file. If you are using vi, press ESC and then :x then ENTER to save and exit.

      Now that you have some custom signatures defined, edit Suricata’s /etc/suricata/suricata.yaml configuration file using nano or your preferred editor to include them:

      • sudo vi /etc/suricata/suricata.yaml

      Find the rule-files: portion of the configuration. If you are using vi enter 1879gg to go to the line. The exact location in your file may be different, but you should be in the correct general region of the file.

      Edit the section and add the following highlighted - local.rules line:

      /etc/suricata/suricata.yaml

      . . .
      rule-files:
        - suricata.rules
        - local.rules
      . . .
      

      Save and exit the file. Be sure to validate Suricata’s configuration after adding your rules. To do so run the following command:

      • sudo suricata -T -c /etc/suricata/suricata.yaml -v

      The test can take some time depending on how many rules you have loaded in the default suricata.rules file. If you find the test takes too long, you can comment out the - suricata.rules line in the configuration by adding a # to the beginning of the line and then run your configuration test again. Be sure to remove the # comment if you plan to use the suricata.rules signature in your final running configuration.

      Once you are satisfied with the signatures that you have created or included using the suricata-update tool, you can proceed to the next step, where you’ll switch the default action for your signatures from alert or log to actively dropping traffic.

      Step 2 — Configuring Signature Actions

      Now that you have your custom signatures tested and working with Suricata, you can change the action to drop or reject. When Suricata is operating in IPS mode, these actions will actively block invalid traffic for any matching signature.

      These two actions are described in the previous tutorial in this series, Understanding Suricata Signatures. The choice of which action to use is up to you. A drop action will immediately discard a packet and any subsequent packets that belong to the network flow. A reject action will send both the client and server a reset packet if the traffic is TCP-based, and an ICMP error packet for any other protocol.

      Let’s use the custom rules from the previous section and convert them to use the drop action, since the traffic that they match is likely to be a network scan, or some other invalid connection.

      Open your /var/lib/suricata/rules/local.rules file using nano or your preferred editor and change the alert action at the beginning of each line in the file to drop:

      • sudo vi /var/lib/suricata/rules/local.rules

      /var/lib/suricata/rules/local.rules

      drop ssh any any -> 203.0.113.0.5 !22 (msg:"SSH TRAFFIC on non-SSH port"; classtype: misc-attack; target: dest_ip; sid:1000000;)
      drop ssh any any -> 2001:DB8::1/32 !22 (msg:"SSH TRAFFIC on non-SSH port"; classtype: misc-attack; target: dest_ip; sid:1000001;)
      . . .
      

      Repeat the step above for any signatures in /var/lib/suricata/rules/suricata.rules that you would like to convert to drop or reject mode.

      Note: If you ran suricata-update in the prerequisite tutorial, you may have more than 30,000 signatures included in your suricata.rules file.

      If you convert every signature to drop or reject you risk blocking legitimate access to your network or servers. Instead, leave the rules in suricata.rules for the time being, and add your custom signatures to local.rules. Suricata will continue to generate alerts for suspicious traffic that is described by the signatures in suricata.rules while it is running in IPS mode.

      After you have a few days or weeks of alerts collected, you can analyze them and choose the relevant signatures to convert to drop or reject based on their sid.

      Once you have all the signatures configured with the action that you would like them to take, the next step is to reconfigure and then restart Suricata in IPS mode.

      Step 3 — Enabling nfqueue Mode

      Suricata runs in IDS mode by default, which means it will not actively block network traffic. To switch to IPS mode, you’ll need to edit Suricata’s /etc/sysconfig/suricata configuration file.

      Open the file in nano or your preferred editor:

      • sudo vi /etc/sysconfig/suricata

      Find the OPTIONS="-i eth0 --user suricata" line and comment it out by adding a # to the beginning of the line. Then add a new line OPTIONS="-q 0 -vvv --user suricata" line that tells Suricata to run in IPS mode.

      Your file should have the following highlighted lines in it when you are done editing:

      /etc/sysconfig/suricata

      . . .
      # OPTIONS="-i eth0 --user suricata"
      OPTIONS="-q 0 -vvv --user suricata"
      . . .
      

      Save and close the file. Now you can restart Suricata using systemctl:

      • sudo systemctl restart suricata.service

      Check Suricata’s status using systemctl:

      • sudo systemctl status suricata.service

      You should receive output like the following:

      Output

      ● suricata.service - Suricata Intrusion Detection Service Loaded: loaded (/usr/lib/systemd/system/suricata.service; disabled; vendor preset: disabled) Active: active (running) since Tue 2021-12-14 16:52:07 UTC; 6s ago Docs: man:suricata(1) Process: 44256 ExecStartPre=/bin/rm -f /var/run/suricata.pid (code=exited, status=0/SUCCESS) Main PID: 44258 (Suricata-Main) Tasks: 10 (limit: 11188) Memory: 52.8M CGroup: /system.slice/suricata.service └─44258 /sbin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid -q 0 -vvv --user suricata . . . Dec 14 16:52:07 suricata suricata[44258]: 14/12/2021 -- 16:52:07 - <Notice> - all 4 packet processing threads, 4 management threads initialized, engine started.

      Note the highlighted active (running) line that indicates Suricata restarted successfully.

      With this change you are now ready to send traffic to Suricata using Firewalld in the next step.

      Step 4 — Configuring Firewalld To Send Traffic to Suricata

      Now that you have configured Suricata to process traffic in IPS mode, the next step is to direct incoming packets to Suricata. If you followed the prerequisite tutorials for this series and are using a Rocky Linux 8 system, you should have Firewalld installed and enabled.

      To add the required rules for Suricata to Firewalld, you will need to run the following commands:

      • sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass
      • sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass

      These two rules ensure that SSH traffic on IPv4 interfaces will bypass Suricata so that you can connect to your server using SSH, even when Suricata is not running. Without these rules, an incorrect or overly broad signature could block your SSH access. Additionally, if Suricata is stopped, all traffic will be sent to the NFQUEUE target and then dropped since Suricata is not running.

      Add the same rules for IPv6 using the following commands:

      • sudo firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass
      • sudo firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass

      Next, add FORWARD rules to ensure that if your server is acting as a gateway for other systems, all that traffic will also go to Suricata for processing.

      • sudo firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -j NFQUEUE
      • sudo firewall-cmd --permanent --direct --add-rule ipv6 filter FORWARD 0 -j NFQUEUE

      The final two INPUT and OUTPUT rules send all remaining traffic that is not SSH traffic to Suricata for processing.

      • sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -j NFQUEUE
      • sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -j NFQUEUE

      Repeat the commands for IPv6 traffic:

      • sudo firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 1 -j NFQUEUE
      • sudo firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 1 -j NFQUEUE

      Now reload Firewalld to make the rules persistent:

      • sudo firewall-cmd --reload

      Note: If you are using another firewall like iptables you will need to modify these rules to match the format your firewall expects.

      At this point in the tutorial you have Suricata configured to run in IPS mode, and your network traffic is being sent to Suricata by default. You will be able to restart your server at any time and your Suricata and firewall rules will be persistent.

      The last step in this tutorial is to verify Suricata is dropping traffic correctly.

      Step 5 — Testing Invalid Traffic

      Now that you have Suricata and your firewall configured to process network traffic, you can test whether Suricata will drop packets that match your custom and other included signatures.

      Recall signature sid:2100498 from the previous tutorial, which is modified in this example to drop matching packets:

      sid:2100498

      drop ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)
      

      Find and edit the rule in your /var/lib/suricata/rules/suricata.rules file to use the drop action if you have the signature included there. Otherwise, add the rule to your /var/lib/suricata/rules/local.rules file.

      Send Suricata the SIGUSR2 signal to get it to reload its signatures:

      • sudo kill -usr2 $(pidof suricata)

      Now test the rule using curl:

      • curl --max-time 5 http://testmynids.org/uid/index.html

      You should receive an error stating that the request timed out, which indicates Suricata blocked the HTTP response:

      Output

      curl: (28) Operation timed out after 5000 milliseconds with 0 out of 39 bytes received

      You can confirm that Suricata dropped the HTTP response using jq to examine the eve.log file:

      • sudo jq 'select(.alert .signature_id==2100498)' /var/log/suricata/eve.json

      You should receive output like the following:

      Output

      { . . . "community_id": "1:SbOgFh2T3DZvwsoyMH4xfxOoVas=", "alert": { "action": "blocked", "gid": 1, "signature_id": 2100498, "rev": 7, "signature": "GPL ATTACK_RESPONSE id check returned root", "category": "Potentially Bad Traffic", "severity": 2, "metadata": { "created_at": [ "2010_09_23" ], "updated_at": [ "2010_09_23" ] } }, "http": { "hostname": "testmynids.org", "url": "/uid/index.html", "http_user_agent": "curl/7.61.1", "http_content_type": "text/html", "http_method": "GET", "protocol": "HTTP/1.1", "status": 200, "length": 39 }, . . .

      The highlighted "action": "blocked" line confirms that the signature matched, and Suricata dropped or rejected the test HTTP request.

      Conclusion

      In this tutorial you configured Suricata to block suspicious network traffic using its built-in IPS mode on Rocky Linux 8. You also added custom signatures to examine and block SSH, HTTP, and TLS traffic on non-standard ports. To tie everything together, you also added firewall rules to direct traffic through Suricata for processing.

      Now that you have Suricata installed and configured in IPS mode, and can write your own signatures that either alert on or drop suspicious traffic, you can continue monitoring your servers and networks, and refining your signatures.

      Once you are satisfied with your Suricata signatures and configuration, you can continue with the last tutorial in this series, which will guide you through sending logs from Suricata to a Security and Information Event Management (SIEM) system built using the Elastic Stack.



      Source link