Hi.
On Sat, 23 Apr 2016 13:04:36 -0400
Harris Paltrowitz <harrisupst...@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).
> 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.
> ufw-skip-to-policy-input udp -- anywhere anywhere udp
> dpt:bootpc
Have some use for DHCP client, but this rule is unnecessary weak.
> 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.
> 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
