| View previous topic :: View next topic |
| Author |
Message |
davidshen84
Apprentice
Joined: 09 Aug 2008
Posts: 286
|
 Posted: Tue Jan 03, 2017 12:22 pm Post subject: iptable is not effective with systemd |
 |
|
Hi,
I have emerge iptables:
| Code: | eix iptables -I
[I] net-firewall/iptables
Available versions: (~)1.4.17 1.4.21-r1 (~)1.4.21-r2(0/10) (~)1.4.21-r3(0/10) (~)1.4.21-r4(0/10) (~)1.6.0-r1(0/11) {conntrack ipv6 netlink nftables pcap static-libs}
Installed versions: 1.6.0-r1(08:50:43 PM 01/02/2017)(conntrack ipv6 -netlink -nftables -pcap -static-libs)
Homepage: http://www.netfilter.org/projects/iptables/
Description: Linux kernel (2.4+) firewall, NAT and packet mangling tools
|
and enabled iptable services:
| Code: | systemctl status iptables-restore.service iptables-store.service
● iptables-restore.service - Restore iptables firewall rules
Loaded: loaded (/usr/lib/systemd/system/iptables-restore.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Tue 2017-01-03 19:49:49 CST; 26min ago
Main PID: 1777 (code=exited, status=0/SUCCESS)
Jan 03 19:49:49 XPS13 systemd[1]: Starting Restore iptables firewall rules...
Jan 03 19:49:49 XPS13 systemd[1]: Started Restore iptables firewall rules.
● iptables-store.service - Store iptables firewall rules
Loaded: loaded (/usr/lib/systemd/system/iptables-store.service; enabled; vendor preset: disabled)
Active: inactive (dead) |
But it seems my firewall is not effective. I can still ssh to this computer from a remote computer without adding and iptable rules.
| Code: | sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 ctstate RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
ACCEPT tcp -- anywhere 192.168.122.108 tcp dpt:ms-wbt-server
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
ACCEPT udp -- anywhere anywhere udp dpt:bootpc |
I found in this forum that someone mentioned that they have "iptables.service" file, but on my machine, I do not...maybe this is the problem? But I just re-emerged the package.
| Code: | equery f iptables|grep service
/usr/lib/systemd/system/ip6tables-restore.service
/usr/lib/systemd/system/ip6tables-store.service
/usr/lib/systemd/system/iptables-restore.service
/usr/lib/systemd/system/iptables-store.service
|
I also checked my kernel configuration against the gentoo wiki, and I have rebuild my kernel and rebooted. Nothing helps.
I also checked if the iptable modules are loaded. And they did:
| Code: | lsmod|grep iptable
iptable_filter 2101 1
iptable_nat 2243 1
nf_nat_ipv4 5456 1 iptable_nat
iptable_mangle 1938 1
ip_tables 14839 3 iptable_mangle,iptable_filter,iptable_nat |
Please help.
Thanks,
David.
_________________
David Shen |
|
| Back to top |
|
 |
bbgermany
Veteran
Joined: 21 Feb 2005
Posts: 1799
Location: Oranienburg/Germany
|
| Posted: Tue Jan 03, 2017 1:37 pm Post subject: |
|
|
Hi,
Since your base-rules for INPUT, OUTPUT and FORWARD are still ACCEPT, you wont get any blocks at all.
Make sure your script set the policy to DROP or REJECT first. Then you wont be able to ssh into the box with your current ruleset.
greets, bb
_________________
1st: i5-7400, 16GB, 2TB
2nd: i5-4570, 16GB, 620GB
3rd: i5-4570, 32GB, 14.5TB
4th: i5-3210M, 8GB, 512GB
5th: i5-3210M, 8GB, 120GB |
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2295
Location: Germany
|
| Posted: Tue Jan 03, 2017 1:42 pm Post subject: |
|
|
Hi davidshen84,
i think the store and restore scripts just save the current state of your active iptable rules.
Maybe you start systemd and it restore the empty default rules first and store them again, so that your actually ip-rules or changes got lost. So it should work if you add your rules again and run the store/save script.
1. Apply some Rules or run your firewall skript.
| Code: | | # sh your-firewall-iptable-skript.sh # or add some iptable rules |
2. Check your Iptable Status before...
3. ...saving the rules in the store.
| Code: | | # systemctl start iptables-store.service |
Sometimes, if the rule itself needs some kernel modules that you don't build or load into your Kernel the script complain that or told you that the rule did not match any target.
And don't forget that the order in which you add your rules and the chains default policy matter.
Regrets, and i wish you a happy new Year
Chris |
|
| Back to top |
|
|
davidshen84
Apprentice
Joined: 09 Aug 2008
Posts: 286
|
| Posted: Wed Jan 04, 2017 12:00 pm Post subject: |
|
|
| bbgermany wrote: | Hi,
Since your base-rules for INPUT, OUTPUT and FORWARD are still ACCEPT, you wont get any blocks at all.
Make sure your script set the policy to DROP or REJECT first. Then you wont be able to ssh into the box with your current ruleset.
greets, bb |
By base-rules, if you mean
| Code: | sudo iptables -vS
-P INPUT ACCEPT -c 16716 10152010
-P FORWARD ACCEPT -c 0 0
-P OUTPUT ACCEPT -c 16389 5845136 |
I guess you are right. But I wonder how they get into my system. I never updated iptable rules before. Are they default value? I think the default rules should be DROP which I think is a safer practice.
Regards,
David.
_________________
David Shen |
|
| Back to top |
|
|
bbgermany
Veteran
Joined: 21 Feb 2005
Posts: 1799
Location: Oranienburg/Germany
|
| Posted: Wed Jan 04, 2017 12:32 pm Post subject: |
|
|
Hi,
the default policy for all chains is accept. So if you replace it with DROP or even REJECT for INPUT, you shouldnt get a connection after running a restore of your rules.
greets, bb
_________________
1st: i5-7400, 16GB, 2TB
2nd: i5-4570, 16GB, 620GB
3rd: i5-4570, 32GB, 14.5TB
4th: i5-3210M, 8GB, 512GB
5th: i5-3210M, 8GB, 120GB |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 16513
|
| Posted: Thu Jan 05, 2017 3:30 am Post subject: |
|
|
If you have no netfilter in the kernel, then the effective policy is ACCEPT because there is nothing that can do otherwise. Setting netfilter's default policy to be ACCEPT maintains the principle of least surprise: adding netfilter support to your kernel should not automatically cause its network stack to begin behaving differently than a netfilter-free kernel. Violating this principle would be especially unpleasant for people who build netfilter as modules, since the kernel would act one way before modules load, and a different way after -- all without user code changing any netfilter rules.
Some people want generally permissive policies, such as is used when banning specific problem peers, but otherwise allowing unsolicited traffic. If your use case specifies a restrictive default policy, you can and probably should arrange for that policy to load before the network is activated, so that your firewall is already effective when you first get an IP address. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
