brent

Are you hosting service on a dynamic IP and receiving a new IP when bouncing your router or firewall? prerequisites: Cloud Flare API token Portainer *Optional* Docker Compose from here. 1. In portainer go to stacks. and create a new stack. 2. Copy the below docker-compose into the editor adding your API key. version: '2' services: cloudflare-ddns: image: oznu/cloudflare-ddns:latest restart: always environment: - API_KEY=xxxxxxx - ZONE=example.com - SUBDOMAIN=subdomain #remove - PROXIED=yes 3. I remove the "SUBDOMAIN" environment as I use CNAME for all my subdomains. Meaning if I update the IP of my A record then my subdomains that use CNAME records are updated. 4. Before clicking on deployment let's set up a test scenario. Go to Cloud Flare and change the last octet of the IP. 5. Back in Portainer click deploy. 6. Go to container logs and verify the container is running. You should see the IP change. 7. In cloud flare verify the DNS has changed to reflect your current IP. 8. In the environment you will see a cron job to run every 5 minutes. This can be changed to your needs.

Update your Instance It is critically important to keep your self-hosted Bitwarden instance up to date. Updates may include fixes that are important for the security of your Bitwarden instance, including patches to any vulnerabilities. Data stored in your Bitwarden vault, including passwords, should be considered critical data and therefore protected with up-to-date software. Additionally, newer versions of client applications may not support older versions of your self-hosted instance. If you're running a standard installation, update your Bitwarden instance using the same Bash (Linux or macOS) or Powershell (Windows) script (bitwarden.sh) used to install Bitwarden. Run the following sequence of commands: Bash ./bitwarden.sh updateself ./bitwarden.sh update

From portainer open stacks and add the below. Modify IP's of adguard servers. If adguard won't spin up you need to disable the host systemd-resolved sudo systemctl disable systemd-resolved.service sudo systemctl stop systemd-resolved --- version: "2.1" services: adguardhome-sync: image: quay.io/bakito/adguardhome-sync container_name: adguardhome-sync command: run environment: - ORIGIN_URL=http://192.168.1.26:85 #change as necessary - ORIGIN_USERNAME=dbtech #change as necessary - ORIGIN_PASSWORD=password #change as necessary - REPLICA_URL=http://192.168.1.27 #change as necessary - REPLICA_USERNAME=dbtech #change as necessary - REPLICA_PASSWORD=password #change as necessary - REPLICA1_URL=http://192.168.1.4 #change as necessary - REPLICA1_USERNAME=username #change as necessary - REPLICA1_PASSWORD=password #change as necessary - CRON=*/1 * * * * # run every 1 minute - RUNONSTART=true ports: - 8080:8080 #change as necessary restart: unless-stopped ################ # # Original Source: # https://github.com/bakito/adguardhome-sync # ################

Iptables is a firewall, installed by default on many Linux distributions. This walk through is simple for setting up the basic server. In this tutorial we will go over how to set up iptables for the first time. Note: When working with firewalls, do not block SSH communication; lock yourself out of your own server (port 22, by default). Prerequisites: Install iptables persistent to save iptables sudo apt install iptables-persistent make a directory /etc/iptables sudo mkdir /etc/iptables useful commands: sudo iptables -L sudo iptables -L -v sudo iptables -S Introducing new rules: To begin using iptables, add the rules for authorized inbound traffic for the services you need. Iptables can keep track of the connection’s state. Therefore, use the command below to enable established connections to continue. sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT Allow traffic to a specific port to permit SSH connections by doing the following: sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT Change the input policy to drop once you’ve added all the required authorized rules. Note: Changing the default rule to drop will allow only specially allowed connections. Before modifying the default rule, ensure you’ve enabled at least SSH, as stated above. sudo iptables -P INPUT DROP Rules for saving and restoring If you restart your server, all these iptables configurations will be lost. Save the rules to a file to avoid this. sudo iptables-save > /etc/iptables/rules.v4 You may then just read the stored file to restore the saved rules. # Overwrite the existing rules sudo iptables-restore < /etc/iptables/rules.v4 # Append new rules while retaining the existing ones sudo iptables-restore -n < /etc/iptables/rules.v4 You may automate the restore procedure upon reboot by installing an extra iptables package that handles the loading of stored rules. Use the following command to do this. sudo apt-get install iptables-persistent After installation, the first setup will prompt you to preserve the current IPv4 and IPv6 rules; choose Yes, and press Enter for both. Saving Updates If you ever think of updating your firewall and want the changes to be durable, you must save your iptables rules. This command will help save your firewall rules: sudo netfilter-persistent save Example of IPTABLES: *filter :INPUT ACCEPT [63:3208] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [36:2160] -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT (Accepting all established connections) -A INPUT -m conntrack --ctstate INVALID -j DROP (Drop statement if service or port doesn't match) -A INPUT -s 83.97.73.245/32 -j DROP (Example of blocking bad IP) -A INPUT -s 83.97.73.245/32 -j REJECT --reject-with icmp-port-unreachable (Rejecting a bad IP) -A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,> (Allow SSH from subnet) -A INPUT -p udp -m udp --dport 137 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT (Allow port) -A INPUT -p udp -m udp --dport 138 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 139 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT COMMIT To accept all traffic on your loopback interface, run these commands: sudo iptables -A INPUT -i lo -j ACCEPT sudo iptables -A OUTPUT -o lo -j ACCEPT Allowing Established and Related Incoming Connections As network traffic generally needs to be two-way – incoming and outgoing – to work properly, it is typical to create a firewall rule that allows established and related incoming traffic, so that the server will allow return traffic for outgoing connections initiated by the server itself. This command will allow that: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT Allowing Established Outgoing Connections You may want to allow outgoing traffic of all established connections, which are typically the response to legitimate incoming connections. This command will allow that: sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT Allowing Internal Network to access External Assuming eth0 is your external network, and eth1 is your internal network, this will allow your internal to access the external: sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT Dropping Invalid Packets Some network traffic packets get marked as invalid. Sometimes it can be useful to log this type of packet but often it is fine to drop them. Do so with this command: sudo iptables -A INPUT -m conntrack --ctstate INVALID -j DROP Blocking an IP Address To block network connections that originate from a specific IP address, 203.0.113.51 for example, run this command: sudo iptables -A INPUT -s 203.0.113.51 -j DROP In this example, -s 203.0.113.51 specifies a source IP address of “203.0.113.51”. The source IP address can be specified in any firewall rule, including an allow rule. If you want to reject the connection instead, which will respond to the connection request with a “connection refused” error, replace “DROP” with “REJECT” like this: sudo iptables -A INPUT -s 203.0.113.51 -j REJECT Blocking Connections to a Network Interface To block connections from a specific IP address, e.g. 203.0.113.51, to a specific network interface, e.g. eth0, use this command: iptables -A INPUT -i eth0 -s 203.0.113.51 -j DROP This is the same as the previous example, with the addition of -i eth0. The network interface can be specified in any firewall rule, and is a great way to limit the rule to a particular network. Service: SSH If you’re using a server without a local console, you will probably want to allow incoming SSH connections (port 22) so you can connect to and manage your server. This section covers how to configure your firewall with various SSH-related rules. Allowing All Incoming SSH To allow all incoming SSH connections run these commands: sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established SSH connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Allowing Incoming SSH from Specific IP address or subnet To allow incoming SSH connections from a specific IP address or subnet, specify the source. For example, if you want to allow the entire 203.0.113.0/24 subnet, run these commands: sudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established SSH connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Here's a sample of setting up a rule which only allows SSH from a single IP: Add a new "allow SSH from 1.2.3.4" rule: iptables -A INPUT -p tcp -s 1.2.3.4 --dport 22 -j ACCEPT Block SSH from all other IPs: iptables -A INPUT -p tcp -s 0.0.0.0/0 --dport 22 -j DROP Now your INPUT chain will look like: Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- 1.2.3.4 0.0.0.0/0 tcp dpt:22 DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 Later, if you need to whitelist a second IP you can use the -I parameter to place it before the blacklist rule. iptables -I INPUT 2 -p tcp -s 4.3.2.1 --dport 22 -j ACCEPT Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- 1.2.3.4 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 4.3.2.1 0.0.0.0/0 tcp dpt:22 DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 Notice that using -I INPUT 2 added the new rule as rule number 2 and bumped the DROP rule to number 3. Allowing Outgoing SSH If your firewall OUTPUT policy is not set to ACCEPT, and you want to allow outgoing SSH connections—your server initiating an SSH connection to another server—you can run these commands: sudo iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A INPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT Allowing Incoming Rsync from Specific IP Address or Subnet Rsync, which runs on port 873, can be used to transfer files from one computer to another. To allow incoming rsync connections from a specific IP address or subnet, specify the source IP address and the destination port. For example, if you want to allow the entire 203.0.113.0/24 subnet to be able to rsync to your server, run these commands: sudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 873 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 873 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established rsync connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Service: Web Server Web servers, such as Apache and Nginx, typically listen for requests on port 80 and 443 for HTTP and HTTPS connections, respectively. If your default policy for incoming traffic is set to drop or deny, you will want to create rules that will allow your server to respond to those requests. Allowing All Incoming HTTP To allow all incoming HTTP (port 80) connections run these commands: sudo iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established HTTP connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Allowing All Incoming HTTPS To allow all incoming HTTPS (port 443) connections run these commands: sudo iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established HTTP connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Allowing All Incoming HTTP and HTTPS If you want to allow both HTTP and HTTPS traffic, you can use the multiport module to create a rule that allows both ports. To allow all incoming HTTP and HTTPS (port 443) connections run these commands: sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established HTTP and HTTPS connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Service: MySQL MySQL listens for client connections on port 3306. If your MySQL database server is being used by a client on a remote server, you need to be sure to allow that traffic. Allowing MySQL from Specific IP Address or Subnet To allow incoming MySQL connections from a specific IP address or subnet, specify the source. For example, if you want to allow the entire 203.0.113.0/24 subnet, run these commands: sudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 3306 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established MySQL connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Allowing MySQL to Specific Network Interface To allow MySQL connections to a specific network interface—say you have a private network interface eth1, for example—use these commands: sudo iptables -A INPUT -i eth1 -p tcp --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -o eth1 -p tcp --sport 3306 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established MySQL connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Service: PostgreSQL PostgreSQL listens for client connections on port 5432. If your PostgreSQL database server is being used by a client on a remote server, you need to be sure to allow that traffic. PostgreSQL from Specific IP Address or Subnet To allow incoming PostgreSQL connections from a specific IP address or subnet, specify the source. For example, if you want to allow the entire 203.0.113.0/24 subnet, run these commands: sudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 5432 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established PostgreSQL connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Allowing PostgreSQL to Specific Network Interface To allow PostgreSQL connections to a specific network interface—say you have a private network interface eth1, for example—use these commands: sudo iptables -A INPUT -i eth1 -p tcp --dport 5432 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -o eth1 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established PostgreSQL connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Service: Mail Mail servers, such as Sendmail and Postfix, listen on a variety of ports depending on the protocols being used for mail delivery. If you are running a mail server, determine which protocols you are using and allow the appropriate types of traffic. We will also show you how to create a rule to block outgoing SMTP mail. Blocking Outgoing SMTP Mail If your server shouldn’t be sending outgoing mail, you may want to block that kind of traffic. To block outgoing SMTP mail, which uses port 25, run this command: sudo iptables -A OUTPUT -p tcp --dport 25 -j REJECT This configures iptables to reject all outgoing traffic on port 25. If you need to reject a different service by its port number, instead of port 25, substitute that port number for the 25 above. Allowing All Incoming SMTP To allow your server to respond to SMTP connections on port 25, run these commands: sudo iptables -A INPUT -p tcp --dport 25 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 25 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established SMTP connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Allowing All Incoming IMAP To allow your server to respond to IMAP connections, port 143, run these commands: sudo iptables -A INPUT -p tcp --dport 143 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 143 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established IMAP connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Allowing All Incoming IMAPS To allow your server to respond to IMAPS connections, port 993, run these commands: sudo iptables -A INPUT -p tcp --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 993 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established IMAPS connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Allowing All Incoming POP3 To allow your server to respond to POP3 connections, port 110, run these commands: sudo iptables -A INPUT -p tcp --dport 110 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 110 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established POP3 connections, is only necessary if the OUTPUT policy is not set to ACCEPT. Allowing All Incoming POP3S To allow your server to respond to POP3S connections, port 995, run these commands: sudo iptables -A INPUT -p tcp --dport 995 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 995 -m conntrack --ctstate ESTABLISHED -j ACCEPT The second command, which allows the outgoing traffic of established POP3S connections, is only necessary if the OUTPUT policy is not set to ACCEPT.

Do you want to access your fleet of Linux servers without a password? First and foremost using password authentication via SSH is a bad practice even more so if your Linux server is internet-facing. Using a public key to access your Linux servers is best practice and prevents brute force attacks. Permissions: from your Linux workstation, if you are getting a permission error trying to ssh to a server check the following permissions. ~/.ssh needs to be owned by the user account. Make sure authorized_keys has the correct permissions. ls -l .ssh/authorized_keys make sure it has a permission of 600. sudo chmod 600 ~/.ssh/authorized_keys make sure the ~/.ssh directory is owned by the user. sudo chown brent:brent ~/.ssh ~/.ssh/id_rsa needs to have a permission of 600. sudo chmod 600 ~/.ssh/id_rsa The id_rsa.pub public key needs to have a permission of 644. sudo chmod 644 ~/.ssh/id_rsa.pub Prerequisites: Windows workstation putty for Windows (Download putty for Windows. You can find the latest Windows installer here. Linux workstation Linux server Generating SSH keys in Windows Create a folder on your local computer called SSH keys. This folder can be anywhere desktop, documents, etc.. Open PuTTygen from your start menu. Change the number of bits in the generated key to 4096 and click Generated. Move the mouse in the open area until complete. Copy the public key to Notepad and save it in the SSH keys folder. Now save the private key to the SSH key folder. You can close PuTTYgen once the files have been saved. Now you should have two files in the folder ssh keys. Copying the Public key to the Linux server. Open Putty and login to your Linux server. We need to check to see if a ssh folder already exists cd ~/.ssh if you don't have one sudo mkdir ~/.ssh Create a file called authorized_keys sudo mkdir ~/.ssh/authorized_keys Open your public key in Notepad and copy the key. Using your favorite text editor paste the key into the authorized_keys file and save. If you already have an authorized_keys file, add the key on another line. sudo nano ~/.ssh/authorized_keys Log out of your server. Open PuTTy up to make a couple of changes. make sure to add user@ in front of your hostname or IP. On the left side navigate to SSH > Auth > Credentials and click Browse to point to the Private key. Once the Key has been added Click on Session and save the session. You will need to repeat this for every server. Create SSH keys on a Linux workstation. Let's make sure we don't have an SSH key pair. ls -l ~/.ssh If the directory exists you may want to back it up as the following command will overwrite the folder. ssh-keygen -b 4096 Save the path in the default location. Enter Passphrase. This isn't required but is suggested as another layer of protection. If you choose to use a passphrase know that you will have to use the passphrase every time you log in. Let's verify that the keys have been created. ls -l ~/.ssh You should see two files id_rsa, the private key, and id_rsa.pub, the public key. Now let's copy the public key over to the server. ssh-copy-id [email protected] Type the server user password. Like below once you log in you should see the Number of key(s) added:1 Let's verify the public key is working. ssh [email protected] If the key is working you won't be prompted for a password.

Install Qemu guest agent for Debian/Ubuntu In this article, we will help you to install the Qemu guest agent on your vm server. This agent is a helper daemon that exchanges information between the quest and the host and executes commands in the guest for snapshot or backup. The guest agent is used for mainly two things one for properly shut down the guest and the second is to freeze the guest file system when making a backup. Step 1: Log in using SSH You must be logged in via SSH with the root account or an account with sudo privileges. Step 2: Install qemu guest agent apt update && apt -y install qemu-guest-agent Step 3: Enable and Start Qemu Agent systemctl enable qemu-guest-agent systemctl start qemu-guest-agent Step 4: Verify Verify that the Qemu quest agent is running systemctl status qemu-guest-agent Conclusion If you are having a problem with the service starting power off the VM completely then start the VM. A restart of the VM won't work in some cases. Congratulations, you have installed the Qemu guest agent on your Debian/Ubuntu based system.