Posts Tagged ‘iptables’
Thursday, June 1st, 2023 
Linux users have most definitely used Netfilter (the older from us might remember and have used ipchains) and rest
should know well or at least partially tried iptables or if you have digged into Linux firewalls more professionally, might have tried nftables
and the newer firewalld (firewall-cmd) that is the standard nowadays in CentOS / Fedora and RHEL (again an abstraction over iptables.).
On Debian firewall is organized around custom shell scripts that deal with iptables chains, or if on Ubuntu perhaps you have tried UFW (The Uncomplicated Firewall)
frontend program for managing firewalls again with iptables. For the lazy ones UFW even has another GUI frontend called Gufw (intended to be easy, intuitive,
graphical user interface for managing Uncomlicated firewall.
Different Linux distributions do use a different set of firewall mechanisms preconfigure but there are other firewall solutions on other Unixes such as ipfilter.
That historically were heavily used that is worthy mentioning and if you happen to pop-up working as a network guy inside some large corporations you might face it.
IPFilter (commonly referred to as ipf) is an open-source software package that provides firewall services and network address translation (NAT) for many Unix-like operating systems.
The author and software maintainer is Darren Reed. IPFilter supports both IPv4 and IPv6 protocols, and is a stateful firewall.
IPFilter is delivered with FreeBSD, NetBSD, Solaris 10 & 11, illumos, OpenIndiana and HP-UX.
It used to be a part of OpenBSD, but it was removed by Theo de Raadt in May 2001 due to problems with its license.
It was subsequently replaced in OpenBSD by PF, which was developed by OpenBSD's own developers.
DragonFly BSD removed its support for IPFilter in May 2011.
IPFilter can be installed as a runtime-loadable kernel module or directly incorporated into the operating system kernel, depending on the specifics of each kernel and user preferences.
The software's documentation recommends the module approach, if possible.
Here are some commands for displaying, changing and distributing IP filters with ipfilter.
It will be mostly useful, if you happen to have some obsolete OS infrastructure or OpenBSD.
The commands given below are to add / remove and activate rules on machine with ipfilter:
# ipfilter –clone
# ipfilter –save
# ipfilter –activate
# ipfilter -addrule
# ipfilter -delrule
# help ipfilter
1. Check ipfilter current config
# ipfilter –show
Name: default_ipv4, Type: ipv4, State: active
Rule Source IP Protocol Dest Port Action
1 any tcp 22 permit
2 any tcp 23 permit
3 any tcp 80 permit
4 any tcp 443 permit
5 any udp 161 permit
6 any udp 123 permit
7 any tcp 600 – 1023 permit
8 any udp 600 – 1023 permit
Name: default_ipv6, Type: ipv6, State: active
Rule Source IP Protocol Dest Port Action
1 any tcp 22 permit
2 any tcp 23 permit
3 any tcp 80 permit
4 any tcp 443 permit
5 any udp 161 permit
6 any udp 123 permit
7 any tcp 600 – 1023 permit
8 any udp 600 – 1023 permit
Name: default_ipv4_new, Type: ipv4, State: defined
Rule Source IP Protocol Dest Port Action
1 any tcp 22 permit
2 any tcp 23 permit
3 any tcp 80 permit
4 any tcp 443 permit
5 any udp 161 permit
6 any udp 123 permit
7 any tcp 600 – 1023 permit
8 any udp 600 – 1023 permit
2. Clone and activate ipfilter configuration
# ipfilter –clone default_ipv4_new -from default_ipv4
# ipfilter –activate default_ipv4_new
# ipfilter –show
Name: default_ipv4, Type: ipv4, State: defined
Rule Source IP Protocol Dest Port Action
1 any tcp 22 permit
2 any tcp 23 permit
3 any tcp 80 permit
4 any tcp 443 permit
5 any udp 161 permit
6 any udp 123 permit
7 any tcp 600 – 1023 permit
8 any udp 600 – 1023 permit
Name: default_ipv6, Type: ipv6, State: active
Rule Source IP Protocol Dest Port Action
1 any tcp 22 permit
2 any tcp 23 permit
3 any tcp 80 permit
4 any tcp 443 permit
5 any udp 161 permit
6 any udp 123 permit
7 any tcp 600 – 1023 permit
8 any udp 600 – 1023 permit
Name: default_ipv4_neu, Type: ipv4, State: active
Rule Source IP Protocol Dest Port Action
1 any tcp 22 permit
2 any tcp 23 permit
3 any tcp 80 permit
4 any tcp 443 permit
5 any udp 161 permit
6 any udp 123 permit
7 any tcp 600 – 1023 permit
8 any udp 600 – 1023 permit
3. Modify cloned configuration
Lets say we would like to delete the telnet port accept traffic rule (port 23)
# ipfilter –delrule default_ipv4_new -rule 2
To permit the rule agian
# ipfilter –addrule default_ipv4_new -rule 2 -sip any -dp 23 -proto tcp -act permit
To save the rule
# ipfilter –save default_ipv4_new
Tags: active, firewalld, ipchains, iptables, ipv4, ipv6, Modify, OpenBSD, permit, tcp
Posted in Everyday Life, Firewall, Linux, System Optimization | 1 Comment »
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 😉
Tags: bootup, Cheers, configure, confusion, dport, encrypted tunnel, external internet, flow, Forward, GRE, gre tunnel, Hope, host, hosts, How to, init, init scripts, Insert, internal ip address, internet ip address, ip nat, iptables, iptables firewall, kernel module, kernel modules, linux router, linux server, Load, make, modprobe, module linux, necessery, POSTROUTING, pptp, reason, redirect, sbin, system boot, tcp, topic, traffic flow, tutorial, window
Posted in Linux, System Administration | 6 Comments »
Monday, October 14th, 2013 
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
Tags: Flood Denial of Service, ICMP, ICMP Ping flood, ICMP traffic, iptables
Posted in Computer Security, System Administration | 1 Comment »
Friday, June 28th, 2013 
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/iptables – default 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)
….
…..
Tags: active directory, c class, dmz router, dport, e check, grep, iptables, local network, network c, nmap, open windows shares, samba shares, udp port numbers, windows network, windows user
Posted in Computer Security, Linux, System Administration, Various | No Comments »
Friday, April 12th, 2013 
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
The 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 🙂
Tags: configuration stage, courier imap, exit status, exiting, imap, imapd, installation script, iptables, Linux, overrides, script header, scripts, servers, ubuntu linux, Watchdog
Posted in Linux, System Administration | 1 Comment »
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—–
Tags: adsl, boot process, BTC, busybox, cdrom, client, company servers, dport, External, file, filesystem, firewall, freak box, init, initrd, ip ranges, ips, iptables, kinky, lilo, linux kernel, machine, mangle, mark, mess, nomen, partition, random ip, rescue, s box, server problems, something, thenew, weekend, work, xxxxx
Posted in Everyday Life | No Comments »
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.
Tags: ALLOW, BBB, blogged, brute force, CCC, ddd, dport, EEE, filter rules, INPUT, ips, iptables, Linux, Main, name, nbsp, port, port 22, port 23, removeEach, sbin, server, ssh, sshbr, SYN, time, value, way, whitelist
Posted in Computer Security, Linux, System Administration | 2 Comments »
