Linux Netfilter discussions
 help / color / mirror / Atom feed
From: gazoxtapod <gazoxtapod@embarqmail.com>
To: netfilter@vger.kernel.org
Subject: Can't override filter section OUTPUT DROP / INPUT DROP Policy
Date: Fri, 25 Aug 2017 14:16:28 +0000	[thread overview]
Message-ID: <59A0313C.1020409@embarqmail.com> (raw)

Esteemed List Participants and Lurkers:    NEWBIE ALERT!
==============================================================
Raspberry Pi 2 - Raspbian GNU/Linux 8 (jessie)
iptables v1.4.21  -  ufw v0.33-2
==============================================================
I'm trying to use the Pi2 as an appliance to monitor DSL Usage from my 
DSL modem (192.168.0.1), which is between a (nearly default 
configuration) firewall router for my LAN and the ISP.  The Pi2 box 
project, when completed, is strictly an appliance that is a client to 
the modem, reading date/time and DSL usage and error status, and 
displaying this on an LCD display.

* I need to allow the Pi2 to negotiate a DHCP request for an IP address 
from the router on bootup. (This is the system default - no need to do 
anything)
* I need to allow the Pi2 to make a periodic connection to the modem and 
fetch data. (I do this with Python Requests - it works)
* I am trying to block all other types of incoming and outgoing 
connections. This is what I can NOT do.

I have tried to research this extensively and at least found this thread 
which is somewhat similar to my basic approach:
  . . DROP policy, serious vulnerability?
  . . http://www.spinics.net/lists/netfilter/msg56020.html

I have tried various tests using 'ufw' and 'iptables' with little to no 
success.  I did discover that "ufw" commands are persistent, and 
"iptables" are dynamic, but not persistent (I think that is right?).

Here is what I 'think' I am trying to do:

sudo iptables -P INPUT DROP        <--  P:Policy
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT DROP
sudo iptables -A OUTPUT -s 192.168.0.1 -j ACCEPT  <--A:Append s:source 
j:jump
sudo iptables -A INPUT -s 192.168.0.1 -j ACCEPT   <--don't need this?

I found the rule for what I think is the DHCP negotiation in the 
unmodified original iptables --list:
-A ufw-before-input -p udp --sport 67 --dport 68 -j accept

OK.  I did discover that "iptables -F" cleans out everything in the 
(non-persistent) --list very nicely and leaves only the 3 filter section 
default policies.  With "ufw enable", as soon as I set "default deny 
outgoing" (-P OUTPUT DROP) as the policy, NOTHING I do overrides that 
and I have no browser connection ability to the modem.  As soon as I set 
"default deny incoming" (-P INPUT DROP) as the policy, NOTHING I do 
overrides that.  I have been using "ping" from an adjacent desktop on 
the LAN (192.168.1.104) to test incoming connections, and it works only 
with "ufw disable" ... EVERYTHING works wide open when disabled, as 
expected, so the firewall router is not getting in the way.

I have managed to get the --list in this configuration, but all access 
to the modem (via the browser) and is blocked. (using ping system URL, 
ping blocked as well):

root@artypi:~# iptables -L -v
Chain INPUT (policy DROP 2 packets, 64 bytes)
  pkts bytes target   prot opt in   out  source      destination
     0     0 ACCEPT   all  --  any  any  192.168.0.1 anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
  pkts bytes target   prot opt in   out  source      destination

Chain OUTPUT (policy DROP 2 packets, 152 bytes)
  pkts bytes target   prot opt in   out  source      destination
     0     0 ACCEPT   all  --  any  any  192.168.0.1 anywhere

* Is the order of the Policies and the rules wrong? can it be changed?
* How can I achieve my objectives to block all access, except allow 
Python Requests (and browser?) access to the modem?

After that, is the above rule for DHCP correct if I use INPUT and/or 
OUTPUT chains instead of the "ufw-before-input" chain?

Thank you for your gracious patience, and for any and all comments, 
suggestions, and assistance.
Blessings in abundance, all the best, & ENJOY!
Art in Carlisle, PA USA

P.S.: I also found this article, but it didn't seem to help me at all: 
Iptables Drop rule - strange behaviour, 
https://www.spinics.net/lists/netfilter/msg52940.html

             reply	other threads:[~2017-08-25 14:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-25 14:16 gazoxtapod [this message]
2017-08-25 16:12 ` Can't override filter section OUTPUT DROP / INPUT DROP Policy netfilter
2017-08-25 16:16   ` netfilter
2017-08-25 20:03   ` gazoxtapod

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59A0313C.1020409@embarqmail.com \
    --to=gazoxtapod@embarqmail.com \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox