Attackers getting past IPTables
Re: Attackers getting past IPTables
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.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: Attackers getting past IPTables
The default rules by firewalld:
Note that:
Allow only one service (ssh). On your custom rules you could narrow that down to trusted subnet.
On the
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 -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
- iptables -S can filter, unlike iptables-save
- The first rule is "allow replies"
- We trust ourselves (the loopback)
- If we accept something, it will be explicitly in the INPUT_* chains
- The default is to reject all new connections
Code: Select all
-p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-p icmp -j ACCEPT
On the
- -s 212.0.0.0/8 drop
- -s 96.0.0.0/8 allow
- drop
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
Re: Attackers getting past IPTables
OK, so noted. Thanks.
Re: Attackers getting past IPTables
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
Re: Attackers getting past IPTables
Sorry, I missed page 2 and didnt see replies to @billwest
Re: Attackers getting past IPTables
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!
@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!
Re: Attackers getting past 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
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).