Re: ifup && iptables error
Exactly, i wan't reformulate the question. What should I change there to get these errors disappear? I'm trying to change some values for example in /etc/iptables/rules.v6 # Generated by xtables-save v1.8.2 on Mon Aug 5 19:42:00 2019 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] # Bad argument #COMMIT # Completed on Mon Aug 5 19:42:00 2019 But i get the following error now when execute the following command /usr/share/netfilter-persistent/plugins.d/25-ip6tables start ip6tables-restore: COMMIT expected at line 8 On Tue, Feb 25, 2020 at 10:37 PM William Torrez Corea wrote: > I get the following error message > > [] Configuring network interfaces...ifquery: > /etc/network/interfaces:19: unknown or no address type and no inherits > keyword specified > ifquery: couldn't read interfaces file "/etc/network/interfaces" > ifquery: /etc/network/interfaces:19: unknown or no address type and no > inherits keyword specified > ifquery: couldn't read interfaces file "/etc/network/interfaces" > ifup: /etc/network/interfaces:19: unknown or no address type and no > inherits keyword specified > ifup: couldn't read interfaces file "/etc/network/interfaces" > failed. > [ ok ] Cleaning up temporary files > [ ok ] Setting up ALSA...done. > [ ok ] Setting sensors limits...done. > [] Loading netfilter rules...run-parts: executing > /usr/share/netfilter-persistent/plugins.d/15-ip4tables start > Bad argument `COMMIT' > Error occurred at line: 4 > Try `iptables-restore -h' or 'iptables-restore --help' for more > information. > run-parts: /usr/share/netfilter-persistent/plugins.d/15-ip4tables exited > with return code 2 > run-parts: executing > /usr/share/netfilter-persistent/plugins.d/25-ip6tables start > failed. > > -- > William Torrez Corea > -- William Torrez Corea
Re: ifup && iptables error
Hi. On Tue, Feb 25, 2020 at 10:37:18PM +, William Torrez Corea wrote: > I get the following error message > > ifquery: /etc/network/interfaces:19: unknown or no address type and no > inherits keyword specified You have a syntax error at line 19 of your e/n/i. > /usr/share/netfilter-persistent/plugins.d/15-ip4tables start > Bad argument `COMMIT' > Error occurred at line: 4 And whatever is in /etc/iptables/rules.v4 - it's not a valid output of iptables-save. Now, to answer the question "what should I change there to get these errors disappear" - the contents of both files are needed. Reco
Re: ifup && iptables error
William Torrez Corea wrote: > [] Loading netfilter rules...run-parts: executing > /usr/share/netfilter-persistent/plugins.d/15-ip4tables start > Bad argument `COMMIT' > Error occurred at line: 4 > Try `iptables-restore -h' or 'iptables-restore --help' for more > information. run-parts: > /usr/share/netfilter-persistent/plugins.d/15-ip4tables exited with return > code 2 run-parts: executing > /usr/share/netfilter-persistent/plugins.d/25-ip6tables start > failed. iptables changed to netfilter as default - could be that your issue is related to that? or you are missing somethe value and your scripts break
ifup && iptables error
I get the following error message [] Configuring network interfaces...ifquery: /etc/network/interfaces:19: unknown or no address type and no inherits keyword specified ifquery: couldn't read interfaces file "/etc/network/interfaces" ifquery: /etc/network/interfaces:19: unknown or no address type and no inherits keyword specified ifquery: couldn't read interfaces file "/etc/network/interfaces" ifup: /etc/network/interfaces:19: unknown or no address type and no inherits keyword specified ifup: couldn't read interfaces file "/etc/network/interfaces" failed. [ ok ] Cleaning up temporary files [ ok ] Setting up ALSA...done. [ ok ] Setting sensors limits...done. [] Loading netfilter rules...run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables start Bad argument `COMMIT' Error occurred at line: 4 Try `iptables-restore -h' or 'iptables-restore --help' for more information. run-parts: /usr/share/netfilter-persistent/plugins.d/15-ip4tables exited with return code 2 run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables start failed. -- William Torrez Corea
[solved] ufw and iptables not playing nice in testing with recent upgrade
iptables 1.8.4-3 landed in unstable and iptables/ufw now works. thanks! :) songbird
Re: ufw and iptables not playing nice in testing with recent upgrade
On 13/02/2020 19:37, songbird wrote: tv.deb...@googlemail.com wrote: On 12/02/2020 05:03, riveravaldez wrote: On 2/11/20, songbird wrote: something in there didn't work today when i applied the upgrade. i don't have time to debug or file reports at the moment, so was able to partially downgrade to get a working connection again. put my hold back on iptables. i'd had a hold on it for a while due to reported errors. no idea why i decided i should try to let it go through this morning. i'm kinda tied up for a few weeks... Maybe similar. Yesterday, after dist-upgrade and reboot the network interface seemed not to be working (for instance, none ping worked/responded), it gave me the impression of a driver issue so rebooted and tried with a previous kernel, that seemed to solve partially the situation. Right now: $ uname -a Linux debian 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux The first symptom (with the more recent kernel) was a message at boot about UFW not being able to start (or something similar). That message didn't appeared when I booted with the previous kernel (the one I'm using right now). Not sure of anything. Let me know if I can do something to diagnose this situation properly. Just informing in the hope it's of some utility. Regards! Hi, running a 5.4 and 5.5 self compiled kernels for a while and it is my experience too that ufw/gufw are broken. I switched to firewalld and associated graphical config utilities on the affected machines, purging iptables in the process. On the other hand shorewall + iptables seems to work fine so far. From what I remember reading iptables is on it's way out anyway (correct me if i am wrong). Hope it helps. temporary issue that is known: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949480 songbird Thank you for pointing this, very much appreciated. I don't know how I missed that the first time I ran into this problem. Aside from UFW still being usable Firewalld is worth a look.
Re: ufw and iptables not playing nice in testing with recent upgrade
tv.deb...@googlemail.com wrote: > On 12/02/2020 05:03, riveravaldez wrote: >> On 2/11/20, songbird wrote: >>>something in there didn't work today when i applied >>> the upgrade. >>> >>>i don't have time to debug or file reports at the moment, >>> so was able to partially downgrade to get a working connection >>> again. >>> >>>put my hold back on iptables. i'd had a hold on it for >>> a while due to reported errors. no idea why i decided i >>> should try to let it go through this morning. i'm kinda >>> tied up for a few weeks... >> >> Maybe similar. Yesterday, after dist-upgrade and reboot the network >> interface seemed not to be working (for instance, none ping >> worked/responded), it gave me the impression of a driver issue so >> rebooted and tried with a previous kernel, that seemed to solve >> partially the situation. >> >> Right now: >> >> $ uname -a >> Linux debian 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 >> GNU/Linux >> >> The first symptom (with the more recent kernel) was a message at boot >> about UFW not being able to start (or something similar). That message >> didn't appeared when I booted with the previous kernel (the one I'm >> using right now). >> >> Not sure of anything. Let me know if I can do something to diagnose >> this situation properly. >> >> Just informing in the hope it's of some utility. >> >> Regards! >> > Hi, running a 5.4 and 5.5 self compiled kernels for a while and it is my > experience too that ufw/gufw are broken. I switched to firewalld and > associated graphical config utilities on the affected machines, purging > iptables in the process. > On the other hand shorewall + iptables seems to work fine so far. From > what I remember reading iptables is on it's way out anyway (correct me > if i am wrong). > > Hope it helps. temporary issue that is known: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949480 songbird
Re: ufw and iptables not playing nice in testing with recent upgrade
On 12/02/2020 05:03, riveravaldez wrote: On 2/11/20, songbird wrote: something in there didn't work today when i applied the upgrade. i don't have time to debug or file reports at the moment, so was able to partially downgrade to get a working connection again. put my hold back on iptables. i'd had a hold on it for a while due to reported errors. no idea why i decided i should try to let it go through this morning. i'm kinda tied up for a few weeks... Maybe similar. Yesterday, after dist-upgrade and reboot the network interface seemed not to be working (for instance, none ping worked/responded), it gave me the impression of a driver issue so rebooted and tried with a previous kernel, that seemed to solve partially the situation. Right now: $ uname -a Linux debian 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux The first symptom (with the more recent kernel) was a message at boot about UFW not being able to start (or something similar). That message didn't appeared when I booted with the previous kernel (the one I'm using right now). Not sure of anything. Let me know if I can do something to diagnose this situation properly. Just informing in the hope it's of some utility. Regards! Hi, running a 5.4 and 5.5 self compiled kernels for a while and it is my experience too that ufw/gufw are broken. I switched to firewalld and associated graphical config utilities on the affected machines, purging iptables in the process. On the other hand shorewall + iptables seems to work fine so far. From what I remember reading iptables is on it's way out anyway (correct me if i am wrong). Hope it helps.
Re: ufw and iptables not playing nice in testing with recent upgrade
On 2/11/20, songbird wrote: > something in there didn't work today when i applied > the upgrade. > > i don't have time to debug or file reports at the moment, > so was able to partially downgrade to get a working connection > again. > > put my hold back on iptables. i'd had a hold on it for > a while due to reported errors. no idea why i decided i > should try to let it go through this morning. i'm kinda > tied up for a few weeks... Maybe similar. Yesterday, after dist-upgrade and reboot the network interface seemed not to be working (for instance, none ping worked/responded), it gave me the impression of a driver issue so rebooted and tried with a previous kernel, that seemed to solve partially the situation. Right now: $ uname -a Linux debian 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux The first symptom (with the more recent kernel) was a message at boot about UFW not being able to start (or something similar). That message didn't appeared when I booted with the previous kernel (the one I'm using right now). Not sure of anything. Let me know if I can do something to diagnose this situation properly. Just informing in the hope it's of some utility. Regards!
ufw and iptables not playing nice in testing with recent upgrade
something in there didn't work today when i applied the upgrade. i don't have time to debug or file reports at the moment, so was able to partially downgrade to get a working connection again. put my hold back on iptables. i'd had a hold on it for a while due to reported errors. no idea why i decided i should try to let it go through this morning. i'm kinda tied up for a few weeks... songbird
Re: iptables DROP before PREROUTING
On Fri, 2020-01-10 at 01:52 +0500, Alexander V. Makartsev wrote: > > The answer to your question, I believe, should look like this: > "iptables -I FORWARD -s 23.132.208.0/24 -j DROP" Thanks! That is what I am looking for. To be clear, I'm doing something much more complex, but the underlying issue is that blocked IPs (via ipsets and text file lists) were properly DROPped by INPUT rules but were circumventing via the FORWARD and NAT rules. -Jim P.
Re: iptables DROP before PREROUTING
On 10.01.2020 00:46, Jim Popovitch wrote: > Hello! > > Is there a way to have iptables DROP before PREROUTING. > > Consider this bit of rules on a home firewall, where 24.126.xx.yy is my > home external IP address. > > - > iptables -P INPUT DROP > iptables -P OUTPUT ACCEPT > iptables -A INPUT -i lo -j ACCEPT > iptables -A OUTPUT -o lo -j ACCEPT > > iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT > > iptables -A INPUT -s 23.132.208.0/24 -j DROP > > # DNAT inbound SSH to home PC > iptables -A FORWARD -i eth0 -d 192.168.1.10 -m state --state > NEW,ESTABLISHED,RELATED -j ACCEPT > iptables -t nat -A PREROUTING -p tcp -d 24.126.xx.yy --dport 12345 -j DNAT > --to-destination 192.168.1.10 > iptables -t nat -A POSTROUTING -s 192.168.1.10 ! -d 192.168.1.0/24 -j SNAT > --to 24.126.xx.yy > > iptables -A INPUT -j DROP > > > What I want to do is prevent 23.132.208.0/24 from accessing a service > (port 12345) on my home PC. The problem is, the REROUTING rules preceed > the DROP rule, so the connections get through. Thanks for any > suggestions/help. > > > -Jim P. > > > > I recommend you to look at this article. [1] It provides pretty good explanations and complete iptables flow chart. It will help you to understand how iptables work internally, so you will have better understanding of where to place your rules and what those rules should be. The answer to your question, I believe, should look like this: "iptables -I FORWARD -s 23.132.208.0/24 -j DROP" This rule will be placed at first line in Forward chain of Filter table and will Drop all traffic that comes from 23.132.208.0/24 subnet, after it leaves Prerouting chain of Nat table. [1] https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
Re: iptables DROP before PREROUTING
Hi. On Thu, Jan 09, 2020 at 02:46:25PM -0500, Jim Popovitch wrote: > Is there a way to have iptables DROP before PREROUTING. What you meant is "before PREROUTING in nat". It's an important bit, see below. > What I want to do is prevent 23.132.208.0/24 from accessing a service > (port 12345) on my home PC. The problem is, the REROUTING rules preceed > the DROP rule, so the connections get through. Thanks for any > suggestions/help. Try it (raw table is called before nat one): iptables -t raw -A PREROUTING -s 23.132.208.0/24 -j DROP Reco
iptables DROP before PREROUTING
Hello! Is there a way to have iptables DROP before PREROUTING. Consider this bit of rules on a home firewall, where 24.126.xx.yy is my home external IP address. - iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -s 23.132.208.0/24 -j DROP # DNAT inbound SSH to home PC iptables -A FORWARD -i eth0 -d 192.168.1.10 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -t nat -A PREROUTING -p tcp -d 24.126.xx.yy --dport 12345 -j DNAT --to-destination 192.168.1.10 iptables -t nat -A POSTROUTING -s 192.168.1.10 ! -d 192.168.1.0/24 -j SNAT --to 24.126.xx.yy iptables -A INPUT -j DROP What I want to do is prevent 23.132.208.0/24 from accessing a service (port 12345) on my home PC. The problem is, the REROUTING rules preceed the DROP rule, so the connections get through. Thanks for any suggestions/help. -Jim P.
Re: iptables, routing problems
On 17/12/19 5:06 pm, Richard Hector wrote: > Hi all, > > I've got a networking issue that's confusing me. Got it, I think. I had previously been applying rules before switching to iptables-legacy - so I'd been adding nftables rules. Then I switched, without flushing (or rebooting), so both rulesets were in effect. I had thought that both were interfaces to the same internal stuff, so hadn't realised that iptables -F wouldn't flush nftables rules (or even thought about it, really). Richard signature.asc Description: OpenPGP digital signature
iptables, routing problems
Hi all, I've got a networking issue that's confusing me. When I try to ssh out, I can see the packets being accepted by the rule in the OUTPUT chain, but I can't see them with TCPDUMP. Nothing is hitting the rules in the nat POSTROUTING chain, either. I can see from the ACCEPT rule (in the iptables output) that the packet is going through the interface I expect (enp4s0.1441) Any ideas? I suspect it's something silly I've just failed to spot ... Note that yesterday, when I was on site, I wasn't trying this, but had similar problems with traffic going out - dns packets were being accepted, but not hitting the postrouting snat rule. Today, I can't get to the machine I was testing from, which is how I found the current problem. In both cases, ping works - I can ping the machine I'm trying to ssh to (10.144.1.10), and yesterday I could ping the dns server (8.8.8.8 for test purposes) Background and other info: The system is (supposed to be) a router, based on an old (atom-based) HP thin client connected to a VLAN switch. It's running buster. I've built routers before, but not using VLANs and not (I think) on buster. I'm using iptables-legacy (because I'm relatively familiar with it). Other oddities are: - it's running OpenVPN (which is working; that's how I'm connecting to it today) - there's an odd route I've added to allow talking to bits of my home LAN, despite the external interface of this router being on the same address range (too many people choose 192.168.1.0/24) Here's the routing table: 8< richard@svrouter:~$ sudo ip route default via 192.168.1.1 dev enp4s0.1 onlink 10.144.1.0/24 dev enp4s0.1441 proto kernel scope link src 10.144.1.1 10.144.2.0/24 dev enp4s0.1442 proto kernel scope link src 10.144.2.1 192.168.1.0/24 dev enp4s0.1 proto kernel scope link src 192.168.1.15 192.168.1.96/27 via 192.168.94.1 dev tun0 192.168.94.0/24 dev tun0 proto kernel scope link src 192.168.94.10 8< /etc/network/interfaces: 8< # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # # The primary network interface # auto enp4s0 # iface enp4s0 inet dhcp auto enp4s0.1 iface enp4s0.1 inet static address 192.168.1.15/24 gateway 192.168.1.1 auto enp4s0.1441 iface enp4s0.1441 inet static address 10.144.1.1/24 auto enp4s0.1442 iface enp4s0.1442 inet static address 10.144.2.1/24 8< (interfaces.d is empty) iptables -vnL: 8< Chain INPUT (policy ACCEPT 26 packets, 8528 bytes) pkts bytes target prot opt in out source destination 0 0 LOGtcp -- * * 0.0.0.0/0 0.0.0.0/0tcp spt:22 LOG flags 0 level 4 1109 99188 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0ctstate RELATED,ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0tcp dpt:22 Chain FORWARD (policy ACCEPT 25 packets, 1750 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0ctstate RELATED,ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- enp4s0.1 enp4s0.1441 0.0.0.0/0 0.0.0.0/0tcp dpt:22 0 0 ACCEPT tcp -- enp4s0.1441 enp4s0.1 0.0.0.0/0 0.0.0.0/0tcp dpt:22 0 0 ACCEPT tcp -- enp4s0.1441 enp4s0.1 0.0.0.0/0 0.0.0.0/0tcp dpt:53 0 0 ACCEPT tcp -- enp4s0.1441 enp4s0.1 0.0.0.0/0 0.0.0.0/0tcp dpt:80 0 0 ACCEPT tcp -- enp4s0.1441 enp4s0.1 0.0.0.0/0 0.0.0.0/0tcp dpt:443 0 0 ACCEPT tcp -- enp4s0.1441 enp4s0.1 0.0.0.0/0 0.0.0.0/0tcp dpt:587 676 46636 LOGudp -- enp4s0.1441 enp4s0.1 0.0.0.0/0 0.0.0.0/0udp dpt:53 LOG flags 0 level 4 prefix "PRE-ACCEPT " 676 46636 ACCEPT udp -- enp4s0.1441 enp4s0.1 0.0.0.0/0 0.0.0.0/0udp dpt:53 25 1750 LOGall -- * * 0.0.0.0/0 0.0.0.0/0LOG flags 0 level 4 prefix "FWD " Chain OUTPUT (policy ACCEPT 53 packets, 3180 bytes) pkts bytes target prot opt in out source destination 731 128K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0ctstate RELATED,ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp -- * * 0.0.0.0/0 203.118.153.20 udp spt:1194 dpt:1194 0 0 ACCEPT udp -- * *
Re: [Solved] iptables firewall and web sites not loading
Le 10/12/2019 à 20:13, nektarios a écrit : Pascal Hambourg wrote: Maybe a "MTU black hole" issue with PPPoE. Workarounds : - lower the MTU on the client side to 1492 - add a "TCPMSS --clamp-to-pmtu" iptables rule on the router (...) The tip you gave me really did the job! I found this page in tldp.org describing the mtu issue http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/mtu-issues.html and the I simply ran the iptables command ``` iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu ``` and it was fixed! Please note that - It's a hack. It does not fix the actual issue (inbound packets bigger than the PMTU are silently dropped). - It works only for TCP. - This rule works only for IPv4. If you have IPv6 connectivity, you must add a similar ip6tables rule. - It does not work inside VPNs and tunnels which hide the actual PMTU.
[Solved] iptables firewall and web sites not loading
On Tue, 10 Dec 2019 09:26:46 + Nektarios Katakis wrote: > On Tue, 10 Dec 2019 07:22:05 +0100 > Pascal Hambourg wrote: > > > Le 10/12/2019 à 00:01, Nektarios Katakis a écrit : > > > > > > I am running an iptables firewall on an openwrt router I ve got. > > > Which acts as Firewall/gateway and performs NATing for my internal > > > network - debian PCs and android phones. > > > > > > All good but specific web sites are not loading for the machines > > > that are sitting behind the home router. > > > > > > When attempting on the browser (firefox but tried different ones) > > > the browser stays at `Performing a TLS handshake to > > > bitbucket.org`. wget has similar results: > > > ``` > > > wget https://bitbucket.org > > > --2019-12-09 22:07:32-- https://bitbucket.org/ > > > Resolving bitbucket.org (bitbucket.org)... 18.205.93.0, > > > 18.205.93.1, 18.205.93.2, ... Connecting to bitbucket.org > > > (bitbucket.org)|18.205.93.0|:443... connected. > > > ``` > > > When doing a tcpdump on the router side I can see some initial TCP > > > session establishment and then nothing: > > (...) > > > Of course doing a wget from the router itself works fine as it > > > also works fine on my desktop if I do dynamic port-forwarding > > > with eg. `ssh -D 1050 router` (and configure of course firefox to > > > use it). > > > > Maybe a "MTU black hole" issue with PPPoE. > > Workarounds : > > - lower the MTU on the client side to 1492 > > - add a "TCPMSS --clamp-to-pmtu" iptables rule on the router > > > > Interesting. I m not a network engineer and actually didnt think of > that. I ll give it a shot and update. > > Thanks. > The tip you gave me really did the job! I found this page in tldp.org describing the mtu issue http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/mtu-issues.html and the I simply ran the iptables command ``` iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu ``` and it was fixed! Thanks again! --- Nektarios Katakis
Re: iptables firewall and web sites not loading
On Tue, 10 Dec 2019 07:22:05 +0100 Pascal Hambourg wrote: > Le 10/12/2019 à 00:01, Nektarios Katakis a écrit : > > > > I am running an iptables firewall on an openwrt router I ve got. > > Which acts as Firewall/gateway and performs NATing for my internal > > network - debian PCs and android phones. > > > > All good but specific web sites are not loading for the machines > > that are sitting behind the home router. > > > > When attempting on the browser (firefox but tried different ones) > > the browser stays at `Performing a TLS handshake to bitbucket.org`. > > wget has similar results: > > ``` > > wget https://bitbucket.org > > --2019-12-09 22:07:32-- https://bitbucket.org/ > > Resolving bitbucket.org (bitbucket.org)... 18.205.93.0, 18.205.93.1, > > 18.205.93.2, ... Connecting to bitbucket.org > > (bitbucket.org)|18.205.93.0|:443... connected. > > ``` > > When doing a tcpdump on the router side I can see some initial TCP > > session establishment and then nothing: > (...) > > Of course doing a wget from the router itself works fine as it also > > works fine on my desktop if I do dynamic port-forwarding with eg. > > `ssh -D 1050 router` (and configure of course firefox to use it). > > Maybe a "MTU black hole" issue with PPPoE. > Workarounds : > - lower the MTU on the client side to 1492 > - add a "TCPMSS --clamp-to-pmtu" iptables rule on the router > Interesting. I m not a network engineer and actually didnt think of that. I ll give it a shot and update. Thanks. -- Nektarios Katakis
Re: iptables firewall and web sites not loading
Le 10/12/2019 à 00:01, Nektarios Katakis a écrit : I am running an iptables firewall on an openwrt router I ve got. Which acts as Firewall/gateway and performs NATing for my internal network - debian PCs and android phones. All good but specific web sites are not loading for the machines that are sitting behind the home router. When attempting on the browser (firefox but tried different ones) the browser stays at `Performing a TLS handshake to bitbucket.org`. wget has similar results: ``` wget https://bitbucket.org --2019-12-09 22:07:32-- https://bitbucket.org/ Resolving bitbucket.org (bitbucket.org)... 18.205.93.0, 18.205.93.1, 18.205.93.2, ... Connecting to bitbucket.org (bitbucket.org)|18.205.93.0|:443... connected. ``` When doing a tcpdump on the router side I can see some initial TCP session establishment and then nothing: (...) Of course doing a wget from the router itself works fine as it also works fine on my desktop if I do dynamic port-forwarding with eg. `ssh -D 1050 router` (and configure of course firefox to use it). Maybe a "MTU black hole" issue with PPPoE. Workarounds : - lower the MTU on the client side to 1492 - add a "TCPMSS --clamp-to-pmtu" iptables rule on the router
Re: iptables firewall and web sites not loading
On 12/10/2019 12:01 AM, Nektarios Katakis wrote:
> Hello,
>
> I am running an iptables firewall on an openwrt router I ve got. Which
> acts as Firewall/gateway and performs NATing for my internal network -
> debian PCs and android phones.
>
> All good but specific web sites are not loading for the machines that
> are sitting behind the home router.
>
> When attempting on the browser (firefox but tried different ones) the
> browser stays at `Performing a TLS handshake to bitbucket.org`. wget has
> similar results:
> ```
> wget https://bitbucket.org
> --2019-12-09 22:07:32-- https://bitbucket.org/
> Resolving bitbucket.org (bitbucket.org)... 18.205.93.0, 18.205.93.1,
> 18.205.93.2, ... Connecting to bitbucket.org
> (bitbucket.org)|18.205.93.0|:443... connected.
> ```
> When doing a tcpdump on the router side I can see some initial TCP
> session establishment and then nothing:
> ```
> tcpdump -vvvi br-lan port 443 | grep bitbucket.org
> tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size
> 262144 bytes
> 192.168.2.168.54440 > bitbucket.org.443: Flags [S], cksum 0xb3a3
> (correct), seq 2816225641, win 29200, options [mss 1460,sackOK,TS val
> 15744661 ecr 0,nop,wscale 7], length 0 bitbucket.org.443 >
> 192.168.2.168.54440: Flags [S.], cksum 0x5c8d (correct), seq
> 1149625734, ack 2816225642, win 26847, options [mss 1460,sackOK,TS val
> 4256708721 ecr 15744661,nop,wscale 7], length 0 192.168.2.168.54440 >
> bitbucket.org.443: Flags [.], cksum 0xf33d (correct), seq 1, ack 1, win
> 229, options [nop,nop,TS val 15744683 ecr 4256708721], length 0
> 192.168.2.168.54440 > bitbucket.org.443: Flags [P.], cksum 0x58a5
> (correct), seq 1:221, ack 1, win 229, options [nop,nop,TS val 15744684
> ecr 4256708721], length 220 bitbucket.org.443 > 192.168.2.168.54440:
> Flags [.], cksum 0xf211 (correct), seq 1, ack 221, win 219, options
> [nop,nop,TS val 4256708810 ecr 15744684], length 0 bitbucket.org.443 >
> 192.168.2.168.54440: Flags [P.], cksum 0x9998 (correct), seq 2897:3668,
> ack 221, win 219, options [nop,nop,TS val 4256708810 ecr 15744684],
> length 771 192.168.2.168.54440 > bitbucket.org.443: Flags [.], cksum
> 0x4e08 (correct), seq 221, ack 1, win 251, options [nop,nop,TS val
> 15744705 ecr 4256708810,nop,nop,sack 1 {2897:3668}], length 0 ```
>
> Of course doing a wget from the router itself works fine as it also
> works fine on my desktop if I do dynamic port-forwarding with eg. `ssh
> -D 1050 router` (and configure of course firefox to use it).
>
> I m not sure what might be wrong here tbh. Of course other (most) sites
> work fine without dynamic forwarding or anything.
>
> I am attaching the output of `iptables --list-rules` for whoever is
> patient enough to read.
>
> Any help would be appreciated.
>
Are you still seeing the error if you do:
$ /etc/init.d/firewall stop
WARNING: You will not have any firewall protection if you do that
Is the issue still manifesting itself if the configuration is reset to
factory default?
This is a Debian mailing list, you might be better off on the OpenWrt forum.
--
John Doe
iptables firewall and web sites not loading
Hello,
I am running an iptables firewall on an openwrt router I ve got. Which
acts as Firewall/gateway and performs NATing for my internal network -
debian PCs and android phones.
All good but specific web sites are not loading for the machines that
are sitting behind the home router.
When attempting on the browser (firefox but tried different ones) the
browser stays at `Performing a TLS handshake to bitbucket.org`. wget has
similar results:
```
wget https://bitbucket.org
--2019-12-09 22:07:32-- https://bitbucket.org/
Resolving bitbucket.org (bitbucket.org)... 18.205.93.0, 18.205.93.1,
18.205.93.2, ... Connecting to bitbucket.org
(bitbucket.org)|18.205.93.0|:443... connected.
```
When doing a tcpdump on the router side I can see some initial TCP
session establishment and then nothing:
```
tcpdump -vvvi br-lan port 443 | grep bitbucket.org
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size
262144 bytes
192.168.2.168.54440 > bitbucket.org.443: Flags [S], cksum 0xb3a3
(correct), seq 2816225641, win 29200, options [mss 1460,sackOK,TS val
15744661 ecr 0,nop,wscale 7], length 0 bitbucket.org.443 >
192.168.2.168.54440: Flags [S.], cksum 0x5c8d (correct), seq
1149625734, ack 2816225642, win 26847, options [mss 1460,sackOK,TS val
4256708721 ecr 15744661,nop,wscale 7], length 0 192.168.2.168.54440 >
bitbucket.org.443: Flags [.], cksum 0xf33d (correct), seq 1, ack 1, win
229, options [nop,nop,TS val 15744683 ecr 4256708721], length 0
192.168.2.168.54440 > bitbucket.org.443: Flags [P.], cksum 0x58a5
(correct), seq 1:221, ack 1, win 229, options [nop,nop,TS val 15744684
ecr 4256708721], length 220 bitbucket.org.443 > 192.168.2.168.54440:
Flags [.], cksum 0xf211 (correct), seq 1, ack 221, win 219, options
[nop,nop,TS val 4256708810 ecr 15744684], length 0 bitbucket.org.443 >
192.168.2.168.54440: Flags [P.], cksum 0x9998 (correct), seq 2897:3668,
ack 221, win 219, options [nop,nop,TS val 4256708810 ecr 15744684],
length 771 192.168.2.168.54440 > bitbucket.org.443: Flags [.], cksum
0x4e08 (correct), seq 221, ack 1, win 251, options [nop,nop,TS val
15744705 ecr 4256708810,nop,nop,sack 1 {2897:3668}], length 0 ```
Of course doing a wget from the router itself works fine as it also
works fine on my desktop if I do dynamic port-forwarding with eg. `ssh
-D 1050 router` (and configure of course firefox to use it).
I m not sure what might be wrong here tbh. Of course other (most) sites
work fine without dynamic forwarding or anything.
I am attaching the output of `iptables --list-rules` for whoever is
patient enough to read.
Any help would be appreciated.
--
Regards,
Nektarios Katakis
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N forwarding_dmz_rule
-N forwarding_lan_rule
-N forwarding_rule
-N forwarding_wan_rule
-N input_dmz_rule
-N input_lan_rule
-N input_rule
-N input_wan_rule
-N output_dmz_rule
-N output_lan_rule
-N output_rule
-N output_wan_rule
-N reject
-N syn_flood
-N zone_dmz_dest_ACCEPT
-N zone_dmz_forward
-N zone_dmz_input
-N zone_dmz_output
-N zone_dmz_src_ACCEPT
-N zone_lan_dest_ACCEPT
-N zone_lan_forward
-N zone_lan_input
-N zone_lan_output
-N zone_lan_src_ACCEPT
-N zone_wan_dest_ACCEPT
-N zone_wan_dest_REJECT
-N zone_wan_forward
-N zone_wan_input
-N zone_wan_output
-N zone_wan_src_REJECT
-A INPUT -i lo -m comment --comment "!fw3" -j ACCEPT
-A INPUT -m comment --comment "!fw3: Custom input rule chain" -j input_rule
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3"
-j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m comment --comment
"!fw3" -j syn_flood
-A INPUT -i br-lan -m comment --comment "!fw3" -j zone_lan_input
-A INPUT -i pppoe-wan -m comment --comment "!fw3" -j zone_wan_input
-A INPUT -i br-dmz -m comment --comment "!fw3" -j zone_dmz_input
-A FORWARD -m comment --comment "!fw3: Custom forwarding rule chain" -j
forwarding_rule
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment
"!fw3" -j ACCEPT
-A FORWARD -i br-lan -m comment --comment "!fw3" -j zone_lan_forward
-A FORWARD -i pppoe-wan -m comment --comment "!fw3" -j zone_wan_forward
-A FORWARD -i br-dmz -m comment --comment "!fw3" -j zone_dmz_forward
-A OUTPUT -o lo -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -m comment --comment "!fw3: Custom output rule chain" -j output_rule
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment
"!fw3" -j ACCEPT
-A OUTPUT -o br-lan -m comment --comment "!fw3" -j zone_lan_output
-A OUTPUT -o pppoe-wan -m comment --comment "!fw3" -j zone_wan_output
-A OUTPUT -o br-dmz -m comment --comment "!fw3" -j zone_dmz_output
-A reject -p tcp -m comment --comment "!fw3" -j REJECT --reject-with tcp-reset
-A reject -m comment --comment "!fw3" -j REJECT --reject-with
icmp-port-un
Re: Iptables at boot, was fail2ban for apache2
On Monday 02 December 2019 07:46:22 Alessandro Vesely wrote: > On Mon 02/Dec/2019 10:35:26 +0100 Andrei POPESCU wrote: > > You might want to install iptables-persistent, otherwise you'll have > > to roll-out your own solution. > > I'm not using iptables-persistent, but just looked at it out of > curiosity. > > Its LSB: > > ### BEGIN INIT INFO > # Provides: netfilter-persistent > # Required-Start:mountkernfs $remote_fs > # Required-Stop: $remote_fs > # Default-Start: S > # Default-Stop: 0 1 6 > # Short-Description: Load boot-time netfilter configuration > # Description: Loads boot-time netfilter configuration > ### END INIT INFO > > S also starts in single-user mode, i.e. without network? > > $remote_fs requires ip links to be already set up? > > Stop, for good measure, does nothing. The comment in the script is > crisply nice: > > stop) > # Why? because if stop is used, the firewall gets flushed for a > variable # amount of time during package upgrades, leaving the machine > vulnerable # It's also not always desirable to flush during purge > echo "Automatic flushing disabled, use \"flush\" instead of > \"stop\"" ;; > > > In the particular case of iptables instead of writing a script you > > should probably just reuse your existing rules file and load that > > with an 'iptables-restore' from the .service unit. > > That's somewhat questionable in some cases. I'd recommend to write a > script with iptables commands rather than interactively issue iptables > command until you are satisfied with the current setup. That's > natural, since iptables doesn't give a visual feedback, so reasoning > is your best friend. IOW, a commented script is more readable than an > interactive setup. > > Then, since you have a script, why not run it directly, rather than > saving/restoring its results? Since I had spent a week battling the bots, and doing a new save for every addition, I find the iptables-restore both starts it and restores it. Good enough till I get a new machine built, by the weekend I hope. > > We are quite far from the original topic so I would suggest you > > start a new thread in case you need assistance with this. > > I try, but don't reset References:/In-Reply-To: header fields. And kmail doesn't make that easy. > > Best > Ale Thanks Alessandro. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
Re: Iptables at boot, was fail2ban for apache2
On Mon, Dec 02, 2019 at 01:46:22PM +0100, Alessandro Vesely wrote: > ### BEGIN INIT INFO > # Provides: netfilter-persistent > # Required-Start:mountkernfs $remote_fs > # Required-Stop: $remote_fs > # Default-Start: S > # Default-Stop: 0 1 6 > # Short-Description: Load boot-time netfilter configuration > # Description: Loads boot-time netfilter configuration > ### END INIT INFO > > S also starts in single-user mode, i.e. without network? I believe single-user mode starts the network. It may not start all of the network services, of course.
Re: Iptables at boot, was fail2ban for apache2
On Mon, Dec 02, 2019 at 01:46:22PM +0100, Alessandro Vesely wrote:
> On Mon 02/Dec/2019 10:35:26 +0100 Andrei POPESCU wrote:
> >
> > You might want to install iptables-persistent, otherwise you'll have to
> > roll-out your own solution.
>
> I'm not using iptables-persistent, but just looked at it out of curiosity.
>
> Its LSB:
>
> ### BEGIN INIT INFO
> # Provides: netfilter-persistent
> # Required-Start:mountkernfs $remote_fs
> # Required-Stop: $remote_fs
> # Default-Start: S
> # Default-Stop: 0 1 6
> # Short-Description: Load boot-time netfilter configuration
> # Description: Loads boot-time netfilter configuration
> ### END INIT INFO
>
> S also starts in single-user mode, i.e. without network?
And Default-Stop value prevents it from running in single-user.
Besides, unless one does something really stupid (like using hostnames
in netfilter rules) - what's wrong with netfilter rules loaded at
runlevel 1?
You can load a rule that processes packet on non-existent interface, for
instance.
> $remote_fs requires ip links to be already set up?
mountkernfs is more problematic here. Presumably it's for NFS-root
configuration.
> > In the particular case of iptables instead of writing a script you
> > should probably just reuse your existing rules file and load that with
> > an 'iptables-restore' from the .service unit.
>
>
> That's somewhat questionable in some cases. I'd recommend to write a script
> with iptables commands rather than interactively issue iptables command until
> you are satisfied with the current setup. That's natural, since iptables
> doesn't give a visual feedback, so reasoning is your best friend. IOW, a
> commented script is more readable than an interactive setup.
"-m comment" anyone?
Personally I see little value in this package. There are cases that
require modifying netfilter rules ad-hoc, saving those at system reboot
can lead to undesirable side-effects. My solution to those is the (ab)use
of /etc/network/interfaces:
auto lo
iface lo inet loopback
up /sbin/iptables-restore < /etc/network/iptables.rules
up /sbin/ip6tables-restore < /etc/network/ip6tables.rules
Because I have no problem in running "iptables-save >
/etc/network/iptables.rules" then the need arises.
Reco
Iptables at boot, was fail2ban for apache2
On Mon 02/Dec/2019 10:35:26 +0100 Andrei POPESCU wrote: > > You might want to install iptables-persistent, otherwise you'll have to > roll-out your own solution. I'm not using iptables-persistent, but just looked at it out of curiosity. Its LSB: ### BEGIN INIT INFO # Provides: netfilter-persistent # Required-Start:mountkernfs $remote_fs # Required-Stop: $remote_fs # Default-Start: S # Default-Stop: 0 1 6 # Short-Description: Load boot-time netfilter configuration # Description: Loads boot-time netfilter configuration ### END INIT INFO S also starts in single-user mode, i.e. without network? $remote_fs requires ip links to be already set up? Stop, for good measure, does nothing. The comment in the script is crisply nice: stop) # Why? because if stop is used, the firewall gets flushed for a variable # amount of time during package upgrades, leaving the machine vulnerable # It's also not always desirable to flush during purge echo "Automatic flushing disabled, use \"flush\" instead of \"stop\"" ;; > In the particular case of iptables instead of writing a script you > should probably just reuse your existing rules file and load that with > an 'iptables-restore' from the .service unit. That's somewhat questionable in some cases. I'd recommend to write a script with iptables commands rather than interactively issue iptables command until you are satisfied with the current setup. That's natural, since iptables doesn't give a visual feedback, so reasoning is your best friend. IOW, a commented script is more readable than an interactive setup. Then, since you have a script, why not run it directly, rather than saving/restoring its results? > We are quite far from the original topic so I would suggest you start a > new thread in case you need assistance with this. I try, but don't reset References:/In-Reply-To: header fields. Best Ale signature.asc Description: OpenPGP digital signature
Re: was: fail2ban for apache2, now iptables help
On Monday 02 December 2019 04:35:26 Andrei POPESCU wrote: > On Du, 01 dec 19, 22:28:43, Gene Heskett wrote: > > It, iptables, did not get restarted on the fresh boot, so obviously > > the systemd manager hasn't been informed to start iptables, > > reloading from /etc/iptables/saved-rules. > > To my knowledge Debian doesn't include anything like this by default. > > > So 1. how do I query systemd to determine if it should have started > > iptables, and if not, 2. what is the command to set it so it does > > start iptables at bootup? > > You might want to install iptables-persistent, otherwise you'll have > to roll-out your own solution. > > With systemd the generic solution would look like: > > 1. Write a script that does what you want > 2. Write a corresponding .service unit describing how / when it's run > 3. Tell systemd to use your .service unit. > > In the particular case of iptables instead of writing a script you > should probably just reuse your existing rules file and load that with > an 'iptables-restore' from the .service unit. > > We are quite far from the original topic so I would suggest you start > a new thread in case you need assistance with this. > I did find the syntax for iptables-restore and have that working as I'd been doing a new iptables-save everytime I added a new rule. So I've got most of them muzzled again. But you're right, the thread has drifted as I looked for a solution for the DDOS I was suffering from. > Kind regards, > Andrei Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
Re: Is it a bug that the iptable_filter module isn't loaded automatically with Debian 10 iptables-nft?
Le 28/10/2019 à 09:14, Andy Smith a écrit : I will take a guess that the switching of the iptables commands to use the nftables framework has somehow caused this iptable_filter module to not be loaded even though the firewall still works. Correct. Is it a bug that loading rules into the filter table using iptables-nft command (actually called as "iptables" due to alternatives) no longer causes iptable_filter module to be loaded and thus "filter" to appear in /proc/net/ip_tables_names? No, it is expected. iptable_* modules and /proc/net/ip_tables_names are part of the iptables framework. But iptables-nft uses the nftables framework (by translating iptables rules into nftables rules). I understand that a management software using iptables may look up /proc/net/ip_tables_names to check whether a tables is active, for instance so that it can initialize or list it properly (initializing or listing an unused inactive table would needlessly activate it). Is there a different proc file that will list the active netfilter tables? There are no netfilter tables. Tables belong to frameworks running inside netfilter such as iptables and nftables. Is it safe for me to continue forcing the load of the iptable_file and ip6table_filter modules, or should I stop doing that and seek to get the management software fixed instead? Though doing that will need some other way to obtain the same information. > If it is bad to force load those modules, perhaps I should be using update-alternatives to go back to using iptables-legacy? Loading an iptables table makes it process packets needlessly. Also, some some iptables extensions are not supported by nftables compatibility layer. So yes, IMO you should go back to using iptables-legacy, even though I cannot think of any undesirable side effect beside performance when the chains are empty with policy ACCEPT. I am aware that we should be switching to nftables now IMO there is no hurry yet.
Is it a bug that the iptable_filter module isn't loaded automatically with Debian 10 iptables-nft?
Hi,
I noticed a few hours ago that a particular piece of firewall
management software wasn't working correctly with my Debian 10
hosts.
After quite a lot of investigation I worked out that the software in
question was looking at the content of /proc/net/ip_tables_names to
determine the names of the tables that are currently active
('filter', 'mangle', etc).
On my Debian 10 hosts, this file is empty even though they have
active rules loaded by iptables.
I then noticed that on my Debian 9 hosts, the modules iptable_filter
and ip6table_filter are loaded as soon as a rule is added to any of
the chains in the filter table ('INPUT', 'OUTPUT, 'FORWARD').
By manually loading the module iptable_filter on my Debian 10 hosts
I was able to populate the file /proc/net/ip_tables_names with the
active tables ('filter') and the management software works again. I
have for the moment made this change permanent by adding those
modules to a file in /etc/modules-load.d/.
I will take a guess that the switching of the iptables commands to
use the nftables framework has somehow caused this iptable_filter
module to not be loaded even though the firewall still works.
Is it a bug that loading rules into the filter table using
iptables-nft command (actually called as "iptables" due to
alternatives) no longer causes iptable_filter module to be loaded
and thus "filter" to appear in /proc/net/ip_tables_names?
Is there a different proc file that will list the active netfilter
tables?
Is it safe for me to continue forcing the load of the iptable_file
and ip6table_filter modules, or should I stop doing that and seek to
get the management software fixed instead? Though doing that will
need some other way to obtain the same information.
If it is bad to force load those modules, perhaps I should be using
update-alternatives to go back to using iptables-legacy?
I am aware that we should be switching to nftables now, but I have
quite a few servers all managed by config management. As I will need
to switch the method by which I manage the firewalling in the config
management, and don't want to run two different things
simultaneously, I was planning to wait until my oldest hosts have
been upgraded enough and then do them all at once. I don't really
want to starting rewriting the firewalls on older Debian 8 servers
when they should go away within a year anyway.
Cheers,
Andy
Re: iptables why rejects this output?
I figured out, the packet is INVALID. I have absolutly no idea how can it happen. 2019.10.07 23:29 keltezéssel, Reco írta: Hi. On Mon, Oct 07, 2019 at 10:55:53PM +0200, BAGI Ákos wrote: you mean I should make the firewall settings public? good idea :) If your security depends on obscurity, you do not have a security in the first place. Your INPUT rules can be probed. Your FORWARD rules aren't relevant to your problem. Your OUTPUT rules are, and they do nothing to protect you from the hostile Internet. So if you're asking why a certain iptables rule produces a certain kernel output - please provide the offending rule at least. Or better - full OUTPUT chain. Reco
Re: iptables why rejects this output?
Hi. On Mon, Oct 07, 2019 at 10:55:53PM +0200, BAGI Ákos wrote: > you mean I should make the firewall settings public? > good idea :) If your security depends on obscurity, you do not have a security in the first place. Your INPUT rules can be probed. Your FORWARD rules aren't relevant to your problem. Your OUTPUT rules are, and they do nothing to protect you from the hostile Internet. So if you're asking why a certain iptables rule produces a certain kernel output - please provide the offending rule at least. Or better - full OUTPUT chain. Reco
Re: iptables why rejects this output?
you mean I should make the firewall settings public? good idea :) 2019.10.05 12:32 keltezéssel, deloptes írta: BAGI Ákos wrote: How can I enable it with iptables? (I have lot of iptables rules). Is it ok, to enable it? without the iptables rules it is hard to tell - post the rules (iptables-save)
Re: iptables why rejects this output?
BAGI Ákos wrote: > How can I enable it with iptables? (I have lot of iptables rules). > Is it ok, to enable it? without the iptables rules it is hard to tell - post the rules (iptables-save)
iptables why rejects this output?
Hi List! This is in the log: Oct 4 22:28:37 atilla kernel: [15888959.848503] IPTABLES OUTPUT reject IN= OUT=eth0 SRC=aa.bb.bb.dd DST=ee.ff.gg.hh LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=4940 DF PROTO=TCP SPT=443 DPT=53983 WINDOW=237 RES=0x00 ACK FIN URGP=0 I'm interested the ending: WINDOW=237 RES=0x00 ACK FIN URGP=0 The client is logged in and communicates fine with the apache server with ssl. However sometimes come such log entries. What does this entry mean? What is not enabled if all responses are enabled (ESTABLISHED, RELATED) How can I enable it with iptables? (I have lot of iptables rules). Is it ok, to enable it? Thx: A
Re: which one is executed first ip_forward=1 or iptables FORWARD Drop
On Thu, Jun 13, 2019 at 10:06:30AM +0100, BELAHCENE Abdelkader wrote: > Hi, > I am using one machine, say SERV, as a gateway ( cards eth0, eth1) from > network1 to network2, I want to forward all packets but tcp port 80 so > I used > *sysctl -w net.ipv4.ip_forward=1* This just enables the forward mechanism in the kernel > > *I want to drop port 80, and accept others port* > > *I tryed* > > *iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 80 -j DROP* It doesn't forward anything. Are these all rules you have? Please post the output of iptables -L Also are network1 and network2 routable? Or do you try a NAT setup? > > *but not ran* what does that even mean? Does that mean it was not working? Technically it does, it just doesn't do what you want it to do. > > *Thanks for help* > *regards* and your "*" key is stuck ;) -H -- Henning Follmann | hfollm...@itcfollmann.com
which one is executed first ip_forward=1 or iptables FORWARD Drop
Hi, I am using one machine, say SERV, as a gateway ( cards eth0, eth1) from network1 to network2, I want to forward all packets but tcp port 80 so I used *sysctl -w net.ipv4.ip_forward=1* *I want to drop port 80, and accept others port* *I tryed* *iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 80 -j DROP* *but not ran* *Thanks for help* *regards*
Re: geoip and iptables
On 3/19/2019 8:54 AM, lists wrote: > Hi, > > In the past, we achieved this following this page: > How are you doing it now? > http://blog.jeshurun.ca/technology/block-countries-ubuntu-iptables-xtables-geoip > The above URL describes what apparently 'geoip-database-contrib' does, looks like I'll have to cooked something up! :) Thanks. -- John Doe
Re: geoip and iptables
Hi, In the past, we achieved this following this page: http://blog.jeshurun.ca/technology/block-countries-ubuntu-iptables-xtables-geoip Perhaps it helps you too. MJ On 19-3-2019 7:54, john doe wrote: Hi, I want to use geoip with iptables. I have installed the package 'geoip-database-extra' and it allows me to use the 'geoiplookup' utility. From what I understand, iptables requires the directory '/usr/share/xt_geoip' to be populated. What debian package(s) do I need to install that is not 'non-free' 'or contrib' to get that directory populated I can do it manually (1) but I would prefer a debian package. In other words: how do I let iptables use the geoip database provided by debian. Any help is welcome. 1) http://xtables-addons.sourceforge.net/geoip.php -- John Doe
geoip and iptables
Hi, I want to use geoip with iptables. I have installed the package 'geoip-database-extra' and it allows me to use the 'geoiplookup' utility. From what I understand, iptables requires the directory '/usr/share/xt_geoip' to be populated. What debian package(s) do I need to install that is not 'non-free' 'or contrib' to get that directory populated I can do it manually (1) but I would prefer a debian package. In other words: how do I let iptables use the geoip database provided by debian. Any help is welcome. 1) http://xtables-addons.sourceforge.net/geoip.php -- John Doe
Re: iptables issue with ASP.Net Core Port 5000
On Wed, 13 Feb 2019 11:30 pm Igor Cicimov On Wed, 13 Feb 2019 9:44 pm Patrick Kirk
>> Hi all,
>>
>> I have a simple asp.net core site that runs with Postgres which works
>> fine if I login as root and set it to run on port 80. SSL is done by
>> cloudflare. I would prefer to use nginx or at least have an iptable
>> rule to redirect the port 80 traffic. Both have the same failure so for
>> now I am trying with iptables.
>>
>> I don't believe this is an issue with asp.net but the line I use to set
>> ports is:
>>
>> public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
>> WebHost.CreateDefaultBuilder(args).UseUrls("http://localhost:5000";,
>> "http://*:80";)
>> .UseStartup();
>>
>> To run the program on port 80, I have to run as root which I want to get
>> away from. So I remove the port 80 from Program.cs and then run the
>> program. Output of nmap is:
>>
>> Starting Nmap 7.40 ( https://nmap.org ) at 2019-02-13 10:35 UTC
>> Nmap scan report for localhost (127.0.0.1)
>> Host is up (0.0000080s latency).
>> Not shown: 997 closed ports
>> PORT STATE SERVICE
>> 22/tcp open ssh
>> 5000/tcp open upnp
>> 5432/tcp open postgresql
>>
>> If I try the iptables route the command I use is:
>>
>> iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port
>> 5000
>>
>> This works fine for Lynx http://localhost but for my url I get
>>
>> "Alert!: HTTP/1.1 521 Origin Down"
>>
>> If I try to use nginx, which I believe is configured correctly, I get
>> the exact same issue.
>>
>> Has anyone any idea what's wrong with my setup?
>>
>> Patrick
>
>
Actually for routing to the localhost interface you need this one:
$ sudo sysctl -w net.ipv4.conf.eth0.route_localnet=1
assuming eth0 is your interface receiving the traffic.
>
Re: iptables issue with ASP.Net Core Port 5000
Le 2019-02-13 11:43, Patrick Kirk a écrit :
Hi all,
I have a simple asp.net core site that runs with Postgres which works
fine if I login as root and set it to run on port 80. SSL is done by
cloudflare. I would prefer to use nginx or at least have an iptable
rule to redirect the port 80 traffic. Both have the same failure so
for now I am trying with iptables.
I don't believe this is an issue with asp.net but the line I use to
set ports is:
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args).UseUrls("http://localhost:5000";,
"http://*:80";)
.UseStartup();
To run the program on port 80, I have to run as root which I want to
get away from. So I remove the port 80 from Program.cs and then run
the program. Output of nmap is:
Starting Nmap 7.40 ( https://nmap.org ) at 2019-02-13 10:35 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.080s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
5000/tcp open upnp
5432/tcp open postgresql
If I try the iptables route the command I use is:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port
5000
This works fine for Lynx http://localhost but for my url I get
"Alert!: HTTP/1.1 521 Origin Down"
If I try to use nginx, which I believe is configured correctly, I get
the exact same issue.
Has anyone any idea what's wrong with my setup?
Patrick
Hello,
Did you want ASP.net and apache or nginx to use the same 80 port ?
Regards,
Re: iptables issue with ASP.Net Core Port 5000
On Wed, 13 Feb 2019 9:44 pm Patrick Kirk Hi all,
>
> I have a simple asp.net core site that runs with Postgres which works
> fine if I login as root and set it to run on port 80. SSL is done by
> cloudflare. I would prefer to use nginx or at least have an iptable
> rule to redirect the port 80 traffic. Both have the same failure so for
> now I am trying with iptables.
>
> I don't believe this is an issue with asp.net but the line I use to set
> ports is:
>
> public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
> WebHost.CreateDefaultBuilder(args).UseUrls("http://localhost:5000";,
> "http://*:80";)
> .UseStartup();
>
> To run the program on port 80, I have to run as root which I want to get
> away from. So I remove the port 80 from Program.cs and then run the
> program. Output of nmap is:
>
> Starting Nmap 7.40 ( https://nmap.org ) at 2019-02-13 10:35 UTC
> Nmap scan report for localhost (127.0.0.1)
> Host is up (0.080s latency).
> Not shown: 997 closed ports
> PORT STATE SERVICE
> 22/tcp open ssh
> 5000/tcp open upnp
> 5432/tcp open postgresql
>
> If I try the iptables route the command I use is:
>
> iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port
> 5000
>
> This works fine for Lynx http://localhost but for my url I get
>
> "Alert!: HTTP/1.1 521 Origin Down"
>
> If I try to use nginx, which I believe is configured correctly, I get
> the exact same issue.
>
> Has anyone any idea what's wrong with my setup?
>
> Patrick
Run:
$ sudo sysctl -w net.ipv4.ip_forward=1
iptables issue with ASP.Net Core Port 5000
Hi all,
I have a simple asp.net core site that runs with Postgres which works
fine if I login as root and set it to run on port 80. SSL is done by
cloudflare. I would prefer to use nginx or at least have an iptable
rule to redirect the port 80 traffic. Both have the same failure so for
now I am trying with iptables.
I don't believe this is an issue with asp.net but the line I use to set
ports is:
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args).UseUrls("http://localhost:5000";,
"http://*:80";)
.UseStartup();
To run the program on port 80, I have to run as root which I want to get
away from. So I remove the port 80 from Program.cs and then run the
program. Output of nmap is:
Starting Nmap 7.40 ( https://nmap.org ) at 2019-02-13 10:35 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.080s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
5000/tcp open upnp
5432/tcp open postgresql
If I try the iptables route the command I use is:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 5000
This works fine for Lynx http://localhost but for my url I get
"Alert!: HTTP/1.1 521 Origin Down"
If I try to use nginx, which I believe is configured correctly, I get
the exact same issue.
Has anyone any idea what's wrong with my setup?
Patrick
Re: iptables config resets after restarting system
Le 10/08/2018 à 22:29, Hubert Hauser a écrit :
echo " * allowing ping responses"
${IPTABLES} -A INPUT -p ICMP -j ACCEPT
${IP6TABLES} -A INPUT -p ICMPv6 -j ACCEPT
Replies to unicast echo requests have the ESTABLISHED state. So you
don't need an extra rule to accept them, unless you are sending echo
requests to broadcast or anycast addresses.
Besides, theses rules accept not accept echo-reply but also ANY ICMP or
ICMPv6 type, including echo-request.
echo -e " * SAVING RULES\n"
iptables-save > /etc/iptables/rules.v4
iptables-apply /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6
ip6tables-apply /etc/iptables/rules.v6
echo -e "\n * DONE!\n"
Here's my iptables config before restarting system:
(...)
And after restarting system:
(a few differences)
Running command fwall-rules after restarting system works. What am I
doing wrong?
How do yo restore the ruleset at startup ?
Are you using the same file ?
Re: iptables config resets after restarting system
On 08/11/2018 05:29 AM, Hubert Hauser wrote:
> Good afternoon!
>
> I've problem with resetting iptables after restarting system. Here's my
> /usr/local/bin/fwall-rules file:
>
> Running command fwall-rules after restarting system works. What am I
> doing wrong?
>
> --
> Best regards,
> Hubert Hauser.
>
It seems the firewalls before and after are what you want, according to
your script? There are a few minor differences, but those are the rules
that you specify in the script.
If you're talking about the iptables rules disappearing on reboot,
that's just how iptables works. You need to restore the iptables rules
on every reboot.
There are a few ways to do this. The easiest way would be to install the
iptables-persistent package, which will handle restoring
(ip(6)tables-restore /etc/iptables/rules.v{4,6}) at boot time, or you
could follow the instructions here
<https://wiki.debian.org/iptables#Storing_iptables_rules_in_a_file>.
Also, a few notes about your script:
iptables-save dumps out the current iptables rules into a file.
iptables-apply applies the dump, but in your script, since the rules
have already been set in iptables, there is no need to run
iptables-{apply,restore}.
You probably don't need to maintain a separate script. I'd just maintain
/etc/iptables/rules.v{4,6} and have it be restored by iptables-restore.
That way, I can avoid having to maintain a separate script every time I
want to change my firewall rules.
iptables-apply is used to apply some rules file, then wait for user
confirmation. This makes sure that if your rules block you out of your
ssh session or similar, you don't accidentally make the machine
unreachable by you. In your case, since the rules have already been
applied (you added them in the script), iptables-apply will "undo" the
apply to the previous state, which is already problematic. So there is
no point to using iptables-apply here, since the rules are already
inside iptables.
iptables config resets after restarting system
Good afternoon!
I've problem with resetting iptables after restarting system. Here's my
/usr/local/bin/fwall-rules file:
#!/bin/bash
IPTABLES=/sbin/iptables
IP6TABLES=/sbin/ip6tables
echo -e "\n ** clean rules ** \n"
echo " * flushing old rules"
${IPTABLES} --flush
${IPTABLES} --delete-chain
${IPTABLES} --table nat --flush
${IPTABLES} --table nat --delete-chain
${IP6TABLES} --flush
${IP6TABLES} --delete-chain
${IP6TABLES} --table nat --flush
${IP6TABLES} --table nat --delete-chain
echo " * setting default policies"
${IPTABLES} -P INPUT DROP
${IPTABLES} -P FORWARD DROP
${IPTABLES} -P OUTPUT ACCEPT
${IP6TABLES} -P INPUT DROP
${IP6TABLES} -P FORWARD DROP
${IP6TABLES} -P OUTPUT ACCEPT
echo -e "\n ** input chain rules ** \n"
echo " * allowing loopback devices"
${IPTABLES} -A INPUT -i lo -j ACCEPT
${IPTABLES} -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
${IPTABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
${IP6TABLES} -A INPUT -i lo -j ACCEPT
${IP6TABLES} -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
${IP6TABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
## BLOCK ABUSING IPs HERE ##
#echo " * BLACKLIST"
#${IPTABLES} -A INPUT -s _ABUSIVE_IP_ -j DROP
#${IPTABLES} -A INPUT -s _ABUSIVE_IP2_ -j DROP
echo " * allowing ssh on port 16960"
${IPTABLES} -A INPUT -p tcp --dport 16960 -m state --state NEW -j ACCEPT
${IP6TABLES} -A INPUT -p tcp --dport 16960 -m state --state NEW -j ACCEPT
#echo " * allowing ftp on port 21"
#${IPTABLES} -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT
echo " * allowing dns on port 53 udp"
${IPTABLES} -A INPUT -p udp -m udp --dport 53 -j ACCEPT
${IP6TABLES} -A INPUT -p udp -m udp --dport 53 -j ACCEPT
echo " * allowing dns on port 53 tcp"
${IPTABLES} -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
${IP6TABLES} -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
echo " * allowing http on port 80"
${IPTABLES} -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
${IP6TABLES} -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
echo " * allowing https on port 443"
${IPTABLES} -A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
${IP6TABLES} -A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
echo " * allowing smtp on port 25"
${IPTABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
${IP6TABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j
ACCEPT
echo " * allowing smtps on port 465"
${IPTABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 465 -j
ACCEPT
${IP6TABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 465 -j
ACCEPT
echo " * allowing submission on port 587"
${IPTABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 587 -j
ACCEPT
${IP6TABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 587 -j
ACCEPT
echo " * allowing imaps on port 993"
${IPTABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 993 -j
ACCEPT
${IP6TABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 993 -j
ACCEPT
echo " * allowing pop3s on port 995"
${IPTABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 995 -j
ACCEPT
${IP6TABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 995 -j
ACCEPT
echo " * allowing imap on port 143"
${IPTABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 143 -j
ACCEPT
${IP6TABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 143 -j
ACCEPT
echo " * allowing pop3 on port 110"
${IPTABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 110 -j
ACCEPT
${IP6TABLES} -A INPUT -p tcp -m state --state NEW -m tcp --dport 110 -j
ACCEPT
echo " * allowing ping responses"
${IPTABLES} -A INPUT -p ICMP -j ACCEPT
${IP6TABLES} -A INPUT -p ICMPv6 -j ACCEPT
# DROP everything else and Log it
${IPTABLES} -A INPUT -j LOG --log-prefix "iptables-reject "
${IPTABLES} -A INPUT -j REJECT --reject-with icmp-host-prohibited
${IP6TABLES} -A INPUT -j LOG --log-prefix "ip6tables-reject "
${IP6TABLES} -A INPUT -j REJECT --reject-with icmp6-adm-prohibited
#
# Save settings
#
echo -e " * SAVING RULES\n"
iptables-save > /etc/iptables/rules.v4
iptables-apply /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6
ip6tables-apply /etc/iptables/rules.v6
echo -e "\n * DONE!\n"
Here's my iptables config before restarting system:
# iptables-save
# Generated by iptables-save v1.6.0 on Fri Aug 10 22:24:06 2018
*nat
:PREROUTING ACCEPT [893:55496]
:INPUT ACCEPT [31:1408]
:OUTPUT ACCEPT [118:7908]
:POSTROUTING ACCEPT [118:7908]
COMMIT
# Completed on Fri Aug 10 22:24:06 2018
# Generated by iptables-save v1.6.0 on Fri Aug 10 22:24:06 2018
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [7920:1029798]
:f2b-nginx-botsearch - [0:0]
:f2b-nginx-http-auth - [0:0]
:
Re: iptables geoip not working after update to jessie
Hi, So, I removed xtables-addons-source: apt-get remove xtables-addons-source And reinstalled xtables-addons-dkms: apt-get install --reinstall xtables-addons-dkms That built the module, and things started working again. Thanks Reco! On 9-5-2018 10:38, Reco wrote: Hi. On Wed, May 09, 2018 at 08:37:52AM +0200, mj wrote: Hi, Yesterday I upgraded a server from wheezy to jessie. Went fine, with one exception: my geoip iptables rules no longer work: root@jessie:~# iptables -A INPUT -m geoip --src-cc RU -j DROP iptables: No chain/target/match by that name. This machine was originaly wheezy, and at that time, I installed the geo ip, according to my notes, like this: apt-get install xtables-addons-common libtext-csv-xs-perl That's not enough. 'apt show xtables-addons-common' says: Note: this package is only useful with a corresponding xtables-addons-dkms package, which you may produce with module-assistant: module-assistant auto-install xtables-addons-source Either install "xtables-addons-dkms" (which should build missing kernel modules by itself), or "xtables-addons-source" (and use module-assistant then). Reco
Re: iptables geoip not working after update to jessie
Hi Reco, Thanks for your reply. Holidays here now, I will try your suggestions next week, and report back then. Thanks! MJ On 05/09/2018 10:38 AM, Reco wrote: Hi. On Wed, May 09, 2018 at 08:37:52AM +0200, mj wrote: Hi, Yesterday I upgraded a server from wheezy to jessie. Went fine, with one exception: my geoip iptables rules no longer work: root@jessie:~# iptables -A INPUT -m geoip --src-cc RU -j DROP iptables: No chain/target/match by that name. This machine was originaly wheezy, and at that time, I installed the geo ip, according to my notes, like this: apt-get install xtables-addons-common libtext-csv-xs-perl That's not enough. 'apt show xtables-addons-common' says: Note: this package is only useful with a corresponding xtables-addons-dkms package, which you may produce with module-assistant: module-assistant auto-install xtables-addons-source Either install "xtables-addons-dkms" (which should build missing kernel modules by itself), or "xtables-addons-source" (and use module-assistant then). Reco
Re: iptables geoip not working after update to jessie
Hi. On Wed, May 09, 2018 at 08:37:52AM +0200, mj wrote: > Hi, > > Yesterday I upgraded a server from wheezy to jessie. Went fine, with one > exception: my geoip iptables rules no longer work: > > > root@jessie:~# iptables -A INPUT -m geoip --src-cc RU -j DROP > > iptables: No chain/target/match by that name. > > This machine was originaly wheezy, and at that time, I installed the geo ip, > according to my notes, like this: > > > apt-get install xtables-addons-common libtext-csv-xs-perl That's not enough. 'apt show xtables-addons-common' says: Note: this package is only useful with a corresponding xtables-addons-dkms package, which you may produce with module-assistant: module-assistant auto-install xtables-addons-source Either install "xtables-addons-dkms" (which should build missing kernel modules by itself), or "xtables-addons-source" (and use module-assistant then). Reco
iptables geoip not working after update to jessie
Hi, Yesterday I upgraded a server from wheezy to jessie. Went fine, with one exception: my geoip iptables rules no longer work: root@jessie:~# iptables -A INPUT -m geoip --src-cc RU -j DROP iptables: No chain/target/match by that name. This machine was originaly wheezy, and at that time, I installed the geo ip, according to my notes, like this: apt-get install xtables-addons-common libtext-csv-xs-perl and cd /tmp/geoip /usr/lib/xtables-addons/xt_geoip_dl mkdir /usr/share/xt_geoip /usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip *.csv This worked in wheezy, but alas after the upgrade it stopped. :-( Iptables still seems to know about geoip, because "iptables -m geoip --help" still lists the geoip match options: geoip match options: [!] --src-cc, --source-country country[,country...] Match packet coming from (one of) the specified country(ies) [!] --dst-cc, --destination-country country[,country...] Match packet going to (one of) the specified country(ies) NOTE: The country is inputed by its ISO3166 code. As I really need to block some countries, I would very much appreciate any assistance here. This post describes exactly my issue: https://bbs.archlinux.org/viewtopic.php?id=195565 root@jessie:~# modprobe xt_geoip modprobe: FATAL: Module xt_geoip not found. But the fix from the post (depmod -a) doesn't help us at all. No output, no difference. Could someone help me out? Best regards, MJ FYI: root@jessie:~# modprobe -c | grep x_tab alias symbol:xt_alloc_entry_offsets x_tables alias symbol:xt_alloc_table_info x_tables alias symbol:xt_check_entry_offsets x_tables alias symbol:xt_check_match x_tables alias symbol:xt_check_target x_tables alias symbol:xt_compat_add_offset x_tables alias symbol:xt_compat_calc_jump x_tables alias symbol:xt_compat_check_entry_offsets x_tables alias symbol:xt_compat_flush_offsets x_tables alias symbol:xt_compat_init_offsets x_tables alias symbol:xt_compat_lock x_tables alias symbol:xt_compat_match_from_user x_tables alias symbol:xt_compat_match_offset x_tables alias symbol:xt_compat_match_to_user x_tables alias symbol:xt_compat_target_from_user x_tables alias symbol:xt_compat_target_offset x_tables alias symbol:xt_compat_target_to_user x_tables alias symbol:xt_compat_unlock x_tables alias symbol:xt_copy_counters_from_user x_tables alias symbol:xt_find_jump_offset x_tables alias symbol:xt_find_match x_tables alias symbol:xt_find_revision x_tables alias symbol:xt_find_table_lock x_tables alias symbol:xt_find_target x_tables alias symbol:xt_free_table_info x_tables alias symbol:xt_hook_link x_tables alias symbol:xt_hook_unlink x_tables alias symbol:xt_proto_fini x_tables alias symbol:xt_proto_init x_tables alias symbol:xt_recseq x_tables alias symbol:xt_register_match x_tables alias symbol:xt_register_matches x_tables alias symbol:xt_register_table x_tables alias symbol:xt_register_target x_tables alias symbol:xt_register_targets x_tables alias symbol:xt_replace_table x_tables alias symbol:xt_request_find_match x_tables alias symbol:xt_request_find_target x_tables alias symbol:xt_table_unlock x_tables alias symbol:xt_unregister_match x_tables alias symbol:xt_unregister_matches x_tables alias symbol:xt_unregister_table x_tables alias symbol:xt_unregister_target x_tables alias symbol:xt_unregister_targets x_tables
issue with iptables antispoofing rules in xen4.8
Hi all I have isses with the on domU startup automatically generated antispoofing rules by /etc/xen/scripts/vif-bridge and /etc/xen/scripts/vif-common.sh Both are part of the xen-utils-common package (4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 installed on Debian 9.4). A domU test01 has two virtual interfaces - vif-test01-INT and vif-test01-TEST, both are connected to separate bridges named brINT and brTEST. The brINT is just an internal bridge without connectivity to an outside network to just connect all domUs and the dom0. The IP addressfor the vif-test01-INT interface is 192.168.240.68. The automatically generated rules per domU are: 1 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out vif-test01-INT --physdev-is-bridged 2 ACCEPT udp -- anywhere anywhere PHYSDEV match --physdev-in vif-test01-INT --physdev-is-bridged udp spt:bootpc dpt:bootps 3 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out vif-test01-INT --physdev-is-bridged 4 ACCEPT all -- 192.168.240.68 anywhere PHYSDEV match --physdev-in vif-test01-INT --physdev-is-bridged 5 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out vif-test01-TEST --physdev-is-bridged 6 ACCEPT udp -- anywhere anywhere PHYSDEV match --physdev-in vif-test01-TEST --physdev-is-bridged udp spt:bootpc dpt:bootps 7 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out vif-test01-TEST --physdev-is-bridged 8 ACCEPT all -- test01 anywhere PHYSDEV match --physdev-in vif-test01-TEST --physdev-is-bridged ... 33 REJECT all -- anywhere anywhere reject-with icmp-port-unreachable >From what I see is that the rules 1/3 and 5/7 are doubled. The next issue is that antispoofing rules just don't work. If I change the ip adress of the vif-test01-INT interface to something like 192.168.240.168 IP packets between test01 and other domUs are still forwarded. If I manually change the iptables rules to something like (in this example just for the brINT connected interface): -A FORWARD -m physdev --physdev-is-bridged --physdev-in vif-test01-INT -p all ! -s 192.168.240.68 -j DROP -A FORWARD -m physdev --physdev-is-bridged --physdev-out vif-test01-INT -p all ! -d 192.168.240.68 -j DROP -A FORWARD -m physdev --physdev-is-bridged --physdev-in vif-test01-INT -p all -j ACCEPT -A FORWARD -m physdev --physdev-is-bridged --physdev-out vif-test01-INT -p all -j ACCEPT ... -A FORWARD -j REJECT --reject-with icmp-port-unreachable then antispoofing works and IP packets with IP addresses different then 192.168.240.68 get dropped. Can somebody confirm this is an issue? Or do I just not understand how the antispoofing rules work on a virtual bridge? Is there a way to diable generation of antispoofing rules automatically on domU startup? I could configure a different vif.default.script in xl.conf and write a wrapper script, but it might be easier to just disable it and load iptables rules manually. -- Cheers, Sebastian EMail: s...@gmxpro.de
Re: BIND and iptables config
On Fri 16 Feb 2018 at 08:53:27 (-0500), Henning Follmann wrote: > On Fri, Feb 16, 2018 at 04:26:14AM +0100, Rodary Jacques wrote: > > Le jeudi 15 février 2018, 11:44:36 CET Henning Follmann a écrit : > > > On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > > > > With NetworkManager, /etc/network/interfaces has only the loopbak > > > > interface, and I can't use wicd which can't deal with two wired > > > > interfaces. And, Henning Follmann, my English is too poor to explain > > > > clearly my setup which is the standard one when your ISP gives you one > > > > routable address and you want your home LAN to have access to internet. > > > > Thanks for your interest anyway. > > > > Jacques > > > > > > > > > > Hello, > > > no your english was good enough to describe your setup. And I would say > > > that 90% of "us" have a form of "dialup" with on routable ip address and a > > > NAT setup. > > > First bind is not "standard" in this kind of situation and makes things > > > overly complicated. I would recommend dnsmasq instead. It is much more > > > staight forward for a NAT box to setup. It will also provide you with a > > > dhcp server. > > > And in your situation you also want to disable/avoid the NetworkManager. > > I told before that wiced can't deal with two wired interfaces. > > That is not true, but lets ignore this for now. I would be interested to know how you do this. I can't even see a way to make wicd make connections on two interfaces at the same time where one is wired and the other wireless. As soon as you select one interface, the other gets disconnected. Do you have some CLI magic that makes it keep the first connection going? Cheers, David.
Re: Re: BIND and iptables config
Because when I did , witen iI just installed Jessie in April 2016, my mailbox which is dedicated to debian-user was flooded with useless or even stupid posts. Sorry for my fellow countrymen. Salut. Jacques
Re: BIND and iptables config
On Fri, Feb 16, 2018 at 04:26:14AM +0100, Rodary Jacques wrote: > Le jeudi 15 février 2018, 11:44:36 CET Henning Follmann a écrit : > > On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > > > With NetworkManager, /etc/network/interfaces has only the loopbak > > > interface, and I can't use wicd which can't deal with two wired > > > interfaces. And, Henning Follmann, my English is too poor to explain > > > clearly my setup which is the standard one when your ISP gives you one > > > routable address and you want your home LAN to have access to internet. > > > Thanks for your interest anyway. > > > Jacques > > > > > > > Hello, > > no your english was good enough to describe your setup. And I would say > > that 90% of "us" have a form of "dialup" with on routable ip address and a > > NAT setup. > > First bind is not "standard" in this kind of situation and makes things > > overly complicated. I would recommend dnsmasq instead. It is much more > > staight forward for a NAT box to setup. It will also provide you with a > > dhcp server. > > And in your situation you also want to disable/avoid the NetworkManager. > I told before that wiced can't deal with two wired interfaces. That is not true, but lets ignore this for now. > > It is quite easy because evry device you list in /e/n/i > i don't know ( with my poor English :-)) what is /e/n/i Again your English is fine it's me being lazy. /e/n/i is short for /etc/network/interfaces This is the "old" way to configure your network interfaces. > > will be > > automaticaaly ignored by the NetworkManager. > > And clearly because you have difficulties in setting this up doesn't make > > all of this a bug. > I don't find it normal to try to use interfaces before they are up! It's > obvously not a bug, but it's just telling users they shouldn't try to > understand. When I fist tried Debian in april 2016, with Jessie, I read in > the bind9 doc something like "there are some issues about changing bind9 > configuration, as future upgrade will loose your changes". without any more > details. Again, everything is behaving as expected. It is how you do things. And to repeat myself, bind is not best in this situation. But if you insist in using bind make sure it listens on your inside network interface, which should be up without delay. You do not want ( and most likely neither does your ISP) a full recursive resolver on your public interface. You insisting to stick to this setup because you already invested too much time in it is kind of stubborn (and I thought that was a German trait). You either have to invest a lot more time to understand this or you could switch to something more suited like dnsmasq. > > Also I want to mention to setup a router with Red Hat or with debian is > > possible but there a distributions which are much more suited for this > > purpose. > I switched to Debian not to find it easier (Redhat wasn't) but because of > safety and coherence. > But NetworkManager, which was on Fedora long before that on Debian, did not > the stupid things it does with resolv.conf and interfaces. You most likely have resolvconf installed which updates /etc/resolv.conf. Anything you change in there will be overwritten whenever something happens on any network device. > > I personally like pfsense and opnsense. Both are based on BSD but > > they are excellent for SOHO routing. > Thanks to Wikipedia, I understood SOHO :-Da And have you looked up OPNSense or pfsense? -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: BIND and iptables config
On Thursday, February 15, 2018 10:26:14 PM Rodary Jacques wrote: > Le jeudi 15 février 2018, 11:44:36 CET Henning Follmann a écrit : > > On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > > > With NetworkManager, /etc/network/interfaces has only the loopbak > > > interface, and I can't use wicd which can't deal with two wired > > > interfaces. And, Henning Follmann, my English is too poor to explain > > > clearly my setup which is the standard one when your ISP gives you one > > > routable address and you want your home LAN to have access to > > > internet. I don't understand--what are the two wired interfaces that you have connected to your computer? > > Hello, > > no your english was good enough to describe your setup. And I would say > > that 90% of "us" have a form of "dialup" with on routable ip address and > > a NAT setup. > > First bind is not "standard" in this kind of situation and makes things > > overly complicated. I would recommend dnsmasq instead. It is much more > > staight forward for a NAT box to setup. It will also provide you with a > > dhcp server. > > And in your situation you also want to disable/avoid the NetworkManager. > > I told before that wiced can't deal with two wired interfaces. > > > It is quite easy because evry device you list in /e/n/i Based on context, I would say that is a difficult to understand attempt at abbreviating /etc/network/interfaces, especially to offer for someone with limited English skills. I hope you are not giving up (I got the idea you might based on your previous post)--I'm not sure I can help you, but I think someone will be able to.
Re: BIND and iptables config
Le jeudi 15 février 2018, 11:44:36 CET Henning Follmann a écrit : > On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > > With NetworkManager, /etc/network/interfaces has only the loopbak > > interface, and I can't use wicd which can't deal with two wired interfaces. > > And, Henning Follmann, my English is too poor to explain clearly my setup > > which is the standard one when your ISP gives you one routable address and > > you want your home LAN to have access to internet. > > Thanks for your interest anyway. > > Jacques > > > > Hello, > no your english was good enough to describe your setup. And I would say > that 90% of "us" have a form of "dialup" with on routable ip address and a > NAT setup. > First bind is not "standard" in this kind of situation and makes things > overly complicated. I would recommend dnsmasq instead. It is much more > staight forward for a NAT box to setup. It will also provide you with a > dhcp server. > And in your situation you also want to disable/avoid the NetworkManager. I told before that wiced can't deal with two wired interfaces. > It is quite easy because evry device you list in /e/n/i i don't know ( with my poor English :-)) what is /e/n/i > will be > automaticaaly ignored by the NetworkManager. > And clearly because you have difficulties in setting this up doesn't make > all of this a bug. I don't find it normal to try to use interfaces before they are up! It's obvously not a bug, but it's just telling users they shouldn't try to understand. When I fist tried Debian in april 2016, with Jessie, I read in the bind9 doc something like "there are some issues about changing bind9 configuration, as future upgrade will loose your changes". without any more details. > Also I want to mention to setup a router with Red Hat or with debian is > possible but there a distributions which are much more suited for this > purpose. I switched to Debian not to find it easier (Redhat wasn't) but because of safety and coherence. But NetworkManager, which was on Fedora long before that on Debian, did not the stupid things it does with resolv.conf and interfaces. > I personally like pfsense and opnsense. Both are based on BSD but > they are excellent for SOHO routing. Thanks to Wikipedia, I understood SOHO :-D > > -H Have a good day (or night). JR
Re: BIND and iptables config
Le jeudi 15 février 2018, 11:44:36 CET Henning Follmann a écrit : > On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > > With NetworkManager, /etc/network/interfaces has only the loopbak > > interface, and I can't use wicd which can't deal with two wired interfaces. > > And, Henning Follmann, my English is too poor to explain clearly my setup > > which is the standard one when your ISP gives you one routable address and > > you want your home LAN to have access to internet. > > Thanks for your interest anyway. > > Jacques > > > > Hello, > no your english was good enough to describe your setup. And I would say > that 90% of "us" have a form of "dialup" with on routable ip address and a > NAT setup. > First bind is not "standard" in this kind of situation and makes things > overly complicated. I would recommend dnsmasq instead. It is much more > staight forward for a NAT box to setup. It will also provide you with a > dhcp server. > And in your situation you also want to disable/avoid the NetworkManager. > It is quite easy because evry device you list in /e/n/i will be > automaticaaly ignored by the NetworkManager. > And clearly because you have difficulties in setting this up doesn't make > all of this a bug. > > Also I want to mention to setup a router with Red Hat or with debian is > possible but there a distributions which are much more suited for this > purpose. I personally like pfsense and opnsense. Both are based on BSD but > they are excellent for SOHO routing. > I had quite enough problems setting this config to try something else. Thank you again. JR
Re: BIND and iptables config
Le 15/02/2018 à 17:01, Rodary Jacques a écrit : my English is too poor to explain clearly my setup Why don't you post in French in the debian-user-french mailing list ?
Re: BIND and iptables config
On Thu, 15 Feb 2018 08:08:59 -0500 Greg Wooledge wrote: > > > But NetworkManager > > *shudder* You're on your own with that one. > Datum: I remember Notwork Manager, but I've used it for at least five years on a netbook, with wi-fi, openvpn and a number of pre-set fixed IP wired schemes, and until recently with a 3G dongle, and it has behaved well. -- Joe
Re: BIND and iptables config
On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > With NetworkManager, /etc/network/interfaces has only the loopbak interface, > and I can't use wicd which can't deal with two wired interfaces. And, Henning > Follmann, my English is too poor to explain clearly my setup which is the > standard one when your ISP gives you one routable address and you want your > home LAN to have access to internet. > Thanks for your interest anyway. > Jacques > Hello, no your english was good enough to describe your setup. And I would say that 90% of "us" have a form of "dialup" with on routable ip address and a NAT setup. First bind is not "standard" in this kind of situation and makes things overly complicated. I would recommend dnsmasq instead. It is much more staight forward for a NAT box to setup. It will also provide you with a dhcp server. And in your situation you also want to disable/avoid the NetworkManager. It is quite easy because evry device you list in /e/n/i will be automaticaaly ignored by the NetworkManager. And clearly because you have difficulties in setting this up doesn't make all of this a bug. Also I want to mention to setup a router with Red Hat or with debian is possible but there a distributions which are much more suited for this purpose. I personally like pfsense and opnsense. Both are based on BSD but they are excellent for SOHO routing. -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: BIND and iptables config
With NetworkManager, /etc/network/interfaces has only the loopbak interface, and I can't use wicd which can't deal with two wired interfaces. And, Henning Follmann, my English is too poor to explain clearly my setup which is the standard one when your ISP gives you one routable address and you want your home LAN to have access to internet. Thanks for your interest anyway. Jacques
Re: BIND and iptables config
On Wed, Feb 14, 2018 at 11:51:50PM +0100, Rodary Jacques wrote: > I have my own DNS config t so that my home LAN can access internet (with > SNAT) to "the" internet which I created under Redhat 7.2! It did work on a > Redhat box with Systemd, NetworkManager , and the bind9 RPM. On Debian the > bind9.service tries to start when the net interfaces are not ready. First thing you want to check is that your /etc/network/interfaces file uses "auto" rather than "allow-hotplug" for the interfaces that *must* be brought up before starting network-y services. > But NetworkManager *shudder* You're on your own with that one.
Re: BIND and iptables config
On Wed, Feb 14, 2018 at 11:51:50PM +0100, Rodary Jacques wrote: > I have my own DNS config t so that my home LAN can access internet (with > SNAT) to "the" internet which I created under Redhat 7.2! It did work on a > Redhat box with Systemd, NetworkManager , and the bind9 RPM. On Debian the > bind9.service tries to start when the net interfaces are not ready.But > NetworkManager also tries to resolve DNS servers still when the net > interfaces are not ready; so the external servers can't be joined and > /etc/resolv.conf ( a soft link to /var/run/NetworkManager/resolv.conf) has > no reference to wlan (man resolvconf, indicated in > /lib/systemd/system/bind9-resolvconf.service as Docu never was on my system). > So I had to cheat with NetworkManager: I removed the link > /etc/resolv.conf, and edited the original one (created during installation) > with all my DNS servers ( the master server is on my box and can't be reached > before BIND (4, 8 or 9) is activated) . I also had to create a new profile on > my external interface with all the DNS servers. > All this done (two or three weeks), I can launch named with my own > (chroot'ed) config, and then start netfilter and SNAT > with my config. > I don't mind all this as long as I don't have to reboot, and cheat again. > Wouldn't it be a bug? No. It's not debian's, bind's or the iptables fault that your setup is unnecessary complicated and cumbersome. The issue is your setup. -H -- Henning Follmann | hfollm...@itcfollmann.com
BIND and iptables config
I have my own DNS config t so that my home LAN can access internet (with SNAT) to "the" internet which I created under Redhat 7.2! It did work on a Redhat box with Systemd, NetworkManager , and the bind9 RPM. On Debian the bind9.service tries to start when the net interfaces are not ready.But NetworkManager also tries to resolve DNS servers still when the net interfaces are not ready; so the external servers can't be joined and /etc/resolv.conf ( a soft link to /var/run/NetworkManager/resolv.conf) has no reference to wlan (man resolvconf, indicated in /lib/systemd/system/bind9-resolvconf.service as Docu never was on my system). So I had to cheat with NetworkManager: I removed the link /etc/resolv.conf, and edited the original one (created during installation) with all my DNS servers ( the master server is on my box and can't be reached before BIND (4, 8 or 9) is activated) . I also had to create a new profile on my external interface with all the DNS servers. All this done (two or three weeks), I can launch named with my own (chroot'ed) config, and then start netfilter and SNAT with my config. I don't mind all this as long as I don't have to reboot, and cheat again. Wouldn't it be a bug? Cheers. Jacques
Re: Iptables at boot
On 2/14/18 4:51 PM, Rodary Jacques wrote: I was just going to give up , and I even installed shorewall, when my last attempt with my very old iptables config (from redhat 7.2) did work. I of course to still get rid of stupid systemd config, but I don't really care since my server is allways up!. Thank you anyway for your hints. Jacques If this server is connected directly to the internet make sure the older config is really working run Steve Gibson's shields up (https://www.grc.com/shieldsup) and scan at least the lower 1024 ports. They should all be green unless you are serving up data like a web page (port 80 and/or 443). -- *...Bob*
Re: Iptables at boot
I was just going to give up , and I even installed shorewall, when my last attempt with my very old iptables config (from redhat 7.2) did work. I of course to still get rid of stupid systemd config, but I don't really care since my server is allways up!. Thank you anyway for your hints. Jacques
Re: Re: Iptables at boot
Thank you.As soon as I can I will try it
Re: Iptables at boot
On 1/31/18 12:28 PM, Jacques Rodary wrote: Hi Many things happened since my first message: I first had to get rid of connman (connection manager), which insisted to preset iptables rules without any notice. My Debian box is uset as a DNS chrooted server (also I had to modify bind9.service behaviour), and I use iptables to do NAT, since I have one routable address for several clients. With Jessie I managed to have all this working. When upgrading to stretch, because of a stupid error with grub on my RAID system, and of an insufficient backup, I lost most of my config. Thanks for your help. When everything will be OK, I surely will have the use for your answers. Jacques Have you looked at shorewall? I use it on all my debian linux installs. Basically its a front end to the kernel iptables network filters. It sets up the iptables entries and then goes away so that there is no additional program running after it does its job. It starts up on boot after you have set up the rules the way you want. You have to set a parameter in the /etc/default/shorewall file to have it start since you don't want to loose connection to your machine if you are logging in through a network port. That way you can test it before you actually use it. It is driven by several text config files in /etc/shorewall. For instance NAT is set up easily by this command in the snat file (my internet connection is on eth1 and local 172 net is on eth0): MASQUERADE 172.16.0.1/16 eth1 I redirect all the dns and time requests to my router machine even if the client has requested these services from an outside address. I use opendns for its malware filters so bind is set to forward all non local dns querys to opendns servers. I also use dnscrypt-proxy to get a secure connection to opendns so that I can be assured that the data coming back from opendns hasn't been tampered with. These 2 lines in the rules file accomplish the redirection: REDIRECT Loc 53 tcp,udp 53 - REDIRECT Loc 123 tcp,udp 123 - There is plenty of documentation and examples for simple setups available on the shorewall web site. -- *...Bob*
Re: Re: Iptables at boot
Hi Many things happened since my first message: I first had to get rid of connman (connection manager), which insisted to preset iptables rules without any notice. My Debian box is uset as a DNS chrooted server (also I had to modify bind9.service behaviour), and I use iptables to do NAT, since I have one routable address for several clients. With Jessie I managed to have all this working. When upgrading to stretch, because of a stupid error with grub on my RAID system, and of an insufficient backup, I lost most of my config. Thanks for your help. When everything will be OK, I surely will have the use for your answers. Jacques
Re: Iptables at boot
On Sun 21/Jan/2018 20:53:43 +0100 Ben Caradoc-Davies wrote: > On 21/01/18 16:05, Mark Fletcher wrote: >> To get you started [addressing the OP], here is the service file I use: > > Mine is slightly different and has the commands inline: > > > $ cat /etc/iptables/iptables.service > [Unit] > Description=iptables rules > After=network.target Shouldn't that be /network-pre.target/? I'm not familiar with systemd (I use sysvinit) but I read "It's primary purpose is for usage with firewall services that want to establish a firewall before any network interface is up" in: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Best Ale
Re: Iptables at boot
On 2018-01-21 1:02, Dejan Jocic wrote: > On 20-01-18, Jacques Rodary wrote: >> Hi >> How can I start iptables at boot. I don't find an equivalent to " service >> iptables start" with systemd and does'nt know how to create a new >> iptables.service. The manpages aren't quite clear for me. Thanks for any >> help. >> Jacques >> > > There are two options. One would be to learn to write systemd service > units. There are many tutorials on net for how to write those with > examples. Other would be to install iptables-persistent package. You can > find more about using iptables-persistent package if you google it, you > will surly run on few quick howtos. If you don't want to learn systemd at this stage you can put your iptables lines in /etc/rc.local (before exit 0 line). It will be run during boot and add your iptables config. I know it's not elegant solution by any means but it works if you don't want to play with services at this stage. -- Karol Augustin ka...@augustin.pl http://karolaugustin.pl/ +353 85 775 5312
Re: Iptables at boot
On 21/01/18 16:05, Mark Fletcher wrote: To get you started [addressing the OP], here is the service file I use: Mine is slightly different and has the commands inline: $ cat /etc/iptables/iptables.service [Unit] Description=iptables rules After=network.target [Service] Type=oneshot ExecStart=/bin/bash -c "/sbin/iptables-restore < /etc/iptables/iptables.rules" ExecStart=/bin/bash -c "/sbin/ip6tables-restore < /etc/iptables/ip6tables.rules" RemainAfterExit=yes ExecStop=/sbin/iptables -F ExecStop=/sbin/ip6tables -F [Install] WantedBy=multi-user.target You can make your initial rules file with iptables-save. Kind regards, -- Ben Caradoc-Davies Director Transient Software Limited <https://transient.nz/> New Zealand
Re: Iptables at boot
On 21-01-18, Mark Fletcher wrote: > On Sun, Jan 21, 2018 at 02:02:07AM +0100, Dejan Jocic wrote: > > On 20-01-18, Jacques Rodary wrote: > > > Hi > > > How can I start iptables at boot. I don't find an equivalent to " > > > service > > > iptables start" with systemd and does'nt know how to create a new > > > iptables.service. The manpages aren't quite clear for me. Thanks for any > > > help. > > > Jacques > > > > > > > There are two options. One would be to learn to write systemd service > > units. There are many tutorials on net for how to write those with > > examples. Other would be to install iptables-persistent package. You can > > find more about using iptables-persistent package if you google it, you > > will surly run on few quick howtos. > > > > > > To get you started [addressing the OP], here is the service file I use: > > [Unit] > Description=Load Iptables Rules > ConditionFileIsExecutable=/etc/systemd/scripts/iptables > After=network.target > > [Service] > Type=forking > ExecStart=/etc/systemd/scripts/iptables > TimeoutSec=0 > RemainAfterExit=yes > > [Install] > WantedBy=multi-user.target > > This goes in /lib/systemd/system/iptables.service and assumes your > iptables commands are in a script which is called iptables, is > executable, and is located in /etc/systemd/scripts > > I must point out there may be Debian policies of which I am not aware > about where the files should ideally go; I lifted this configuration > from a non-Debian box. There is nothing about it that will _not work_ on > Debian, but there may be a preferred Debian location for such files, > which hopefully my contribution will encourage someone knowledgable to > add. > > then to run it once, as root: > systemctl start iptables > > and to set it up so it runs at boot, as root: > systemctl enable iptables > > HTH > > Mark > Location for local custom unit files should be /etc/systemd/system but it can be on several more places, if you desire so. It is just that those in /etc/systemd/system take precedence over others.
Re: Simple iptables table doesn't let me forward X windows
On Sat, Jan 20, 2018 at 07:30:09PM +, Joe wrote: > On Sat, 20 Jan 2018 12:13:12 -0600 > Jason wrote: > > > Hi, > > > > I am trying to setup (what should be) a simple iptables table between > > two machines on a local network, both with static IP addresses. The > > machine I want to set up the iptables on is a headless server which I > > access using ssh. I want to cut off all communications except with the > > machine I ssh from. What I did works except when I try to run a GUI > > program on the server to display locally, after a pause I get > > something like: > > > > Geany: cannot open display > > or > > xterm: Xt error: Can't open display: localhost:10.0 > > > > both of which work before I run the iptables commands. > > OK, that leaves little doubt that it's a firewall issue. > > > > > Here's what I did (000.000.000.000 is substituted for actual IP > > address of client machine): > > > > $ sudo iptables -A INPUT -s 000.000.000.000 -j ACCEPT > > $ sudo iptables -A OUTPUT -d 000.000.000.000 -j ACCEPT > > $ sudo iptables -P INPUT DROP > > $ sudo iptables -P OUTPUT DROP > > > > I also tried to add > > > > $ sudo iptables -A INPUT -i lo -j ACCEPT > > You'll also want a lo ACCEPT in the OUTPUT chain. Which fixed my problem, see my reply to Pascal. > > > > > without success. > > > > What do I need to do to get X forwarding to work? > > > > Others may know the exact answer in this case. I'll make couple of > suggestions for future iptables issues. > > 1. Take one of the very basic firewall scripts (there are many around) > that works statefully i.e. allows everything out, accepts established > and related state replies, drops invalid packets, accepts lo in and out. > Start from there, check your X forwarding works, then add IP address > restrictions as required one by one. When it breaks, you know exactly > what did it. > > 2. Use -j LOG targets with various --log-prefix values in various > places to understand what's going on, generally what's being dropped > by mistake. When you finish with them, comment them out but leave them > there for future use. Tailor them by address and/or port to look for > specific issues. In your existing case: > > iptables -A INPUT -j LOG --log-level debug --log-prefix "INPUT dropped:" > > just before the actual DROP judgement, and another for OUTPUT. It will > generate a lot of stuff quite quickly, so comment it once you have some > logs to examine. It's amazing what really obvious things you can > overlook with a firewall, and this will identify them fairly quickly. > It's a much less tedious job than using a packet capture application, > which is massive overkill for simple networking problems. > > 3. You may be doing this without telling us here, but when you have a > script to make your firewall, put in initialisation commands first, to > remove any existing rules, and set overall DROP defaults in case your > main iptables logic takes a wrong turn. You'll want at least the -F and > -X iptables options for filter, nat and mangle tables. If you haven't > disabled IPv6 altogether, you'll also need corresponding ip6tables > commands, as IPv6 is wide open by default. > I'm learning. Thanks for responding! -- Jason
Re: Simple iptables table doesn't let me forward X windows
On Sat, Jan 20, 2018 at 07:58:27PM +0100, Pascal Hambourg wrote: > Le 20/01/2018 à 19:13, Jason a écrit : > > > >I am trying to setup (what should be) a simple iptables table > > I don't think so. In iptables, "tables" are preexisting data structures > containing chains, and chains contain rules that you create. The set of > rules in these chains and tables is called, well, a ruleset. Thanks for the clarification. This is my first experience using iptables and my knowledge of it is elementary at best. > > >between > >two machines on a local network, both with static IP addresses. > > Nonsense. A ruleset is set up on one machine, not between two machines. I had thought after I wrote it that the wording probably wasn't correct. > > >The machine I want to set up the iptables on > > As I wrote : on one machine. > > >is a headless server which I > >access using ssh. I want to cut off all communications except with the > >machine I ssh from. > > I guess you use X tunnelling with ssh -X or -Y ? Yes, with -X. > >What I did works except when I try to run a GUI > >program on the server to display locally, after a pause I get > >something like: > > > > Geany: cannot open display > >or > > xterm: Xt error: Can't open display: localhost:10.0 > > > >both of which work before I run the iptables commands. > > > >Here's what I did (000.000.000.000 is substituted for actual IP > >address of client machine): > > You really should not use that kind of address for substitution. 0.0.0.0 has > a special meaning. You could use addresses in 192.0.2.0/24 which are > reserved for examples and documentation instead. Okay, making a note of it. > >$ sudo iptables -A INPUT -s 000.000.000.000 -j ACCEPT > >$ sudo iptables -A OUTPUT -d 000.000.000.000 -j ACCEPT > >$ sudo iptables -P INPUT DROP > >$ sudo iptables -P OUTPUT DROP > > > >I also tried to add > > > >$ sudo iptables -A INPUT -i lo -j ACCEPT > > > >without success. > > > >What do I need to do to get X forwarding to work? > > Add > > iptables -A OUTPUT -o lo -j ACCEPT That works, thanks a lot Pascal! > > Note that this ruleset allows much more than just SSH and X forwarding > between the two machines. Which is fine in this case. Thanks again! -- Jason
Re: Iptables at boot
On Sun, Jan 21, 2018 at 02:02:07AM +0100, Dejan Jocic wrote: > On 20-01-18, Jacques Rodary wrote: > > Hi > > How can I start iptables at boot. I don't find an equivalent to " service > > iptables start" with systemd and does'nt know how to create a new > > iptables.service. The manpages aren't quite clear for me. Thanks for any > > help. > > Jacques > > > > There are two options. One would be to learn to write systemd service > units. There are many tutorials on net for how to write those with > examples. Other would be to install iptables-persistent package. You can > find more about using iptables-persistent package if you google it, you > will surly run on few quick howtos. > > To get you started [addressing the OP], here is the service file I use: [Unit] Description=Load Iptables Rules ConditionFileIsExecutable=/etc/systemd/scripts/iptables After=network.target [Service] Type=forking ExecStart=/etc/systemd/scripts/iptables TimeoutSec=0 RemainAfterExit=yes [Install] WantedBy=multi-user.target This goes in /lib/systemd/system/iptables.service and assumes your iptables commands are in a script which is called iptables, is executable, and is located in /etc/systemd/scripts I must point out there may be Debian policies of which I am not aware about where the files should ideally go; I lifted this configuration from a non-Debian box. There is nothing about it that will _not work_ on Debian, but there may be a preferred Debian location for such files, which hopefully my contribution will encourage someone knowledgable to add. then to run it once, as root: systemctl start iptables and to set it up so it runs at boot, as root: systemctl enable iptables HTH Mark
Re: Iptables at boot
On 20-01-18, Jacques Rodary wrote: > Hi > How can I start iptables at boot. I don't find an equivalent to " service > iptables start" with systemd and does'nt know how to create a new > iptables.service. The manpages aren't quite clear for me. Thanks for any > help. > Jacques > There are two options. One would be to learn to write systemd service units. There are many tutorials on net for how to write those with examples. Other would be to install iptables-persistent package. You can find more about using iptables-persistent package if you google it, you will surly run on few quick howtos.
Iptables at boot
Hi How can I start iptables at boot. I don't find an equivalent to " service iptables start" with systemd and does'nt know how to create a new iptables.service. The manpages aren't quite clear for me. Thanks for any help. Jacques
Re: Simple iptables table doesn't let me forward X windows
Joe wrote: > OK, that leaves little doubt that it's a firewall issue. usually xauth missing or wrong xauth people do upgrade, then just press yes and pile up mess over mess and then come here to ask for help. it's fun regards
Re: Simple iptables table doesn't let me forward X windows
On Sat, 20 Jan 2018 12:13:12 -0600 Jason wrote: > Hi, > > I am trying to setup (what should be) a simple iptables table between > two machines on a local network, both with static IP addresses. The > machine I want to set up the iptables on is a headless server which I > access using ssh. I want to cut off all communications except with the > machine I ssh from. What I did works except when I try to run a GUI > program on the server to display locally, after a pause I get > something like: > > Geany: cannot open display > or > xterm: Xt error: Can't open display: localhost:10.0 > > both of which work before I run the iptables commands. OK, that leaves little doubt that it's a firewall issue. > > Here's what I did (000.000.000.000 is substituted for actual IP > address of client machine): > > $ sudo iptables -A INPUT -s 000.000.000.000 -j ACCEPT > $ sudo iptables -A OUTPUT -d 000.000.000.000 -j ACCEPT > $ sudo iptables -P INPUT DROP > $ sudo iptables -P OUTPUT DROP > > I also tried to add > > $ sudo iptables -A INPUT -i lo -j ACCEPT You'll also want a lo ACCEPT in the OUTPUT chain. > > without success. > > What do I need to do to get X forwarding to work? > Others may know the exact answer in this case. I'll make couple of suggestions for future iptables issues. 1. Take one of the very basic firewall scripts (there are many around) that works statefully i.e. allows everything out, accepts established and related state replies, drops invalid packets, accepts lo in and out. Start from there, check your X forwarding works, then add IP address restrictions as required one by one. When it breaks, you know exactly what did it. 2. Use -j LOG targets with various --log-prefix values in various places to understand what's going on, generally what's being dropped by mistake. When you finish with them, comment them out but leave them there for future use. Tailor them by address and/or port to look for specific issues. In your existing case: iptables -A INPUT -j LOG --log-level debug --log-prefix "INPUT dropped:" just before the actual DROP judgement, and another for OUTPUT. It will generate a lot of stuff quite quickly, so comment it once you have some logs to examine. It's amazing what really obvious things you can overlook with a firewall, and this will identify them fairly quickly. It's a much less tedious job than using a packet capture application, which is massive overkill for simple networking problems. 3. You may be doing this without telling us here, but when you have a script to make your firewall, put in initialisation commands first, to remove any existing rules, and set overall DROP defaults in case your main iptables logic takes a wrong turn. You'll want at least the -F and -X iptables options for filter, nat and mangle tables. If you haven't disabled IPv6 altogether, you'll also need corresponding ip6tables commands, as IPv6 is wide open by default. -- Joe
Re: Simple iptables table doesn't let me forward X windows
Le 20/01/2018 à 19:13, Jason a écrit : I am trying to setup (what should be) a simple iptables table I don't think so. In iptables, "tables" are preexisting data structures containing chains, and chains contain rules that you create. The set of rules in these chains and tables is called, well, a ruleset. between two machines on a local network, both with static IP addresses. Nonsense. A ruleset is set up on one machine, not between two machines. The machine I want to set up the iptables on As I wrote : on one machine. is a headless server which I access using ssh. I want to cut off all communications except with the machine I ssh from. I guess you use X tunnelling with ssh -X or -Y ? What I did works except when I try to run a GUI program on the server to display locally, after a pause I get something like: Geany: cannot open display or xterm: Xt error: Can't open display: localhost:10.0 both of which work before I run the iptables commands. Here's what I did (000.000.000.000 is substituted for actual IP address of client machine): You really should not use that kind of address for substitution. 0.0.0.0 has a special meaning. You could use addresses in 192.0.2.0/24 which are reserved for examples and documentation instead. $ sudo iptables -A INPUT -s 000.000.000.000 -j ACCEPT $ sudo iptables -A OUTPUT -d 000.000.000.000 -j ACCEPT $ sudo iptables -P INPUT DROP $ sudo iptables -P OUTPUT DROP I also tried to add $ sudo iptables -A INPUT -i lo -j ACCEPT without success. What do I need to do to get X forwarding to work? Add iptables -A OUTPUT -o lo -j ACCEPT Note that this ruleset allows much more than just SSH and X forwarding between the two machines.
Simple iptables table doesn't let me forward X windows
Hi, I am trying to setup (what should be) a simple iptables table between two machines on a local network, both with static IP addresses. The machine I want to set up the iptables on is a headless server which I access using ssh. I want to cut off all communications except with the machine I ssh from. What I did works except when I try to run a GUI program on the server to display locally, after a pause I get something like: Geany: cannot open display or xterm: Xt error: Can't open display: localhost:10.0 both of which work before I run the iptables commands. Here's what I did (000.000.000.000 is substituted for actual IP address of client machine): $ sudo iptables -A INPUT -s 000.000.000.000 -j ACCEPT $ sudo iptables -A OUTPUT -d 000.000.000.000 -j ACCEPT $ sudo iptables -P INPUT DROP $ sudo iptables -P OUTPUT DROP I also tried to add $ sudo iptables -A INPUT -i lo -j ACCEPT without success. What do I need to do to get X forwarding to work? Thanks! -- Jason
Tr : new command in replacement for iptables in debian 9 ?
thank you ben, it is probably nftables.my problem is solved ... Le Mardi 17 octobre 2017 14h03, Stephane L a écrit : Hi, Is there a new command to replace iptables in debian 9 ? I have read something like that best regards
Re: new command in replacement for iptables in debian 9 ?
On 18/10/17 01:03, Stephane L wrote: Is there a new command to replace iptables in debian 9 ? I have read something like that nftables? https://packages.debian.org/sid/main/nftables I have not yet used it. iptables still works for stretch (9) and sid. Kind regards, -- Ben Caradoc-Davies Director Transient Software Limited <http://transient.nz/> New Zealand
new command in replacement for iptables in debian 9 ?
Hi, Is there a new command to replace iptables in debian 9 ? I have read something like that best regards
Re: How can I enable ufw firewall tool with an existing set of iptables rules?
On Mon, Aug 28, 2017 at 15:54 Joe wrote: ... I confess to no specific knowledge here, but I suspect none of the > firewall front-ends will accommodate an arbitrary iptables ruleset, as > the front-ends impose their own structure which would almost certainly > conflict. > Unfortunately, ufw doesn't have a safety net. However, I did keep a valid ssh connection in a separate window to ensure I could still login after I enabled ufw. That's still a dangerous way but my fallback is my server is with a company who can assist in a reboot and ssh access again if necessary. Alexander's idea is a good one, and I really should have taken his advice. However, all worked out well, fortunately. Thanks, Joe. -Tom
Re: How can I enable ufw firewall tool with an existing set of iptables rules?
On Mon, Aug 28, 2017 at 15:49 Alexander V. Makartsev wrote: > Smart way to do it is to setup a cron job to run shell script that will > flush (or restore to default working ruleset) iptables rules every 10 > minutes. Thanks, Alexander. -Tom
Re: How can I enable ufw firewall tool with an existing set of iptables rules?
On Mon, 28 Aug 2017 20:01:54 + Tom Browder wrote: > Installing and enabling ufw sounds easy, but how is the existing set > of iptables rules treated? I want to use ufw on a remote server and > losing ssh would be disastrous! > I confess to no specific knowledge here, but I suspect none of the firewall front-ends will accommodate an arbitrary iptables ruleset, as the front-ends impose their own structure which would almost certainly conflict. I tried two or three front-ends some years ago, but they were not suited to my needs, and I've stayed with a custom iptables script. However, all of them must allow some safe and relatively sane way to activate a ruleset while guaranteeing one or more types of access. Many servers are administered remotely. In this situation, I'd set up a skeleton test server in a local VM, and confirm that I understood how to do this before trying it for real. Even then I might set up a brute-force-and-ignorance reversion to the original state in a cron job timed for ten minutes later if not cancelled. And I'd still worry... how far do you have to travel if it goes wrong? -- Joe
Re: How can I enable ufw firewall tool with an existing set of iptables rules?
Smart way to do it is to setup a cron job to run shell script that will flush (or restore to default working ruleset) iptables rules every 10 minutes. With this approach, even if you mess up your iptables rules and loose ssh, you can simply wait for 10 minutes and reconnect to ssh. Take your time and check that cron job is working correctly and if it is, continue with ufw\iptables setup or correct mistakes. On 29.08.2017 01:01, Tom Browder wrote: > Installing and enabling ufw sounds easy, but how is the existing set > of iptables rules treated? I want to use ufw on a remote server and > losing ssh would be disastrous! > > Thanks. > > -Tom >
How can I enable ufw firewall tool with an existing set of iptables rules?
Installing and enabling ufw sounds easy, but how is the existing set of iptables rules treated? I want to use ufw on a remote server and losing ssh would be disastrous! Thanks. -Tom
Re: dhcp and iptables
On Tue, Aug 15, 2017 at 07:07:41PM +1000, Zenaan Harkness wrote: > On Tue, Aug 15, 2017 at 10:42:42AM +0200, Pascal Hambourg wrote: > > Le 15/08/2017 à 10:03, Bonno Bloksma a écrit : > > > > > > Can someone help me to understand this? Why does DHCP work when the > > > iptable lines looks like in the first example > > > > DHCP software usually use the raw network interface, by-passing the IP > > stack and iptables rules. > > Would one "configure" DHCP firewalling with ebtables, or ip, or > something else? > Neither! Tell dhcp server to only listen on the internal network. That's it. -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: dhcp and iptables
Le 15/08/2017 à 11:07, Zenaan Harkness a écrit : On Tue, Aug 15, 2017 at 10:42:42AM +0200, Pascal Hambourg wrote: DHCP software usually use the raw network interface, by-passing the IP stack and iptables rules. Would one "configure" DHCP firewalling with ebtables ebtables works only on a bridge, so it requires creating a dummy bridge containing the network interface. or ip ip for firewalling ?
Re: dhcp and iptables
On Tue, Aug 15, 2017 at 10:42:42AM +0200, Pascal Hambourg wrote: > Le 15/08/2017 à 10:03, Bonno Bloksma a écrit : > > > > Can someone help me to understand this? Why does DHCP work when the iptable > > lines looks like in the first example > > DHCP software usually use the raw network interface, by-passing the IP stack > and iptables rules. Would one "configure" DHCP firewalling with ebtables, or ip, or something else?
Re: dhcp and iptables
Le 15/08/2017 à 10:03, Bonno Bloksma a écrit : Can someone help me to understand this? Why does DHCP work when the iptable lines looks like in the first example DHCP software usually use the raw network interface, by-passing the IP stack and iptables rules.
dhcp and iptables
Hi, I have a Linux machine that used to be a router as well so it used to have multiple interfaces. My firewall script used to have special lines to not accept certain traffic on the outside interface. Nowadays the machine is just doing DHCP stuff on the internal network and all is fine, except. I was just now looking at my firewall script and noticed I accept DHCP and BOOTPS requests from all interfaces except... the only interface I have, but it all still works. Can someone help me to understand this? Why does DHCP work when the iptable lines looks like in the first example My firewall looks like this: linein:~#(vm) iptables -L -v Chain INPUT (policy DROP 49 packets, 5557 bytes) pkts bytes target prot opt in out source destination 1131 88068 ACCEPT all -- anyany anywhere anywhere state RELATED,ESTABLISHED 2 104 ACCEPT tcp -- anyany 172.16.0.0/15anywhere tcp dpt:ssh 0 0 ACCEPT all -- lo any anywhere anywhere 160 ACCEPT icmp -- anyany anywhere anywhere 0 0 ACCEPT tcp -- !eth0 any anywhere anywhere tcp dpt:bootps 0 0 ACCEPT udp -- !eth0 any anywhere anywhere udp dpt:bootps Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- anyany anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT all -- anyany 172.16.0.0/15anywhere Chain OUTPUT (policy ACCEPT 1478 packets, 338K bytes) pkts bytes target prot opt in out source destination As you can see the bootps lines have 0 hits and that is also because they accept traffic only from interfaces other than eth0, which happens to be the only interface right now, except for lo. As far as I can determine dhcp/bootps traffic gets accepted by the first line with the "state RELATED,ESTABLISHED" part, although that is only an educated guess. Now why would be the case can anyone tell me that? The funny thing it that once I changed the bootps lines to the proper format the bootps lines seem to hit my DHCP requests if I do a ipconfig /renew on my Windows machine. linein:~/newfw#(vm) iptables -L -v Chain INPUT (policy DROP 1 packets, 229 bytes) pkts bytes target prot opt in out source destination 41 3424 ACCEPT all -- anyany anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT tcp -- anyany 172.16.0.0/15anywhere tcp dpt:ssh 0 0 ACCEPT all -- lo any anywhere anywhere 0 0 ACCEPT icmp -- anyany anywhere anywhere 0 0 ACCEPT tcp -- anyany anywhere anywhere tcp dpt:bootps 1 328 ACCEPT udp -- anyany anywhere anywhere udp dpt:bootps Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- anyany anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT all -- anyany 172.16.0.0/15anywhere Chain OUTPUT (policy ACCEPT 42 packets, 7204 bytes) pkts bytes target prot opt in out source destination Now how can that be if the RELATED,ESTABLISHED line is the first in my iptable? The DHCP request should either hit that line and get accepted or get accepted by another iptables line or get dropped when the bootps line was wrong. But as the bootps lines are the last on my INPUT chain and the policy is DROP I don't get it. :-( Can someone help me to understand this? Why does DHCP work when the iptable lines looked like in the first example Ps. I see I still have some forward lines, I should delete those as well from my config but I want to change as little as possible right now to understand what is going on. Bonno Bloksma
Re: PROGRESS [Re: New to iptables]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jan 05, 2017 at 01:25:10PM -0600, Richard Owlett wrote: > On 1/4/2017 10:54 AM, Richard Owlett wrote: > [snipping my original ;] > One doesn't understand things without understood background. > This thread triggered some understanding of things I'd been told in > past. That's great to hear (should I say "read"). It's what we all are here for, right? All the best for your plans :) Cheers - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlhur7sACgkQBcgs9XrR2kZ1BwCfcPunHMD0HzpbcEjVcAL1aT1x ioIAniN1sZL2dhCQIbF52Q0Y7T9Sy9hA =sxgp -END PGP SIGNATURE-
PROGRESS [Re: New to iptables]
On 1/4/2017 10:54 AM, Richard Owlett wrote: [snipping my original ;] One doesn't understand things without understood background. This thread triggered some understanding of things I'd been told in past. I'm using http://www.netfilter.org/documentation/ as a reading guide. A shorewall or netfilter page pointed me to ufw (I'll use gufw for now). Browsing the the feature list of privoxy suggests it may be of interest. I won't be using a VM, but will install very minimal Debian with a browser on a flash drive and use it for banking.
Re: New to iptables
Le 04/01/2017 à 21:30, Joe a écrit : iptables operates at the level of IP addresses and protocols (and ports, in the case of tcp and udp, other protocols don't use them). Where it appears to work with URLs, as you have discovered, it resolves the URL Not URLs. Hostnames.
Re: New to iptables
On Wed, 4 Jan 2017 10:54:53 -0600
Richard Owlett wrote:
> I'm searching for an introduction to iptables that leads me to
> answers to the questions *I* have. I've got a flock of links I'm
> working thru.
How are we going to know what resource answers the questions *you* have
if we don't know what they are?
>
>
> In the meantime I have a few questions.
>
> One of the links led to _Securing Debian Manual_ and in particular
> "Appendix F - Security update protected by a firewall"
> {https://www.debian.org/doc/manuals/securing-debian-howto/ap-fw-security-update.en.html}
>
> I follow the description as far as it goes - i.e. access is
> limited to a specific URL.
> QUESTION 1
> What happens if the URL is not "security.debian.org" but my bank.
> I assume that there is no problem with links within the same domain.
> I DO know however that the site gets information from other sites
> to handle my requests. From what I can follow they are
> JavaScripts applets(right word) to display information. What
> would happen?
As you are discovering, http(s) is messy. There's a basic web page,
which will almost always contain a number of further URLs which your
web browser is expected to retrieve, some of which lead to JavaScript
and other abominations. Without knowing exactly what URLs are
referenced by a particular container web page (which may change from
day to day, a web designer's Prime Directive is 'if it ain't broke,
break it'), there's no way you can explicitly allow or disallow all of
them.
iptables operates at the level of IP addresses and protocols (and ports,
in the case of tcp and udp, other protocols don't use them). Where it
appears to work with URLs, as you have discovered, it resolves the URL
once at the time the iptables command is executed (an 'iptables script'
is a set of individual iptables commands, usually executed on boot) and
places the resulting IP address into a table which is then accessed in
real time by the kernel. It's safer to stick to IP addresses, as that
reminds you that non-local ones are subject to change without notice.
If you want control within an application protocol, such as http, then
iptables is not a great tool. You need something that can see inside
the protocol, something that in a firewall is usually called an
'application gateway' or similar. The best known for http is squid,
which is a caching proxy server with extra bells and whistles. One
of the favourite examples using the iptables PREROUTING chain is
transparent proxying to enable a two-NIC firewall to send all http
requests from the LAN to a squid port, without the LAN machines needing
special configuration or being able to avoid using the proxy. That kind
of thing is what iptables is good for. iptables is also a good basic
network diagnostic tool, when you don't need the power and complexity
of wireshark or similar. A few strategically placed logging rules can
tell you whether your client is even attempting to reach a distant
server, and whether you get a reply.
https is supposedly not subject to analysis, but if you want to
frighten yourself (you mention online banking) google for 'superfish'
and 'lenovo'.
--
Joe
Re: New to iptables
While you computer should be protected by a fire wall (I use shorewall for
that) maybe you should look at privoxy. privoxy is a Privacy Enhancing Proxy
that the browser can be set to go through to access web sites.
The privoxy setup for your sand-boxed install would be set to allow access only
to the banking sites by url and block all others. That way you don't have to
worry about the ip addresses a bank might have at the time you access it (they
may have multiple addresses for load shearing for example). Again the
sand-boxed install should have a firewall that only lets outgoing requests get
through and blocks all incoming probes. Shorewall can easily do this for you so
you won't have to mess with the workings of iptables.
Your open install should also use privoxy with a more open setup that will help
you stay away from malware and add sites. Shorewall firewall can be set to
allow incoming access to any servers you might have like ssh and let outgoing
requests get through.
If your computer has a processor that will support virtual machines and at least
4GB ram and a spare 20G or so of file space you could easily install Debian in a
VM and add all the firewall and privoxy rules to get to your banking sites.
KVM/QEMU and virtual machine manager make this process easy. To get to your
banking sites you would just spin up the sand-boxed VM. It would show up in a
separate window and allow you to have all the other stuff you were doing on you
host un-sand-boxed machine still visible. It might even make more sense to make
the VM be your "dirty" so that if it did get infected you would just install
Debian again. Or keep a spare copy of the just installed image file that the VM
runs off of and simply copy the spare over the messed up image file and be back
in business in a few minutes.
These are just a few examples of what you can do. I use VMs all the time mostly
for testing updates before I commit them to my host desktop machine. One VM
even runs my weather station software 24/7.
*...Bob*
On 01/04/2017 11:54 AM, Richard Owlett wrote:
> I'm searching for an introduction to iptables that leads me to answers to the
> questions *I* have. I've got a flock of links I'm working thru.
>
>
> In the meantime I have a few questions.
>
> One of the links led to _Securing Debian Manual_ and in particular
> "Appendix F - Security update protected by a firewall"
> {https://www.debian.org/doc/manuals/securing-debian-howto/ap-fw-security-update.en.html}
>
>
> I follow the description as far as it goes - i.e. access is limited to a
> specific URL.
> QUESTION 1
> What happens if the URL is not "security.debian.org" but my bank.
> I assume that there is no problem with links within the same domain.
> I DO know however that the site gets information from other sites to handle my
> requests. From what I can follow they are JavaScripts applets(right word) to
> display information. What would happen?
>
> Because of my my uncertainties intend to have a "sandboxed" install. The
> associated partition will have only Debian and the browser.
>
> Question 2
> There will be a separate install of Debian that I will use for "everything
> else". Can the iptables of that install be set to allow access to any domain
> *EXCEPT* my bank's? The goal being minimization of "operator error".
>
> Question 3
> Is there a simple minded tool that I could enter the show in the example in
> "Appendix F".
>
> TIA
>
>
>
