Re: New to iptables
On Wed, 4 Jan 2017 10:54:53 -0600
Richard Owlett <rowlett@cloud85.net> 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
Reply to: