Attackers getting past IPTables

Issues related to configuring your network
User avatar
TrevorH
Forum Moderator
Posts: 25542
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Attackers getting past IPTables

Post by TrevorH » 2019/05/23 06:22:24

Look at your tcpdump output and check if you see responses going back. If you do then the traffic has got to your application and it is talking back. If you don't and the iptables counters are increasing, then your rules are working.
CentOS 5 died in March 2017 - migrate NOW!
Full time Geek, part time moderator. Use the FAQ Luke

User avatar
jlehtone
Posts: 2142
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Attackers getting past IPTables

Post by jlehtone » 2019/05/23 06:59:43

The default rules by firewalld:

Code: Select all

# iptables -S INPUT
-P INPUT ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES_SOURCE
-A INPUT -j INPUT_ZONES
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
Note that:
  1. iptables -S can filter, unlike iptables-save
  2. The first rule is "allow replies"
  3. We trust ourselves (the loopback)
  4. If we accept something, it will be explicitly in the INPUT_* chains
  5. The default is to reject all new connections
For the record, firewalld's default zone "public" allows only:

Code: Select all

-p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-p icmp -j ACCEPT
Allow only one service (ssh). On your custom rules you could narrow that down to trusted subnet.

On the
  1. -s 212.0.0.0/8 drop
  2. -s 96.0.0.0/8 allow
  3. drop
one can ask whether the rule 1 is necessary. Rule 2 will not match packets from 212.0.0.0/8 and rule 3 will drop all that the rule 2 did not match.
On the other hand you get statistics about attempts from 212.0.0.0/8 and rules 2 and 3 do not have to evaluate those packets. Are those significant benefits?

@billwest:
Do check your statistics. Huge majority of packets tends to be RELATED, ESTABLISHED. There is no point to check them with other rules. An example:

Code: Select all

# iptables -vnL INPUT
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 554M  354G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
26349 1574K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
61593 8499K INPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
61593 8499K INPUT_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
61593 8499K INPUT_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  260 10400 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
61080 8471K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

billwest
Posts: 147
Joined: 2006/11/19 10:50:31
Location: Perth, Western Australia

Re: Attackers getting past IPTables

Post by billwest » 2019/05/23 09:09:40

OK, so noted. Thanks.

gwatson
Posts: 13
Joined: 2018/08/10 14:53:02

Re: Attackers getting past IPTables

Post by gwatson » 2019/05/23 09:41:50

I have that in there @billwest, are you saying I should move it?

Code: Select all

#!/bin/bash
#
# iptables example configuration script
#
# Flush all current rules from iptables
#
 iptables -F
#
# Allow SSH connections on tcp port 22
# This is essential when working on remote servers via SSH to prevent locking yourself out of the system
#
 iptables -A INPUT -p tcp --dport 22 -j ACCEPT
#
# Set default policies for INPUT, FORWARD and OUTPUT chains
#
 iptables -P INPUT DROP
 iptables -P FORWARD DROP
 iptables -P OUTPUT ACCEPT
#
# Set access for localhost
#
 iptables -A INPUT -i lo -j ACCEPT
#
# Accept packets belonging to established and related connections
#
 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#
# Accept packets from trusted IP addresses
 iptables -A INPUT -m state --state NEW -s 215.0.0.0/8 -j DROP
 iptables -A INPUT -m state --state NEW -s 164.0.0.0/8 -j DROP
 iptables -A INPUT -m state --state NEW -s 3

gwatson
Posts: 13
Joined: 2018/08/10 14:53:02

Re: Attackers getting past IPTables

Post by gwatson » 2019/05/23 09:44:50

Sorry, I missed page 2 and didnt see replies to @billwest

gwatson
Posts: 13
Joined: 2018/08/10 14:53:02

Re: Attackers getting past IPTables

Post by gwatson » 2019/05/23 10:14:25

If I look at the tcpdump @TrevorH, I dont see any replies back to the offending IP's in the Destination, they only show up in the source - is this what you mean?

@jlehtone, yes one would have to wonder why you would have to Accept the allowed address if you have to reject the Drop address. Is your suggestion "Allow only one service (ssh). On your custom rules you could narrow that down to trusted subnet." for firewalld or iptables?

Thanks again everyone the assistance!

User avatar
jlehtone
Posts: 2142
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Attackers getting past IPTables

Post by jlehtone » 2019/05/23 11:40:49

gwatson wrote:
2019/05/23 10:14:25
@jlehtone, Is your suggestion "Allow only one service (ssh). On your custom rules you could narrow that down to trusted subnet." for firewalld or iptables?
Conceptually, for both.

You want to write and load your netfilter rules with iptables. It is quite trivial for you to add and remove rules, say:

Code: Select all

-s 1.2.3.4/30 -p tcp --dport 443 -m state --state NEW -m comment --comment "trusted https clients" -j ACCEPT
The caveat is that making mistakes is easy too. Mistakes can lock you out and/or let unwanted parties in.


If firewalld user would not want ssh from everywhere, they could (for example) change interface(s) to zone "drop" and add acceptable sources to the zone "public" (that does allow ssh). The firewalld is mindboggling (and not necessarily in a good way).

Post Reply