Archive

Articles taggués ‘firewall’

TCP SYN flood DOS attack with hping3

26/03/2024 Aucun commentaire

Hping

Wikipedia defines hping as :

hping is a free packet generator and analyzer for the TCP/IP protocol distributed by Salvatore Sanfilippo (also known as Antirez). Hping is one of the de facto tools for security auditing and testing of firewalls and networks, and was used to exploit the idle scan scanning technique (also invented by the hping author), and now implemented in the Nmap Security Scanner. The new version of hping, hping3, is scriptable using the Tcl language and implements an engine for string based, human readable description of TCP/IP packets, so that the programmer can write scripts related to low level TCP/IP packet manipulation and analysis in very short time.

On ubuntu hping can be installed from synaptic manager.

$ sudo apt-get install hping3

Syn flood

To send syn packets use the following command at terminal

$ sudo hping3 -i u1 -S -p 80 192.168.1.1

The above command would send TCP SYN packets to 192.168.1.1
sudo is necessary since the hping3 create raw packets for the task , for raw sockets/packets root privilege is necessary on Linux.

S – indicates SYN flag
p 80 – Target port 80
i u1 – Wait for 1 micro second between each packet

More options

Lire la suite…

How to Change Location of IPTables Logs

25/03/2024 Aucun commentaire

Logs are a very important aspect of any firewall. In IPTables, linux provides such functionality as logging, but by default the logs go to a file /var/log/syslog or /var/log/messages . Sometimes it can be hard to find the information you need, as logs from the entire system are also found there.

If you want to change the file where IPTables logs into, you must configure IPTables rules to display the log prefix, next thing is configure RsysLog to get this prefix and send this to a custom log file that contains only iptables log information.

  • Check if you have RsysLog installed and running
root@dbsysnet:/home/olivier# dpkg -l | grep rsyslog
ii  rsyslog                               8.32.0-1ubuntu4                                 amd64        reliable system and kernel logging daemon
Jul 20 17:59:56 dbsysnet systemd[1]: Starting System Logging Service...
Jul 20 17:59:56  systemd[1]: Started System Logging Service.
Jul 20 17:59:56  rsyslogd[813]: warning: ~ action is deprecated, consider using the 'stop' statement instead [v8.32.0 try http://www.
Jul 20 17:59:56  rsyslogd[813]: imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd.  [v8.32.0]
Jul 20 17:59:56  rsyslogd[813]: rsyslogd's groupid changed to 106
Jul 20 17:59:56  rsyslogd[813]: rsyslogd's userid changed to 102
Jul 20 17:59:56  rsyslogd[813]:  [origin software="rsyslogd" swVersion="8.32.0" x-pid="813" x-info="http://www.rsyslog.com"] start
  • Configure your IPTABLES rules with --log-prefix
# iptables -A INPUT -p tcp --dport 22 --syn -j LOG --log-prefix "[IPTABLES]: "
  • Create configuration file for RsysLog
# touch /etc/rsyslog.d/10-iptables.conf
  • Open this file and paste below configuration and tne save file
:msg, contains, "[IPTABLES]: " -/var/log/firewall.log
& ~

Explanation:

First line check data log for word [IPTABLES] : and if the word is found it will be sent to the file /var/log/firewall.log

Second line is responsible for stopping the log processing and sending it to the standard location in this case /var/log/syslog or /var/log/messages

  • Restart RsysLog service
root@:/home/olivier# systemctl restart rsyslog

Lire la suite…

Categories: Réseau, Système Tags: , , ,

Linux Iptables Avoid IP Spoofing And Bad Addresses Attacks

23/03/2024 Aucun commentaire

Source: nixCraft

Spoofing and bad address attack tries to fool the server and try to claim that packets had come from local address/network.

Following IP/netwok address are know to open this kind of attack:

Incoming source IP address is your servers IP address

Bad incoming address from following ranges:

  • 0.0.0.0/8
  • 127.0.0.0/8
  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
  • 192.168.0.0/16
  • 224.0.0.0/3
  • Your own internal server/network ip address/ranges.

Lire la suite…

How to: Linux Iptables block common attacks

23/03/2024 Aucun commentaire

Source: nixCraft

Following list summaries the common attack on any type of Linux computer:

Syn-flood protection

In this attack system is floods with a series of SYN packets. Each packets causes system to issue a SYN-ACK responses. Then system waits for ACK that follows the SYN+ACK (3 way handshake). Since attack never sends back ACK again entire system resources get fulled aka backlog queue. Once the queue is full system will ignored incoming request from legitimate users for services (http/mail etc). Hence it is necessary to stop this attack with iptables.

Force SYN packets check

Make sure NEW incoming tcp connections are SYN packets; otherwise we need to drop them:

iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Force Fragments packets check

Packets with incoming fragments drop them. This attack result into Linux server panic such data loss.

iptables -A INPUT -f -j DROP

XMAS packets

Incoming malformed XMAS packets drop them:

iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

Lire la suite…

Categories: Sécurité, Système Tags: ,

Linux Iptables Limit the number of incoming tcp connection / syn-flood attacks

22/03/2024 Aucun commentaire

A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a target’s system. This is a well known type of attack and is generally not effective against modern networks. It works if a server allocates resources after receiving a SYN, but before it has received the ACK.

if Half-open connections bind resources on the server, it may be possible to take up all these resources by flooding the server with SYN messages. Syn flood is common attack and it can be block with following iptables rules:

iptables -A INPUT -p tcp –syn -m limit –limit 1/s –limit-burst 3 -j RETURN

All incoming connection are allowed till limit is reached:

  • –limit 1/s: Maximum average matching rate in seconds
  • –limit-burst 3: Maximum initial number of packets to match

Open our iptables script, add the rules as follows:

# Limit the number of incoming tcp connections
# Interface 0 incoming syn-flood protection
iptables -N syn_flood
iptables -A INPUT -p tcp --syn -j syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A syn_flood -j DROP
#Limiting the incoming icmp ping request:
iptables -A INPUT -p icmp -m limit --limit  1/s --limit-burst 1 -j ACCEPT
iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j LOG --log-prefix PING-DROP:
iptables -A INPUT -p icmp -j DROP
iptables -A OUTPUT -p icmp -j ACCEPT

First rule will accept ping connections to 1 per second, with an initial burst of 1. If this level crossed it will log the packet with PING-DROP in /var/log/message file. Third rule will drop packet if it tries to cross this limit. Fourth and final rule will allow you to use the continue established ping request of existing connection.
Where,

  • ‐‐limit rate: Maximum average matching rate: specified as a number, with an optional ‘/second’, ‘/minute’, ‘/hour’, or ‘/day’ suffix; the default is 3/hour.
  • ‐‐limit‐burst number: Maximum initial number of packets to match: this number gets recharged by one every time the limit specified above is not reached, up to this number; the default is 5.

You need to adjust the –limit-rate and –limit-burst according to your network traffic and requirements.

Let us assume that you need to limit incoming connection to ssh server (port 22) no more than 10 connections in a 10 minute:

iptables -I INPUT -p tcp -s 0/0 -d $SERVER_IP --sport 513:65535 --dport 22 -m state --state NEW,ESTABLISHED -m recent --set -j ACCEPT
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 11 -j DROP
iptables -A OUTPUT -p tcp -s $SERVER_IP -d 0/0 --sport 22 --dport 513:65535 -m state --state ESTABLISHED -j ACCEPT
Categories: Réseau, Sécurité Tags: , ,