How to add bulk IP addresses to DigitalOcean firewall ?

digitalocean

Trying to add bulk IP’s in DigitalOcean firewall? You are in the right place.

DigitalOcean cloud control panel UI doesn’t allow you to paste in multiple IP Addresses at once. That’s a good idea for a UI improvement.

In the meantime you can definitely do it via the API

Use the following shell script

It uses json for POST data, so update TOKEN, FIREWALL NAME, IP addresses, ports… and then run the script

#!/bin/bash

# Author: Akhil Jalagam
# update TOKEN, FIREWALL NAME, IP addresses and then run the script

TOKEN=dfjvbidvbasb4l5tu45hvu46vgl45h6vl
FIREWALL_NAME=internalaccess
curl -X POST -H "Content-Type: application/json" \
-H "Authorization: Bearer $token" \
-d \
'{
  "name": "'$FIREWALL_NAME'",
  "inbound_rules": [
    {
      "protocol": "tcp",
      "ports": "all",
      "sources": {
        "addresses": [
          "196.112.47.128/29",
          "196.112.43.128/29"
        ]
      }
    },
    {
      "protocol": "udp",
      "ports": "all",
      "sources": {
        "addresses": [
          "196.112.47.128/29",
          "196.112.43.128/29"

        ]
      }
    },
    {
      "protocol": "icmp",
      "sources": {
        "addresses": [
          "0.0.0.0/0",
          "::/0"
        ]
      }
    }
  ],
  "outbound_rules": [
    {
      "protocol": "icmp",
      "destinations": {
        "addresses": [
          "0.0.0.0/0",
          "::/0"
        ]
      }
    },
    {
      "protocol": "tcp",
      "ports": "all",
      "destinations": {
        "addresses": [
          "0.0.0.0/0",
          "::/0"
        ]
      }
    },
    {
      "protocol": "udp",
      "ports": "all",
      "destinations": {
        "addresses": [
          "0.0.0.0/0",
          "::/0"
        ]
      }
    }
  ]
}' "https://api.digitalocean.com/v2/firewalls/"

Hope it will save your time ! 😊

Still Confused With Mail Ports?

This article explains the most commonly used Email protocols on the internet – POP3, IMAP, and SMTP

  • SMTP 25, 2525
  • SMTP-SSL/TLS 587,465
  • IMAP 143
  • IMAP-SSL/TLS 993
  • POP3 110
  • POP3-SSL/TLS 995

587 vs. 465
These port assignments are specified by the Internet Assigned Numbers Authority (IANA):

Port 587: [SMTP] Message submission (SMTP-MSA), a service that accepts submission of email from email clients (MUAs). Described in RFC 6409.

Port 465: URL Rendezvous Directory for SSM (entirely unrelated to email)
Historically, port 465 was initially planned for the SMTPS encryption and authentication “wrapper” over SMTP, but it was quickly deprecated (within months, and over 15 years ago) in favour of STARTTLS over SMTP (RFC 3207). Despite that fact, there are probably many servers that support the deprecated protocol wrapper, primarily to support older clients that implemented SMTPS. Unless you need to support such older clients, SMTPS and its use on port 465 should remain nothing more than a historical footnote.

Custom fail2ban filters using regexp

fail2Ban is a very handy tool to prevent a lot of unwanted traffic from consuming bandwidth on your servers. It’s a very small and relatively simple IDS Type Tool that comes with some predefined Filters to automatically lockout potentially dangerous or bandwidth-consuming type attacks.

Creating a Custom Filter

/etc/fail2ban/filter.d/custom.conf
[Definition]
 
badagents = 360Spider|ZmEu|Auto Spider 1.0|zgrab/[0-9]*\.[0-9a-zA-Z]*|Wget\(.*\)|MauiBot.*
 
failregex = ^.+?:\d+ <HOST> -.*"(GET|POST|HEAD).*HTTP.*(?:%(badagents)s)"$
 
ignoreregex =

Testing

fail2ban-regex /path-to-samples/sample.log /etc/fail2ban/filter.d/custom.conf

Jail example

[apache-custom]
enabled  = true
logpath  = /var/log/apache*/access.log
		   /var/log/apache*/ssl_access.log
action   = iptables-ipset-proto4[name=Custom, port=1010, protocol=tcp]
findtime = 86400
bantime  = -1
maxretry = 1

Cron job for Automatic Feed updates in Openvas

To get updated content from the feeds you need to run the following scripts (in this order) on a daily base

# crontab -e

0 1 * * * /usr/sbin/greenbone-nvt-sync > /dev/null
0 2 * * * /usr/sbin/greenbone-scapdata-sync > /dev/null
0 3 * * * /usr/sbin/greenbone-certdata-sync > /dev/null

If there is any issue during the sync the scripts should give you additional info.

How to RESET/FLUSH/DELETE all iptables in Linux

Take backup

iptables-save > ~/iptables-`date +%Y%m%d_%H%M%S`.bak

Flush now

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 FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Again to restore from backup

iptables-restore < bak.file

How to set up an SPF record for your domain?

What are the SPF records?

A Sender Policy Framework (SPFrecord is a type of Domain Name Service (DNS) TXT record that identifies which mail servers are permitted to send an email on behalf of your domain. The purpose of an SPF record is to detect and prevent spammers from sending messages with forged From addresses on your domain.

Overview

Sender Policy Framework (SPF) is a method of fighting spam. As more time passes, this protocol will be used as one of the standard methods of fighting spam on the Internet. An SPF record is a TXT record that is part of a domain’s DNS zone file. The TXT record specifies a list of authorized hostnames/IP addresses that mail can originate from for a given domain name. Once this entry is placed within the DNS zone, no further configuration is necessary to take advantage of servers that incorporate SPF checking into their anti-spam systems. This SPF record is added the same way as a regular A, MX, or CNAME record.

Collect all IP addresses that are used to send email

The Sender Policy Framework (SPF) gives the ability to authenticate your email and to specify which IP addresses are allowed to send an email on behalf of the specific domain.

In order to successfully implement SPF, you first need to identify which mail servers are used to send an email for your domain. These mail servers can be any sending organization, you should think of your Email Service Provider, Office mail server and any other third-party mail servers that may be used to send an email for you.

Create your SPF record

v=spf1 ip4:34.243.61.237 ~all

Example

named (bind DNS server) config

@                       IN       TXT   "v=spf1 a mx ~all"

Testing

Test online

https://www.kitterman.com/spf/validate.html

Testing IPSEC VPN Systems with ike-scan

ike-scan is a command-line tool for discovering, fingerprinting and testing IPsec VPN systems. It constructs and sends IKE Phase-1 packets to the specified hosts, and displays any responses that are received.

ike-scan does two things:

  1. Discovery: Determine which hosts are running IKE. This is done by displaying those hosts which respond to the IKE requests sent by ike-scan.
  2. Fingerprinting: Determine which IKE implementation the hosts are using. There are several ways to do this: (a) Backoff fingerprinting – recording the times of the IKE response packets from the target hosts and comparing the observed retransmission backoff pattern against known patterns; (b) vendor id fingerprinting – matching the vendor-specific vendor IDs against known vendor ID patterns; and (c) proprietary notify message codes.

Basic scan

# ike-scan x.x.x.x
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
65.111.172.164 Main Mode Handshake returned HDR=(CKY-R=e6e1202cb8c44f2d) SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration=28800) VID=4a131c81070358455c5728f20e95452f (RFC 3947 NAT-T) VID=7d9419a65310ca6f2c179d9215529d56 (draft-ietf-ipsec-nat-t-ike-03) VID=90cb80913ebb696e086381b5ec427b1f (draft-ietf-ipsec-nat-t-ike-02\n) VID=cd60464335df21f87cfdb2fc68b6a448 (draft-ietf-ipsec-nat-t-ike-02) VID=4485152d18b6bbcd0be8a8469579ddcc (draft-ietf-ipsec-nat-t-ike-00) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Ending ike-scan 1.9: 1 hosts scanned in 0.512 seconds (1.95 hosts/sec).  1 returned handshake; 0 returned notify

Aggressive mode with user-id

# ike-scan --aggressive --multiline --id akhil x.x.x.x
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
65.111.172.164 Aggressive Mode Handshake returned
 HDR=(CKY-R=4fb76b5165da9e05)
 SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration=28800)
 KeyExchange(128 bytes)
 Nonce(16 bytes)
 ID(Type=ID_IPV4_ADDR, Value=65.111.172.164)
 Hash(20 bytes)
 VID=4a131c81070358455c5728f20e95452f (RFC 3947 NAT-T)
 VID=7d9419a65310ca6f2c179d9215529d56 (draft-ietf-ipsec-nat-t-ike-03)
 VID=90cb80913ebb696e086381b5ec427b1f (draft-ietf-ipsec-nat-t-ike-02\n)
 VID=cd60464335df21f87cfdb2fc68b6a448 (draft-ietf-ipsec-nat-t-ike-02)
 VID=4485152d18b6bbcd0be8a8469579ddcc (draft-ietf-ipsec-nat-t-ike-00)
 VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Ending ike-scan 1.9: 1 hosts scanned in 0.512 seconds (1.95 hosts/sec).  1 returned handshake; 0 returned notify

iptables explained

iptables

Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user-defined chains.

Each chain is a list of rules which can match a set of packets. Each rule specifies what to do with a packet that matches. This is called a ‘target’, which may be a jump to a user-defined chain in the same table.

Tables

  • The filter table: This is the default and perhaps the most widely used table. It is used to make decisions about whether a packet should be allowed to reach its destination.
  • The mangle table: This table allows you to alter packet headers in various ways, such as changing TTL values.
  • The nat table: This table allows you to route packets to different hosts on NAT (Network Address Translation) networks by changing the source and destination addresses of packets. It is often used to allow access to services that can’t be accessed directly because they’re on a NAT network.
  • The raw table: iptables is a stateful firewall, which means that packets are inspected with respect to their “state”. (For example, a packet could be part of a new connection, or it could be part of an existing connection.) The raw table allows you to work with packets before the kernel starts tracking its state. In addition, you can also exempt certain packets from the state-tracking machinery.

Chains

  • The PREROUTING chain: Rules in this chain apply to packets as they just arrive on the network interface. This chain is present in the natmangle and raw tables.
  • The INPUT chain: Rules in this chain apply to packets just before they’re given to a local process. This chain is present in the mangle and filter tables.
  • The OUTPUT chain: The rules here apply to packets just after they’ve been produced by a process. This chain is present in the rawmangle, nat and filter tables.
  • The FORWARD chain: The rules here apply to any packets that are routed through the current host. This chain is only present in the mangle and filter tables.
  • The POSTROUTING chain: The rules in this chain apply to packets as they just leave the network interface. This chain is present in the nat and mangle tables.

Targets

  • ACCEPT: This causes iptables to accept the packet.
  • DROP: iptables drops the packet. To anyone trying to connect to your system, it would appear like the system didn’t even exist.
  • REJECT: iptables “rejects” the packet. It sends a “connection reset” packet in case of TCP, or a “destination host unreachable” packet in case of UDP or ICMP.

The connection tracking module – conntrack

  • NEW: This state represents the very first packet of a connection.
  • ESTABLISHED: This state is used for packets that are part of an existing connection.
  • RELATED: This state is used for connections that are related to another ESTABLISHEDconnection.
  • INVALID: This state means the packet doesn’t have a proper state. This may be due to several reasons, such as the system running out of memory or due to some types of ICMP traffic.
  • UNTRACKED: Any packets exempted from connection tracking in the raw table with the NOTRACK target end up in this state.
  • DNAT: This is a virtual state used to represent packets whose destination address was changed by rules in the nat table.
  • SNAT: Like DNAT, this state represents packets whose source address was changed.