Archive

Articles taggués ‘iptables’

Simple stateful firewall

30/01/2023 Comments off

Source: archlinux.org

This page explains how to set up a stateful firewall using iptables. It also explains what the rules mean and why they are needed. For simplicity, it is split into two major sections. The first section deals with a firewall for a single machine, the second sets up a NAT gateway in addition to the firewall from the first section.

Warning: The rules are given in the order that they are executed. If you are logged into a remote machine, you may be locked out of the machine while setting up the rules. You should only follow the steps below while you are logged in locally.The example config file can be used to get around this problem.

Prerequisites

Note: Your kernel needs to be compiled with iptables support. All stock Arch Linux kernels have iptables support.

First, install the userland utilities iptables or verify that they are already installed.

This article assumes that there are currently no iptables rules set. To check the current ruleset and verify that there are currently no rules run the following:

# iptables-save
# Generated by iptables-save v1.4.19.1 on Thu Aug  1 19:28:53 2013
*filter
:INPUT ACCEPT [50:3763]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [30:3472]
COMMIT
# Completed on Thu Aug  1 19:28:53 2013

or

# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 156 packets, 12541 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 82 packets, 8672 bytes)
num   pkts bytes target     prot opt in     out     source               destination

If there are rules, you may be able to reset the rules by loading a default rule set:

# iptables-restore < /etc/iptables/empty.rules

Otherwise, see Iptables#Resetting rules.

Lire la suite…

IPTables, la suite: script d’initialisation

29/01/2023 Aucun commentaire

Source: notarobot.fr

On a vu dans l’article précédent comment fonctionnait IPTables et comment pouvait se construire ses commandes. Dans la suite je vais vous proposer un script qui permet d’initialiser IPTables avec ses propres règles au démarrage de la machine.

Ce n’est pas la meilleure façon de faire c’est juste celle que j’utilise. On pourrait rendre ce script plus court, plus interactif j’en suis parfaitement conscient.
D’abord je commence a choisir mes règles par défaut: logiquement je bloque tout le trafic entrant mais est ce que je bloque aussi par défaut tout le trafic sortant ? C’est mon cas mais à vous de voir ce qui est le mieux pour votre situation. Par exemple, et c’est rare, lorsque qu’un attaquant réussit via je ne sais quel moyen a coller un rootkit sur votre serveur cela peut être intéressant de l’empêcher de dialoguer avec l’extérieur.
Ensuite comme vous êtes sûrement connectés en SSH sur votre serveur on va éviter de couper la connexion à l’initialisation du pare feu par exemple donc il va falloir autoriser toutes les connexions déjà établies en considérant qu’elles soient sûres. Puis on enchaîne nos règles en gardant bien à l’esprit l’article précédent pour les agencer dans l’ordre. Donc ça donne quelque chose comme ça:

#!/bin/sh

#On rappelle le chemin ou se trouve l'exécutable dont on va se servir
PATH=/bin:/sbin:/usr/bin:/usr/sbin

#On vide complètement les règles
iptables -t filter -F
iptables -t filter -X

#Tout le trafic est bloqué...
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

#...sauf les connexions déjà établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#On autorise le serveur a pouvoir communiquer avec lui même (la boucle locale)
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

#Si on veut bloquer des adresses en particulier c'est ici qu'il faut les ajouter car en dessous on commence à ouvrir les ports et on risque que ces règles prennent le pas sur un blocage spécifique

iptables -A INPUT -s A.B.C.D -j DROP
iptables -A INPUT -s X.X.Y.Y -j DROP

#Autoriser le ping dans les deux sens
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT

#Autorisation du traffic Web en entrant
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

#Autorisation du traffic SSH en entrant pour le management du serveur
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT

#Autorisation du web en sortant (utile pour récupérer des sources)
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT

#Autorisation SSH, FTP en sortant
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

#Autorisation NTP, RTM(OVH), DNS,
iptables -t filter -A OUTPUT -p tcp --dport 123 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 6100:6200 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT

#Protection DDOS
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT

#Anti Scan de port
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Voilà donc comme je l’ai dit ce n’est pas un script parfait mais il permet au moins de voir que fait chaque ligne et reste clair malgrès tout. Il est évident qu’il faudrait réfléchir a une autre méthode si les règles viennent à se multiplier parce que cela peut vite devenir ingérable. Ceci dit vous allez pouvoir avoir une base compréhensible pour sécuriser votre serveur de manière fiable. En tout cas au niveau des connexions réseau !

Emergency DOS or DDOS stopping script

28/01/2023 Aucun commentaire

If you are under a DOS or DDOS attack and running out of your mind or don’t know what to do, use this script to get ride of this panic situation.

DoS or DDoS is an attempt to make a victim website unavailable by creating hundreds to hundreds thousands of established connections that overflow victim resources and makes a website unavailable to the genuine users/visitors.

Short and useful slide that definite this script can be view on slideshare

You can run script to mitigate a low level ddos attack some how while and can stop DOS attack completely. This script is available under GPL license from the author.

How to mitigate DoS or DDoS attack?

Stop or flush other rules for now :

service apf stop
iptables -F
wget http://www.hackersgarage.com/wp-content/uploads/2011/08/antiDDoS.txt
mv antiDDoS.txt antiDDoS.sh
chmod u+x antiDDoS.sh
./antiDDoS.sh

Some other useful commands to analyze the type of attacks :

netstat -antp | grep ESTABLISHED
netstat -antp | grep -i sync
netstat --help

Source: hackersgarage.com

Iptables Firewall

26/01/2023 Aucun commentaire

Source: tty1.netthere

This page presents a simple firewall script. It is probably not the best of all possible firewalls, nor the most secure, but may be a starting point for your experiments. Please send any comments and suggestions to <tehpeh-web@tty1.net>.

Update 2011-05-28: IPv6 script

Please see the page for a newer firewall script with IPv6 support.

Turning on native Kernel IPv4 protection

The Linux kernel provides some basic protections against manipulated IP packets. A configuration could be:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies                          # enable syn cookies (prevent against the common 'syn flood attack')
echo 0 > /proc/sys/net/ipv4/ip_forward                              # disable Packet forwarning between interfaces
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts             # ignore all ICMP ECHO and TIMESTAMP requests sent to it via broadcast/multicast
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians                   # log packets with impossible addresses to kernel log
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses       # disable logging of bogus responses to broadcast frames
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter                      # do source validation by reversed path (Recommended option for single homed hosts)
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects                 # don't send redirects
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route            # don't accept packets with SRR option

Further reading:

  • The file Documentation/networking/ip-sysctl.txt in your kernel source directory
  • Network Security with /proc/sys/net/ipv4

Limit ping responses

Any iptables rule can be tuned to respond only to a limited number of times per time unit by using the limit module. This can be extremely useful for log entries (A ping flooding will not lock down your computer by writing to log files). I will show an example on how to limit on ICMP responses. This is not really useful, because it imposes a maximum number of responses for ALL source IP addresses, but it may help to reduce network traffic on brute force attacks (and reduce volume in the log file).

iptables -A INPUT  -p icmp -m limit --limit 10/second -j ACCEPT
iptables -A INPUT  -p icmp -j DROP

This will limit the ICMP responses to a maximum of 10 replies per second. All the rest is silently dropped. Beware: dropping ICMP responses may slow down or cut off legitimate users (for example when ICMP “Fragmentation Needed” packets are dropped).

Dealing with brute force ssh attacks

A stateful firewall can make brute force ssh scans more painful to the attacker by slowing down the responses. I will present a simple teergrubing strategy against ssh scans. This method relies on the IPTables/Netfilter Recent Module, written by Snow-man. The idea is simple: permit only a limited number of new connections per source IP address; drop any further connection attempt for a while.

iptables -A INPUT -p tcp --dport 22 -m recent --rcheck --seconds 60 --hitcount 2 --name SSH -j LOG --log-prefix "SH "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 2 --name SSH -j DROP
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT  -i $int_if -m state --state ESTABLISHED,RELATED -j ACCEPT

Line 1 of the script checks if the source IP has already marked as ‘Bad Guy’ and logs the packet, if so. The second line drops the packet if it comes from a marked IP address and marks the source again. This ensures that the source will stay blacklisted as long as the attack continues. The third line marks the source IP as ‘Bad Guy’ if there are more than 2 connection attempts per minute. Note that already established connections continue to work (because the packets will no more arriving on 22).

Further reading:

Lire la suite…

Detect and Block WordPress Brute Force Login Attacks

26/01/2023 Aucun commentaire

detect and block wordpress brute forceIf you run a wordpress blog these days, you are likely to experience brute force attacks where nefarious individuals attempt to break in to your website by quickly a list of userids and passwords against your wp-login.php.  Here’s how I automated detection and blocking of WordPress brute force login attacks.

Detecting a WordPress Brute Force Attack

One can typically detect a wordpress brute force attack by parsing through your webserver’s access_log file.  The access_log file records all of the access requests that a web server handles.  A brute force attack typically will have frequent and numerous attempts to the wp-login.php file as shown below:

Example:  In the access_log file below, we detect a brute force login attack on our WordPress blog.  We detected it by noticing frequent and constant requests to the wp-login.php file.

31.192.210.159 - - [11/Sep/2014:02:01:43 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:44 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:45 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:47 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:49 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:50 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:51 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:52 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:54 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:55 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"

Typically in an event like this, I lookup the IP address in the ARIN database as I showed in a previous article:  What Personal Information Can You Get From Your Web Server?  Frequently, I find that the address is from APAC or RIPE addresses.

Lire la suite…