On Wed, 4 Jan 2017 10:54:53 -0600 Richard Owlett <rowl...@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