Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #167046

Re: Firewall - basic config?

Show all headers | View raw

On 04/23/2016 01:01 PM, Reco wrote:
> 	Hi.
>
> On Sat, 23 Apr 2016 13:04:36 -0400
> Harris Paltrowitz <harrisupstate@yahoo.com> wrote:
>
>> Hi List,
>>
>> I have a question regarding how I've configured my iptables to act as a
>> very basic "firewall", i.e., one that simply prevents any and all
>> incoming connections.  Now, from my readings over the past several days
>> I think I've learned that at least some of my outgoing requests will
>> have responses that should be allowed to come back in -- but aside from
>> that, I essentially want my firewall to act in a very "default" method,
>> i.e., the way a complete neophyte would expect his or her firewall to
>> work within Windows or Mac.
>>
>> Here's what I did -- I will also paste the results of my current
>> "iptables -L" command...  I hope the text block is not too large...
> No, it's not large. Somewhat complex, but that's the price to pay for
> using ufw.
>
> For the reference, the simpliest possible set of netfilter rules that
> does what you want is (assuming static IP assignment, no DHCP):
>
> iptables -F INPUT
> iptables -A INPUT -i lo -j ACCEPT
> iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
> iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT
> iptables -A INPUT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED \
> 	-j ACCEPT
> iptables -A INPUT -p udp -m conntrack --ctstate RELATED,ESTABLISHED \
> 	-j ACCEPT
> iptables -P INPUT DROP
> iptables -F FORWARD
> iptables -P FORWARD DROP
> iptables -F OUTPUT
> iptables -P OUTPUT ACCEPT
>
>
>> 1. First, my issue with manually configuring iptables is not the
>> complexity of it, per se -- but the fact that I want to avoid having my
>> newness to it prevent me from setting it up in an insecure manner.  So...
> You already allowed more holes in INPUT chain that you described.
>
>
>> 2. I found that "ufw" works as a line-command-based-front-end to
>> iptables.  I also came across "gufw" in my travels, and I even tried it,
>> but I've since gleaned that all that's really needed in ufw to
>> completely mimic the basic functionality of gufw is to (a) install ufw,
>> and (b) enable it -- one does not even need to establish the default
>> policies, although the Debian wiki page incorrectly states that this is
>> necessary.
> There are numerous frontends to iptables. IMO they do simple things
> complex way and require really strange kludges to do complex things.
> Your iptables is an excellent example of the first of those approaches.
>
> If 'raw' iptables are not your cup of tea - consider using firewalld
> and firewall-applet.
>
>
>> 3. So after having installed and enabled ufw, here's the output of my
>> "iptables -L" command.  I noticed a mention of "microsoft-ds" in
>> there...  I assume this is just a protocol, and not a piece of
>> software!
> Indeed it's a protocol. I prefer 'iptables -nvL' or straightforward
> 'iptables-save' in such cases.
>
>>   Any suggestions/comments would be much appreciated. Thanks
>> very much.
> Assuming you'd want to keep ufw, you'd need to worry about:
>
>> Chain ufw-after-input (1 references)
>> target     prot opt source               destination
>> ufw-skip-to-policy-input  udp  --  anywhere anywhere             udp
>> dpt:netbios-ns
>> ufw-skip-to-policy-input  udp  --  anywhere anywhere             udp
>> dpt:netbios-dgm
>> ufw-skip-to-policy-input  tcp  --  anywhere anywhere             tcp
>> dpt:netbios-ssn
>> ufw-skip-to-policy-input  tcp  --  anywhere anywhere             tcp
>> dpt:microsoft-ds
> There's no reason to accept these unless you're using Samba (either
> the server or client).
However, if you look at the ufw-skip-to-policy-input chain, it simply 
DROPs everything, so there is no hole here, as far as I can tell.  
Indeed, this chain specifies all protocols, from anywhere to anywhere, 
target DROP. So, in the end, all packets to these destination ports 
(dpt) are DROPed.

>> ufw-skip-to-policy-input  udp  --  anywhere anywhere             udp
>> dpt:bootps
> There's no reason to allow udp:67 unless you're a DHCP server.
Again, see above, ufw-skip-to-policy-input will DROP these packets.
>
>> ufw-skip-to-policy-input  udp  --  anywhere anywhere             udp
>> dpt:bootpc
> Have some use for DHCP client, but this rule is unnecessary weak.
See above.
>
>
>> ACCEPT     udp  --  anywhere             anywhere             udp
>> spt:bootps dpt:bootpc
> So, first they compose a perfectly good rule for DHCP client
> (ufw-before-input chain), but then they allow udp:68 unconditionally in
> ufw-after-input chain. I'll assume that something very clever is going
> on here.
Correct me if I'm wrong, however, the ufw-before-input chain concerns me 
greatly.  The first rule here ACCEPTs all packets of all protocols 
coming from anywhere and going to anywhere.  This appears to be an 
incredibly big hole.  The above rule Reco mentions, will never be seen 
as it is quite a bit further down the chain, after everything has 
already been ACCEPTed.  Surely, I'm reading something wrong?:-\

>
>> ufw-not-local  all  --  anywhere             anywhere
>> ACCEPT     udp  --  anywhere             224.0.0.251          udp dpt:mdns
> Useful for Avahi users, no reason to allow this otherwise.
>
>> ACCEPT     udp  --  anywhere             239.255.255.250      udp dpt:1900
>> ufw-user-input  all  --  anywhere             anywhere
> No reason to allow UPnP unless you're planning to use this host as a
> firewall/router.
>
>
> All other rules have nothing to catch my eye.
>
> Reco
>
The INPUT chain seems to be problematic to me.  As noted above, the 
ufw-before-input chain seems to ACCEPT everything in its first rule, so 
none of the other rules in the INPUT chain will have any effect. The 
OUTPUT chain seems to be the same way, though this is not as problematic 
for me, as usually, you will want to allow just about anything in the 
OUTPUT chain.  Though, I suspect that this could allow an exploit 
wherein the user's machine is used to originate undesired packets 
heading out to the net.

The FORWARD chain looks to be secure, as ultimately the default DROP 
policy for that chain is what happens to everything.

Again, while I have done some studying of iptables, and think that I am 
fluent in the incantations necessary to set it up, I am not an expert, 
so if I have mis-interpreted the OPs provided iptables listing, please 
correct me for both my and his benefit!!

-- 
Mike

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Firewall - basic config? Harris Paltrowitz <harrisupstate@yahoo.com> - 2016-04-23 19:10 +0200
  Re: Firewall - basic config? Reco <recoverym4n@gmail.com> - 2016-04-23 20:10 +0200
    Re: Firewall - basic config? Michael Milliman <michael.e.milliman@gmail.com> - 2016-04-24 07:20 +0200
      Re: Firewall - basic config? Reco <recoverym4n@gmail.com> - 2016-04-24 11:00 +0200
        Re: Firewall - basic config? Michael Milliman <michael.e.milliman@gmail.com> - 2016-04-26 04:10 +0200
  Re: Firewall - basic config? Joe <joe@jretrading.com> - 2016-04-23 22:00 +0200
    Re: Firewall - basic config? shawn wilson <ag4ve.us@gmail.com> - 2016-04-25 15:50 +0200
  Re: Firewall - basic config? cbannister@slingshot.co.nz - 2016-04-27 10:40 +0200
  Re: Firewall - basic config? Jonathan Dowland <jmtd@debian.org> - 2016-04-27 11:30 +0200
    Re: Firewall - basic config? Harris Paltrowitz <harrisupstate@yahoo.com> - 2016-04-27 13:50 +0200

csiph-web