On 04/23/2016 01:01 PM, Reco wrote:
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).
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
