Archive

Articles taggués ‘iptables’

How to Change Location of IPTables Logs

25/03/2024 Comments off

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 Comments off

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…

Categories: Réseau, Sécurité Tags: , , ,

How to: Linux Iptables block common attacks

23/03/2024 Comments off

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 Comments off

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: , ,

MMD-0035-2015 – .IptabLex or .IptabLes on shellshock.. sponsored by ChinaZ actor

15/03/2024 Comments off

Source: Malware Must Die!

The background

.IptabLex & .IptabLes ELF DDoS malware is the malware made by China DDoSer crime group, designed to infect multiple architecture of Linux distribution, was aiming for Linux boxes in the internet with the low security and authentication flaw in SSH as vector of infection, was an emerged ELF threat in 2014.

Historically, MalwareMustDie, NPO (MMD) is the first entity who detected this malware around May last year and named it as Linux .Iptablesx|s on our last year’s alert MMD-0025-2014 [link] released on June 15, 2014. And we build malware repository for this ELF family for sharing samples and trend for researchers and industries on kernelmode started from September 4th 2014 [link], since the threat was gone so wild at the time and there was so few information about this malware that causing low awareness and detection ratio, so we managed all we can to suppress the growth of infection rate.

The DDoS attacks originated from this malware, in quantity of incidents and traffic used, was so massive in 2014 causing some warning was released from important security entities in September 2014, as per announced by Prolexic (thank you for mentioning MalwareMustDie) [link] in their Threat Advisory with « High Risk » level, following by Akamai‘s warning referred to the Prolexic’s advisory announcing the world wide warning [link] of .IptableS|X.

Afterward, Linux .IptableS / .IptablesX ELF malware was still be detected in the wild until the end of October 2014, but since November 2014 we did not find any significant wave of infection using these family, wiped by the emerge of many other China DDoS new malware families that we detected also afterwards. From the early this year (January 2015), we started to assume the malware popularity and development of .IptabLes|x was stopped..

However, on June 27th 2015 I was informed in the twitter by a friend @TinkerSec for what was suspected as Linux/ChinaZ infection. I supported him with ELF binary sample’s « real time » analysis in twitter as per shown in his report below:

Today, our team mate @benkow has detected a shellshock attack with having the same payload as sample, and curiousity made me taking a deeper analysis this time, to find and feel so surprised to realize that the payload is a Linux IptableS or .IptablesX variant actually. I can not believe this myself so I checked many times until I am very positive with this conclusion and after understanding why we were thinking it was Linux/ChinaZ I wrote this information as the follow up, the return of 2014’s DDoS disaster, the IptableS|X threat. Below is the detail.

Lire la suite…

Categories: Réseau, Sécurité Tags: , ,