Posts Tagged ‘iptables’

How to disable ICMP ping protocol on Linux router with iptables to protect against ping Flood Denial of Service

Monday, October 14th, 2013

how to disable ping icmp protocol on linux server - how to drop incoming ping floods
Its useful to disable ICMP reply sometimes on Linux, especially if you have to deal with abusive script kiddies trying to DoS your host using ICMP Ping flood. Though ICMP Ping Flood is no longer so used as it used to be in past still there are some malicious users trying to use it to revenge a company for being mis-treated or simply because someone paid them to do financial loss to a company through DDoS-ing there internet portal or whatever …

From position of system administrator implementing a tiny one liner iptables rule protects severely against basic ICMP Ping Flood, the rule will not be hard to pass by experienced attacker but still will stop a lot of shit ICMP traffic:

Here is rule:

fw-server:~# iptables -I INPUT -j DROP -p icmp --icmp-type echo-request

Sometimes its necessary Filter IPs of certain hosts trying to DoS you to do so:

fw-server:~# iptables -I INPUT -s xxx.xxx.xxx.xxx -j DROP -p icmp --icmp-type echo-request

To disable ICMP ping requests on IPv6 protocol:

fw-server:~#ip6tables -I INPUT -p icmpv6 --icmp-type 8 -j DROP Note that above firewall rule does not drop all ICMP requests (as there are ICMP requests) necessary for standard TCP/IP or UDP applications to properly operate, but it DROPs packets of ICMP type (echo request).

If later its necessary to temporary enable ping on server quickest way is to FLUSH all INPUT chain temporary, i.e.:

fw-server:~# iptables -F INPUT

Whether necessary to just delete the PING echo-request DROP rule one can also use:

fw-server:~# iptables --list

and

fw-server:~# iptables -D INPUT 10

Here 10 number is the number of line number where DROP icmp rule is showing.

Well that's it now your server will be a bit more secure 😉 Enjoy

Testing your local network for open Windows shares from Linux router

Friday, June 28th, 2013

Windows sharing testing local network for open  shared directories Samba Software logo

Whether you administrate local Windows network behind a DMZ router, It is useful to routinely scan from Linux router which Windows hosts on the network has enabled sharing? The reason is some Windows user might share something by mistake which is not supposed to be shared without even he realizes this.
 

 In case, where new Linux router is configured and Windows hosts behind it can't locate each other on network make sure you have in your firewall before any filtering (REJECT / DROP) firewall rules:

iptables -A INPUT -s 192.168.5.1/24 -m state --state NEW -p tcp --dport 137 -j ACCEPT
iptables -A INPUT  -s 192.168.5.1/24 -m state --state NEW -p tcp --dport 138 -j ACCEPT
iptables -A INPUT  -s 192.168.5.1/24 -m state --state NEW -p tcp --dport 139 -j ACCEPT
iptables -A INPUT  -s 192.168.5.1/24 -m state --state NEW -p tcp --dport 445 -j ACCEPT

iptables -A INPUT -s 0.0.0.0/24 -m state --state NEW -p tcp --dport 445 -j REJECT
iptables -A INPUT -s 0.0.0.0/24 -m state --state NEW -p tcp --dport 138 -j REJECT
iptables -A INPUT -s 0.0.0.0/24 -m state --state NEW -p tcp --dport 139 -j REJECT
iptables -A INPUT -s 0.0.0.0/24 -m state --state NEW -p tcp --dport 137 -j REJECT

(Qquickest way to place rules to exec on next boot is via /etc/rc.local)

Once set, to check all is fine with fwall rules:

router:~# iptables -L INPUT -n

Chain INPUT (policy ACCEPT)

target     prot opt source               destination         

ACCEPT     tcp  —  192.168.5.0/24       0.0.0.0/0           state NEW tcp dpt:137
ACCEPT     tcp  —  192.168.5.0/24       0.0.0.0/0           state NEW tcp dpt:138
ACCEPT     tcp  —  192.168.5.0/24       0.0.0.0/0           state NEW tcp dpt:139
ACCEPT     tcp  —  192.168.5.0/24       0.0.0.0/0           state NEW tcp dpt:445 
REJECT tcp — 0.0.0.0/24 0.0.0.0/0 state NEW tcp dpt:445 reject-with icmp-port-unreachable
REJECT tcp — 0.0.0.0/24 0.0.0.0/0 state NEW tcp dpt:138 reject-with icmp-port-unreachable
REJECT tcp — 0.0.0.0/24 0.0.0.0/0 state NEW tcp dpt:139 reject-with icmp-port-unreachable
REJECT tcp — 0.0.0.0/24 0.0.0.0/0 state NEW tcp dpt:137 reject-with icmp-port-unreachable

On CentOS / Fedora / Redhat router place below rules in /etc/sysconfig/iptablesdefault firewall configuration file for RPM based distros:

-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 137 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 138 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 139 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 445 -j ACCEPT
-A RH-Firewall-1-INPUT -s 0.0.0.0/24 -m state --state NEW -p tcp --dport 137 -j REJECT
-A RH-Firewall-1-INPUT -s 0.0.0.0/24 -m state --state NEW -p tcp --dport 138 -j REJECT
-A RH-Firewall-1-INPUT -s 0.0.0.0/24 -m state --state NEW -p tcp --dport 139 -j REJECT
-A RH-Firewall-1-INPUT -s 0.0.0.0/24 -m state --state NEW -p tcp --dport 445 -j REJECT

After that check lets say 192.168.5.0/24 whether Windows Samba shares ports are reachable:

 To check hosts with Sharing easiest way is to scan your network C class range with nmap for all ports through which Windows Samba shares communicate – i.e. check for open state TCP / UDP port numbers 139,137,139,445 list of samba used default ports is in  /etc/services

router:~# grep netbios /etc/services

netbios-ns 137/tcp # NETBIOS Name Service
netbios-ns 137/udp
netbios-dgm 138/tcp # NETBIOS Datagram Service
netbios-dgm 138/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp

Note that Port 445 microsoft-ds is not in /etc/services because it is not common used (only used whether Windows hosts are using Active Directory)

 
router:~# nmap 192.168.5.1-255 -p 139,137,139,445

Interesting ports on 192.168.5.23:

PORT    STATE    SERVICE
137/tcp filtered netbios-ns
139/tcp open     netbios-ssn
445/tcp open     microsoft-ds
MAC Address: 00:AA:4D:2F:4D:A2 (Giga-byte Technology Co.)


Interesting ports on 192.168.5.31:

PORT    STATE    SERVICE
137/tcp filtered netbios-ns
139/tcp open     netbios-ssn
445/tcp open     microsoft-ds
MAC Address: 3C:B9:2B:76:A6:08 (Unknown)
….
…..

 

 

Fixing insserv: warning: script ‘…’ missing LSB tags and overrides on Debian and Ubuntu Linux

Friday, April 12th, 2013

apt-get f install logo fixing warning script missing LSB tags Debian Ubuntu Linux
 

Some of packages I just tried to install on one of the Debian servers I admin failed during package (set up) configuration stage. Here is little paste with the errors due to it dpkg-reconfigure on each of newly set-up packages failed:

Setting up acct (6.5.4-2.1) ...
insserv: warning: script 'K02courier-imap' missing LSB tags and overrides
insserv: warning: script 'courier-imapd' missing LSB tags and overrides
insserv: warning: script 'iptables' missing LSB tags and overrides
insserv: warning: script 'courier-imap' missing LSB tags and overrides 

Because of this whole package install failed and the usual

# apt-get -f install

supposed to fix mess with packages end up with same errors:

insserv: warning: script 'K02courier-imap' missing LSB tags and overrides
insserv: warning: script 'iptables' missing LSB tags and overrides
insserv: warning: script 'courier-imap' missing LSB tags and overrides
insserv: There is a loop between service watchdog and iptables if stopped
insserv:  loop involving service iptables at depth 2
insserv:  loop involving service watchdog at depth 1
insserv: Stopping iptables depends on watchdog and therefore on system facility `$all' which can not be true!
insserv: exiting now without changing boot order!
update-rc.d: error: insserv rejected the script header
dpkg: error processing acct (--configure):
 subprocess installed post-installation script returned error exit status 1

T
he scripts in question iptables / courier-imap / K02courier-imap were custom created  scripts by me earlier and I have completely forgot about it. In Debian 5 and earlier I used the same scripts to make system load custom services not installed through a standard Debian package. After a bit of research, I've noticed in newer Debian / Ubuntu release, new Commented tags are included in all Debian belonging packages init scripts. Thus the reason for failing package configuration, were my custom scripts were missing those tags. To get around the situation I had to open manually each of the scripts missing init script LSB tags i.e. ( iptables / courier-imap / K02courier-imap ) and add after
#! /bin/sh

shebang;

### BEGIN INIT INFO
# Provides:          skeleton
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Example initscript
# Description:       This file should be used to construct scripts to be
#                    placed in /etc/init.d.
### END INIT INFO

Once those "boilerplate", skele comments are included to solve the mess I had to run again:

# apt-get -f install

This solves it. Enjoy 🙂


How to prevent SSH and FTP bruteforce attacks with iptables on Linux

Friday, December 30th, 2011

Earlier I've blogged about how to prevent brute force attacks with fail2ban, denohosts and blockhosts , however there is easier way to secure against basic brute force attacks by not installing or configuring any external programs.
The way I'm talking about uses simple iptables rules to filter out brute force attacks.

Here is a small script to stop ssh and FTP invaders which try to initiate more than 3 consequential connections in 5 minutes time to port 22 or port 23:

SERVER_MAIN_IP='AAA.BBB.CCC.DDD';/sbin/iptables -N SSH_WHITELIST
/sbin/iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshbr --set
/sbin/iptables -A INPUT -p tcp --dport 22 --syn -j SSH_WHITELIST
/sbin/iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshbr \
--update --rttl --hitcount 3 --seconds 300 -j REJECT --reject-with tcp-reset
/sbin/iptables -A SSH_WHITELIST -s $SERVER_MAIN_IP -p tcp --dport 22 --syn -m recent --rttl --remove

The only thinIf the rules are matched iptables filter rules will be added to the iptables CHAIN SSH_WHITELIST
In case if you want to add some more truested IPs add some more iptables rules, like:

ALLOW_IP='BBB.CCC.DDD.EEE';
/sbin/iptables -A SSH_WHITELIST -s $ALLOW_IP -p tcp --dport 22 --syn -m recent --rttl --remove

Each filtered IP that matches the rules will be filtered for 5 minutes, if 5 minutes is enough, the 300 value has to be increased.
 

How to make GRE tunnel iptables port redirect on Linux

Saturday, August 20th, 2011

I’ve recently had to build a Linux server with some other servers behind the router with NAT.
One of the hosts behind the Linux router was running a Window GRE encrypted tunnel service. Which had to be accessed with the Internet ip address of the server.
In order < б>to make the GRE tunnel accessible, a bit more than just adding a normal POSTROUTING DNAT rule and iptables FORWARD is necessery.

As far as I’ve read online, there is quite of a confusion on the topic of how to properly configure the GRE tunnel accessibility on Linux , thus in this very quick tiny tutorial I’ll explain how I did it.

1. Load the ip_nat_pptp and ip_conntrack_pptp kernel module

linux-router:~# modprobe ip_nat_pptp
linux-router:~# modprobe ip_conntrack_pptp

These two modules are an absolutely necessery to be loaded before the remote GRE tunnel is able to be properly accessed, I’ve seen many people complaining online that they can’t make the GRE tunnel to work and I suppose in many of the cases the reason not to be succeed is omitting to load this two kernel modules.

2. Make the ip_nat_pptp and ip_nat_pptp modules to load on system boot time

linux-router:~# echo 'ip_nat_pptp' >> /etc/modules
linux-router:~# echo 'ip_conntrack_pptp' >> /etc/modules

3. Insert necessery iptables PREROUTING rules to make the GRE tunnel traffic flow

linux-router:~# /sbin/iptables -A PREROUTING -d 111.222.223.224/32 -p tcp -m tcp --dport 1723 -j DNAT --to-destination 192.168.1.3:1723
linux-router:~# /sbin/iptables -A PREROUTING -p gre -j DNAT --to-destination 192.168.1.3

In the above example rules its necessery to substitute the 111.222.223.224 ip address withe the external internet (real IP) address of the router.

Also the IP address of 192.168.1.3 is the internal IP address of the host where the GRE host tunnel is located.

Next it’s necessery to;

4. Add iptables rule to forward tcp/ip traffic to the GRE tunnel

linux-router:~# /sbin/iptables -A FORWARD -p gre -j ACCEPT

Finally it’s necessery to make the above iptable rules to be permanent by saving the current firewall with iptables-save or add them inside the script which loads the iptables firewall host rules.
Another possible way is to add them from /etc/rc.local , though this kind of way is not recommended as rules would add only after succesful bootup after all the rest of init scripts and stuff in /etc/rc.local is loaded without errors.

Afterwards access to the GRE tunnel to the local IP 192.168.1.3 using the port 1723 and host IP 111.222.223.224 is possible.
Hope this is helpful. Cheers 😉

The end of the work week :)

Friday, February 1st, 2008

One more week passed without serious server problems. Yesterday after upgrade to debian 4.0rc2 with

apt-get dist-upgrade and reboot the pc-freak box became unbootable.

I wasn’t able to fix it until today because the machine’s box seemed not to read cds well.The problem was consisted of this that after the boot process of the linux kernel has started the machine the boot up was interrupted with a message saying
/sbin/init is missing

and I was dropped to a busybox without being able to read nothing from my filesystem.Thankfully nomen came to Dobrich for the weekend and today he bring me his cdrom-drive I booted with the debian.

Using Debian’s linux rescue I mounted the partition to check what’s wrong. I suspected something is terribly wrong with the lilo’s conf.

Looking closely to it I saw it’s the lilo conf file it was setupped to load a initrd for the older kernel. changing the line to thenew initrd in /etc/lilo.conf and rereading the lilo; /sbin/lilo -C; /sbin/lilo;

fixed the mess and pc-freak booted succesfully! 🙂

Yesterday I had to do something kinky. It was requested from a client to have access to a mysql service of one of the company servers,the problem was that the client didn’t have static IP so I didn’t have a good way to put into the current firewall.

Everytime the adsl they use got restarted a new absolutely random IP from all the BTC IP ranges was assigned.

The solution was to make a port redirect to a non-standard mysql port (XXXXX) which pointed to the standard 3306 service. I had to tell the firewall not to check the coming IPs on the non-standard port (XXXXX) against the 3306 service fwall rules.

Thanks to the help of a guy inirc.freenode.net #iptables jengelh I figured out the solution.

To complete the requested task it was needed to mark all packagescoming into port (XXXXX) using the iptables mangle option and to add a rule to ACCEPT all marked packages.

The rules looked like this

/sbin/iptables -t mangle -A PREROUTING -p tcp –dport XXXXX -j MARK –set-mark 123456/sbin/iptables -t nat -A PREROUTING -d EXTERNAL_IP -i eth0 -p tcp –dport XXXXX -j DNAT –to-destination EXTERNAL_IP:3306

/sbin/iptables -t filter -A INPUT -p tcp –dport 3306 -m mark –mark 123456 -j ACCEPT .

Something I wondered a bit was should /proc/sys/net/ipv4/ip_forward in order for the above redirect to be working, in case you’re wondering too well it doesn’t 🙂 The working week was a sort of quiteful no serious problems with servers and work no serious problems at school (although I see me and my collegues become more and more unserious) at studying. My grand parentsdecided to make me a gift and give me money to buy a laptop and I’m pretty happy for this 🙂 All that is left is to choose a good machine with hardware supported both by FreeBSD and Linux.

END—–