| View previous topic :: View next topic |
| Author |
Message |
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
 Posted: Sun Jun 18, 2017 8:33 pm Post subject: iptables and portage [solved] |
 |
|
I'm wondering if I'm not searching appropriately for this, as my online searches come up with related, but different issues, but I'm having difficulties downloading packages while emerging with my iptables firewall up. I have a firewall script (see here) that sets the firewall rules (know that if any of the rules seem odd it's due to my not having any real experience with iptables and using this server as a way to learn). Is there a more straightforward way to give access to emerge-related downloads?
Last edited by alienjon on Wed Jun 21, 2017 2:27 am; edited 1 time in total |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21635
|
| Posted: Sun Jun 18, 2017 9:17 pm Post subject: |
|
|
For starters, the standard criticisms apply:- Using a bash script to load rules is error prone.
- Using a bash script that runs without set -e is asking for trouble.
- Prefer using iptables-save to show us the loaded rules over showing us the rules you want to load. These two sets may differ if your bash script failed to load all the rules.
- When you need advice on a firewall, you should explain to us what currently broken things you need fixed or currently working things you need disabled.
- You should describe in brief your network topology. We do not need a full accounting, but it would be helpful to know whether this machine is purely internal to a LAN or does double duty as the NAT device protecting your network from the Internet.
- Tell us how many network cards you have, their interface names, and their approximate purposes. Primarily, we need to understand which cards should be considered trusted (internal) and which should be considered untrusted (Internet). Wireless could go either way, depending on what wireless access policy you use. Personal use password-protected wireless probably goes in the trusted list. A public wireless access point probably goes on the untrusted list.
Your initial description suggests to me that your packet filter is preventing emerge from downloading distfiles. Is that correct? If so, please identify a specific download that fails with these rules. Depending on the ebuild, Portage may use http or ftp. It might use https, though that seems to be a bit rarer.
Your rules definitely need some modifications. Identifying exactly which modifications requires a better understanding of what you hope to block/allow. I can guess some of that from your comments, but you have quite a few rules that make sense only if the machine both provides service FOO to other systems and consumes service FOO from other systems. Usually, systems do only one of those two. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sun Jun 18, 2017 9:34 pm Post subject: |
|
|
| You blocked all outgoing traffic so emerge can't make http requests. |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Sun Jun 18, 2017 9:56 pm Post subject: |
|
|
Thanks for the thoughts, Hu:
| Hu wrote: | | Using a bash script to load rules is error prone. Using a bash script that runs without set -e is asking for trouble. |
I agree. I've been using a script to easily clear/see what options I'm setting. I'm more familiar with bash than iptables by a bit, so I hoped to basically get the filters/chains setup as appropriate and then iptables-save when all was done.
| Hu wrote: | | Prefer using iptables-save to show us the loaded rules over showing us the rules you want to load. These two sets may differ if your bash script failed to load all the rules. |
Related to your prior comment, I'm guessing you would suggest to simply use iptables-save to update the rules and iptables-load to reload the previously saved set? Is it as simple as one command and the other? What I'm getting at is that I'm wondering if I could save the commands that I know work and, if something messes up, could I then just call iptables-load to set to the previous, or does this only work at boot/reset the whole shebang?
| Hu wrote: | When you need advice on a firewall, you should explain to us what currently broken things you need fixed or currently working things you need disabled.
You should describe in brief your network topology. We do not need a full accounting, but it would be helpful to know whether this machine is purely internal to a LAN or does double duty as the NAT device protecting your network from the Internet.
Tell us how many network cards you have, their interface names, and their approximate purposes. Primarily, we need to understand which cards should be considered trusted (internal) and which should be considered untrusted (Internet). Wireless could go either way, depending on what wireless access policy you use. Personal use password-protected wireless probably goes in the trusted list. A public wireless access point probably goes on the untrusted list. |
Good point. I'm running on a fairly simple home network. I get Internet from my ISP via a cable modem that connects to my router. The router itself connects to two separate switches that bring ethernet to various parts of the house. One end-point is my desktop, one is the server, and one is another router that I use as a WAP (ie: all of these connect via ethernet to the switches). Both my desktop (Windows 10) and server (Gentoo) have one network interface (technically my desktop has a few virtual ones, but no other cards/connections to the Internet or otherwise outside of the computer). My sever is essentially headless ('essentially' as I don't have a monitor plugged in and do most of my communication via ssh or other services (ie: SAMBA, plex), though I do have a video card in it for the install and if something really messes up and I can't log in otherwise).
Conceptually, and as you mentioned, I want all hard-wired and wireless connected to the WAP to be considered 'trusted' and thus allowed full access to each other. The firewall in which this thread is based is installed on the Gentoo server. I'm currently running ssh, apache (that uses https and lets encrypt and forwards http traffic to https), SAMBA, and a plex media server. Because I'll want the server to have access to the Internet through the router I want the firewall to carefully allow only what I know it should be allowing and, in some cases, hard block anyone who appears to be connecting inappropriately (thanks to fail2ban I've already found a handful of what appear to be Chinese based IPs that attempted to bruteforce SSH. fail2ban blocks for a predetermined amount of time, but when a few of these came up regularly I wanted to add a permanent block directly through iptables.
| Hu wrote: | | Your initial description suggests to me that your packet filter is preventing emerge from downloading distfiles. Is that correct? If so, please identify a specific download that fails with these rules. Depending on the ebuild, Portage may use http or ftp. It might use https, though that seems to be a bit rarer. |
This is correct. The download this came up for was linux-firmware. |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Sun Jun 18, 2017 10:14 pm Post subject: |
|
|
| Ant P. wrote: | | You blocked all outgoing traffic so emerge can't make http requests. |
Not all outgoing. The only things I specifically drop in the script are the permabans. Drop is the default policy, but I do have http enabled further below as well as the specific IP address for the server from which it is trying to download from (I figured adding every possible distro IP was crazy enough to start this thread). |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21635
|
| Posted: Sun Jun 18, 2017 11:37 pm Post subject: |
|
|
| alienjon wrote: | | I'm more familiar with bash than iptables by a bit, so I hoped to basically get the filters/chains setup as appropriate and then iptables-save when all was done. |
That is fine. I still suggest you enable set -e in the script in the interim. This will halt the script if any rules fail to load (perhaps due to a typo, or a missing kernel feature). As is, your script loads the rules it can and skips past any that cannot load. iptables should still generate output warning about failed entries, but if you do not see that, you could end up with a weird half-configured filter where early rules and late rules are present, but middle rules are absent.
| alienjon wrote: | | Related to your prior comment, I'm guessing you would suggest to simply use iptables-save to update the rules and iptables-load to reload the previously saved set? Is it as simple as one command and the other? What I'm getting at is that I'm wondering if I could save the commands that I know work and, if something messes up, could I then just call iptables-load to set to the previous, or does this only work at boot/reset the whole shebang? |
iptables-save is like iptables -n -L, except it is designed to be machine-readable and to show all the information necessary to restore the configuration later. The human-readable version omits some details for brevity. Those details may matter when debugging.
The Gentoo init scripts use iptables-save / iptables-restore internally, so once you finalize your configuration and delegate it to the Gentoo init script, you will be fine.
Yes, you can save the output of any number of iptables-save runs and use that output to revert to the corresponding configuration using iptables-restore. Calling iptables-restore clears the configuration and replaces it with the specified filters, if it succeeds. Otherwise, it leaves the previous configuration enabled. You may use this at any time.
| alienjon wrote: | | Good point. I'm running on a fairly simple home network. ... |
We can work with this. One important point you did not describe is whether Internet-initiated traffic can reach this server on arbitrary ports. Your filters are written as though it probably can, and this is the safe assumption, so we can proceed on the assumption that full filtering is required.
| alienjon wrote: | | Hu wrote: | | Your initial description suggests to me that your packet filter is preventing emerge from downloading distfiles. Is that correct? If so, please identify a specific download that fails with these rules. Depending on the ebuild, Portage may use http or ftp. It might use https, though that seems to be a bit rarer. |
This is correct. The download this came up for was linux-firmware. |
FTP is a terrible protocol. Your rules allow ftp-control (but only for internal hosts), but not ftp-data (at all), which uses a separate port and, depending on how the ftp client decides to operate, may involve back-connections. Omission of ftp-data alone will break this download. If the ftp client tried to use active mode, you are in for even more pain. Banning FTP should be considered a good idea, not a defect. In my opinion, you would be better served by configuring Portage not to use FTP-based download.
For a general analysis of your rules:
These are interfaces, not addresses. Allowing them is correct, though.
| https://pastebin.com/p0tzSasK: | 25 # These are permabanned addresses.
26 iptables -A INPUT --source 218.65.30.43 -j RETURN
27 iptables -A INPUT --source 153.99.182.23 -j RETURN |
You could use -j DROP here to emphasize that they are to be banned even if for some reason the chain policy was not DROP.
What machine owns this address? Why do you have --source for it in both the INPUT and OUTPUT chains? That is unlikely to be correct.
| https://pastebin.com/p0tzSasK: | 39 # Allow emerge --sync
40 iptables -A INPUT -p TCP --dport 873 -j ACCEPT
41 iptables -A OUTPUT -p TCP --dport 873 -j ACCEPT |
This block is probably wrong. The INPUT rule permits incoming rsync requests. Unless this machine is intended to offer rsync service to the world, you do not want that line. The OUTPUT is fine.
| https://pastebin.com/p0tzSasK: | 43 # Needed emerge IP addresses
44 iptables -A INPUT -s 200.236.31.1 -j ACCEPT
45 iptables -A OUTPUT -s 200.236.31.1 -j ACCEPT |
The OUTPUT rule is pointless. Your server will never use the Gentoo mirror address as a source, only as a destination. In my opinion, trying to whitelist specific Gentoo mirrors is the wrong solution anyway. Mirrors come and go over time, and most downloads are done through a name that will change its underlying A records as that happens. If you rely on this approach, expect to periodically need to review and update the list.
| https://pastebin.com/p0tzSasK: | 47 # Allow ssh
48 iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport ssh -m state --state NEW,ESTABLISHED -j ACCEPT |
You already allowed ESTABLISHED above. It is unnecessary to repeat it here.
| https://pastebin.com/p0tzSasK: | 53 # Allow webserver
56 iptables -A INPUT -p TCP --dport https --syn -m conntrack --ctstate NEW -j ACCEPT
57 iptables -A OUTPUT -p TCP --dport https --syn -m conntrack --ctstate NEW -j ACCEPT |
This looks confused. The first line lets the system act as an https server. The second line lets it contact https servers elsewhere. Specifying both --syn and using conntrack may work, but looks strange. You should let conntrack handle this.
| https://pastebin.com/p0tzSasK: | 59 # Allow ftp
60 iptables -A INPUT -p TCP -s 192.168.1.0/24 --dport ftp -j ACCEPT
61 iptables -A OUTPUT -p TCP -s 192.168.1.0/24 --dport ftp -j ACCEPT |
As noted above, this is unlikely to work due to FTP's split control/data design. I suggest removing these lines and finding a way to avoid using FTP at all. Also, note that since these are address-restricted, even if FTP did not have the split design, this would not have enabled your attempted download.
| https://pastebin.com/p0tzSasK: | 62 iptables -A INPUT -p TCP -s 192.168.1.0/24 --dport sftp -j ACCEPT
63 iptables -A OUTPUT -p TCP -s 192.168.1.0/24 --dport sftp -j ACCEPT |
This is the Simple File Transfer Protocol, not the openssh Secure File Transfer. It is unlikely that you need these lines at all.
This looks wrong. You allow clients to query your DNS server over UDP. You allow any peer that sends from TCP port 53 to talk to any port of yours. Are you providing DNS service?
This looks wrong. You enable any outbound TCP connection whatsoever, but only if it has a source port of 53, which is privileged. Very few programs are likely to hit this rule, and it is even less likely that they will be programs you want to enable.
I am not familiar with the requirements of this server and do not have time to learn them just now. Sorry, no audit for this block.
| https://pastebin.com/p0tzSasK: | 101 # Speedtest ports
102 iptables -A INPUT -p tcp --dport 80 -j ACCEPT
103 iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT |
This almost entirely eliminates any value you might otherwise get from filtering outbound traffic. Transport over http has largely superceded purpose-built protocols, so any unwanted program that cannot tunnel over http is not worth worrying about. Any unwanted program that can tunnel over http will use this as a trivial escape. |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Mon Jun 19, 2017 2:48 am Post subject: |
|
|
| Hu wrote: | | I still suggest you enable set -e in the script in the interim. |
Already done  I imagine this would go at the beginning of the script?
| Hu wrote: | | The Gentoo init scripts use iptables-save / iptables-restore internally, so once you finalize your configuration and delegate it to the Gentoo init script, you will be fine. |
iptables-save seems like a bit of a misnomer then, as it doesn't 'save' anything but rather displays what is currently set? Now that you mention it I do recall that iptables is saved/stored through the init script. It's /etc/init.d/ip[6]tables [save,restore] for the functions I referred to previously (save will save the current iptables state and restore will erase the current configuration and load the last saved state). I think I saw that the iptables-[save,restore] command and that the init script had the same options (ie: save/restore) and thought that they were the same things, but one was init-based and the other was the commands it was based off of.
| Hu wrote: | | One important point you did not describe is whether Internet-initiated traffic can reach this server on arbitrary ports. |
As far as I'm aware yes, it very much can.
| Hu wrote: | | In my opinion, you would be better served by configuring Portage not to use FTP-based download. |
Never had a problem with FTP before now, but I understand your point. I'll look into deferring FTP over other connection types. Thanks for the pointer.
| Hu wrote: | | Code: | 25 # These are permabanned addresses.
26 iptables -A INPUT --source 218.65.30.43 -j RETURN
27 iptables -A INPUT --source 153.99.182.23 -j RETURN |
You could use -j DROP here to emphasize that they are to be banned even if for some reason the chain policy was not DROP. |
Thanks for the catch on this. This was definitely a wrong chain. I meant to use -j REJECT here. I had read a post on another forum a few months back that made a good argument to use REJECT over DROP in these kinds of cases as it's a faster response and doesn't really provide any extra security. For the life of me I can't find the post, but here's another that says basically the same thing in fewer words.
| Hu wrote: | | Code: | 32 iptables -A INPUT -s 192.168.1.11 -j ACCEPT
33 iptables -A OUTPUT -s 192.168.1.11 -j ACCEPT |
What machine owns this address? Why do you have --source for it in both the INPUT and OUTPUT chains? That is unlikely to be correct. |
That's my desktop. I wanted to have a contingency to make sure there would never be a reason why my desktop couldn't talk with the server, as it's the main machine I use to interface with the server (for shell access and maintenance, I mean). I'm guessing you'd think this is overkill?
| Hu wrote: | | Code: | 39 # Allow emerge --sync
40 iptables -A INPUT -p TCP --dport 873 -j ACCEPT
41 iptables -A OUTPUT -p TCP --dport 873 -j ACCEPT |
This block is probably wrong. The INPUT rule permits incoming rsync requests. Unless this machine is intended to offer rsync service to the world, you do not want that line. The OUTPUT is fine. |
Thanks for calling this one out. I was having problems even syncing a while back until I found the right port. I want to say that without the INPUT I still had a problem syncing. I've commented the INPUT for now and will remove it later if my sync works find during the next run.
| Hu wrote: | | Code: | 43 # Needed emerge IP addresses
44 iptables -A INPUT -s 200.236.31.1 -j ACCEPT
45 iptables -A OUTPUT -s 200.236.31.1 -j ACCEPT |
The OUTPUT rule is pointless. Your server will never use the Gentoo mirror address as a source, only as a destination. In my opinion, trying to whitelist specific Gentoo mirrors is the wrong solution anyway. Mirrors come and go over time, and most downloads are done through a name that will change its underlying A records as that happens. If you rely on this approach, expect to periodically need to review and update the list. |
This was another example that nothing I was doing was working to get portage to download appropriately. I added the OUTPUT as much out of frustration as anything, though I knew it likely wasn't going to have any effect. I think part of what confused me on the matter is that as connections are two way (my server's machine will communicate information to the Gentoo servers and vice versa, I wasn't sure if the OUTPUT is needed to accept the acknowledgement of the connection or anything akin to that. That having been said I do recognize that I have a state-ful line earlier about accepting all RELATED,ESTABLISHED connections and I imagine that would address this very question. That having been said, would it be a fair representation to say that, so long as RELATED,ESTABLISHED is allowed then any remaining rules would only account for the initial connection? I imagine that would have to be the case, otherwise every rule would require both INPUT/OUTPUT and would make that distinction useless.
| Hu wrote: | | Code: | 47 # Allow ssh
48 iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport ssh -m state --state NEW,ESTABLISHED -j ACCEPT |
You already allowed ESTABLISHED above. It is unnecessary to repeat it here. |
Understood. I've commented the line for the moment; plan to remove later.
| Hu wrote: | | Code: | 53 # Allow webserver
56 iptables -A INPUT -p TCP --dport https --syn -m conntrack --ctstate NEW -j ACCEPT
57 iptables -A OUTPUT -p TCP --dport https --syn -m conntrack --ctstate NEW -j ACCEPT |
This looks confused. The first line lets the system act as an https server. The second line lets it contact https servers elsewhere. Specifying both --syn and using conntrack may work, but looks strange. You should let conntrack handle this. |
Do you mean to simply remove the --syn option in these lines? I need to read up on these options a bit more, I think. I'm not familiar with either (they came from somewhere someone mentioned this was a way to address two-way HTTPS access). This is one example where I think both INPUT and OUTPUT are needed as I do run a HTTPS webserver and will need to download via HTTPS from time to time.
| Hu wrote: | | Code: | 59 # Allow ftp
60 iptables -A INPUT -p TCP -s 192.168.1.0/24 --dport ftp -j ACCEPT
61 iptables -A OUTPUT -p TCP -s 192.168.1.0/24 --dport ftp -j ACCEPT |
As noted above, this is unlikely to work due to FTP's split control/data design. I suggest removing these lines and finding a way to avoid using FTP at all. Also, note that since these are address-restricted, even if FTP did not have the split design, this would not have enabled your attempted download. |
I'm guessing these lines are what's causing the problems in the first place (as you mentioned it only specifies the *.*.1.* subnet and wouldn't include allow portage distfiles). However, what confuses me is that the -j ACCEPT for the specific whitelisted portage servers were previously mentioned without specifying a port (thought I believe I did include a port at one point and still didn't have luck). As that command came earlier I would imagine this one wouldn't have actually had any impact.
| Hu wrote: | | Code: | 62 iptables -A INPUT -p TCP -s 192.168.1.0/24 --dport sftp -j ACCEPT
63 iptables -A OUTPUT -p TCP -s 192.168.1.0/24 --dport sftp -j ACCEPT |
This is the Simple File Transfer Protocol, not the openssh Secure File Transfer. It is unlikely that you need these lines at all. |
Noted. I think I saw this recommended in a post somewhere. I don't intend to run [s]ftp on the server (at least at the moment) though I wonder if I'll need to download something at some point (via portage or wget) that uses sftp. Might be good to have INPUT at the very least?
| Hu wrote: | | Code: | 65 # DNS server
66 iptables -A INPUT -p udp --dport 53 -j ACCEPT
67 iptables -A INPUT -p tcp --sport 53 -j ACCEPT |
This looks wrong. You allow clients to query your DNS server over UDP. You allow any peer that sends from TCP port 53 to talk to any port of yours. Are you providing DNS service? |
| Hu wrote: | | Code: | | 69 iptables -A OUTPUT -p tcp --sport 53 -j ACCEPT |
This looks wrong. You enable any outbound TCP connection whatsoever, but only if it has a source port of 53, which is privileged. Very few programs are likely to hit this rule, and it is even less likely that they will be programs you want to enable. |
This was part of a problem I had when I first setup the server where I wouldn't access DNS at all. No, I don't run a DNS server, but I seem to remember having a problem without all of these lines. What should DNS access look like?
| Hu wrote: |
I am not familiar with the requirements of this server and do not have time to learn them just now. Sorry, no audit for this block. |
No worries on this one. I'm less concerned about Plex because they have pretty good documentation on their requirements and I found all the ports I'll need (though as this is the server I imagine I could remove all the OUTPUT lines?
| Hu wrote: | | Code: | 101 # Speedtest ports
102 iptables -A INPUT -p tcp --dport 80 -j ACCEPT
103 iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT |
This almost entirely eliminates any value you might otherwise get from filtering outbound traffic. Transport over http has largely superceded purpose-built protocols, so any unwanted program that cannot tunnel over http is not worth worrying about. Any unwanted program that can tunnel over http will use this as a trivial escape. |
Ok, I'm literally smiling over this one. This is, admittedly, a very crude hack. I have a script that runs a command-line speedtest.net speed test a few times a day. When I first ran the script it worked, but stopped working after running the firewall script. Come to find out that they use port 80 to test Internet speeds (which makes sense, I suppose, since their main product runs via a browser). I wanted to either a) find a way to specify "port 80 but only for their domain" or b) a better Internet speed test. I couldn't figure out (a) and haven't had time to look into (b). In the meantime I have this glaring hole in the firewall. I may just remove these lines until I have the time to test better, though. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21635
|
| Posted: Tue Jun 20, 2017 2:30 am Post subject: |
|
|
| alienjon wrote: | | Already done I imagine this would go at the beginning of the script? |
Yes.
| alienjon wrote: | | iptables-save seems like a bit of a misnomer then, as it doesn't 'save' anything but rather displays what is currently set? |
Yes. It is a key tool used as plumbing by tools that can save your state. By itself, it saves only to stdout, which is not useful without a redirection.
| alienjon wrote: |
Thanks for the catch on this. This was definitely a wrong chain. I meant to use -j REJECT here. |
As I understand man iptables, using -j RETURN invoked the policy for the chain, which you set to DROP above. Using -j DROP is just a more direct way of stating the same result. Using -j REJECT does something else. Personally, I prefer -j DROP for traffic from hosts I know I never want to talk to. I can see -j REJECT for traffic from hosts that I trust, but do not intend to service (such as other local machines).
| alienjon wrote: | | Hu wrote: | | Code: | | 33 iptables -A OUTPUT -s 192.168.1.11 -j ACCEPT |
Why do you have --source for it in both the INPUT and OUTPUT chains? |
That's my desktop. I wanted to have a contingency to make sure there would never be a reason why my desktop couldn't talk with the server, as it's the main machine I use to interface with the server (for shell access and maintenance, I mean). I'm guessing you'd think this is overkill? |
Not overkill, just wrong. Your INPUT rule is fine, but your OUTPUT rule says that this Gentoo machine is always permitted to send outbound traffic claiming to be from your desktop. It is unlikely this rule will ever be hit, even during the emergency scenario it is meant to handle. You likely want -d, not -s.
| alienjon wrote: | | Hu wrote: | | Code: | | 45 iptables -A OUTPUT -s 200.236.31.1 -j ACCEPT |
The OUTPUT rule is pointless. Your server will never use the Gentoo mirror address as a source, only as a destination. ... |
... |
As above, I think you missed my point here. My critique was not about whether you need the rule (although that is a good discussion). My critique was that the rule uses the wrong iptables match, so it will never be used, even in cases where having the (correctly written variant) rule is the right solution.
As for your question, if your OUTPUT policy is DROP, then you need a rule to allow the initial OUTPUT packet so that the connection can be created. Once created, stateful tracking will eliminate the need for per-purpose mirrored INPUT rules. If your OUTPUT policy were ACCEPT, all outbound traffic would be permitted and would, where appropriate, create connection tracking entries that would then eliminate the need for specific INPUT rules (assuming that, as with your rules, INPUT had a rule to ACCEPT ESTABLISHED).
| alienjon wrote: | | Do you mean to simply remove the --syn option in these lines? I need to read up on these options a bit more, I think. I'm not familiar with either (they came from somewhere someone mentioned this was a way to address two-way HTTPS access). This is one example where I think both INPUT and OUTPUT are needed as I do run a HTTPS webserver and will need to download via HTTPS from time to time. |
Yes, remove --syn. Yes, if you are both offering HTTPS to others and consuming HTTPS from others, then it is correct to have both rules.
| alienjon wrote: | | I'm guessing these lines are what's causing the problems in the first place (as you mentioned it only specifies the *.*.1.* subnet and wouldn't include allow portage distfiles). However, what confuses me is that the -j ACCEPT for the specific whitelisted portage servers were previously mentioned without specifying a port (thought I believe I did include a port at one point and still didn't have luck). As that command came earlier I would imagine this one wouldn't have actually had any impact. |
As ACCEPT rules, they can only cause a problem if you define a problem to be allowing access to hosts which ought to be denied. My critique was that they were insufficient to fully enable FTP service, not that they interfered with it. Yes, the earlier entry allowing all access to a Gentoo mirror should have been sufficient, assuming that all FTP service was provided by the mirror you whitelisted. Remember that some of these names map to multiple addresses, so you might not have whitelisted the same host that Portage then tried to use.
| alienjon wrote: | | Noted. I think I saw this recommended in a post somewhere. I don't intend to run [s]ftp on the server (at least at the moment) though I wonder if I'll need to download something at some point (via portage or wget) that uses sftp. Might be good to have INPUT at the very least? |
No. I am not aware of any Gentoo mirrors that offer service over OpenSSH sftp. If you did try to offer service to OpenSSH, you would need a rule for the ssh port, not the sftp port, since OpenSSH sftp is tunnelled over ssh.
| alienjon wrote: |
| Hu wrote: | | Code: | 65 # DNS server
66 iptables -A INPUT -p udp --dport 53 -j ACCEPT
67 iptables -A INPUT -p tcp --sport 53 -j ACCEPT |
|
| Hu wrote: | | Code: | | 69 iptables -A OUTPUT -p tcp --sport 53 -j ACCEPT |
|
This was part of a problem I had when I first setup the server where I wouldn't access DNS at all. No, I don't run a DNS server, but I seem to remember having a problem without all of these lines. What should DNS access look like? |
In most cases, OUTPUT -p udp --dport 53 -j ACCEPT combined with your stateful INPUT rule should be sufficient. There is no need for the tcp OUTPUT rule I quoted. The INPUT rules are only needed if you run a DNS server, so you can remove those also.
| alienjon wrote: | | No worries on this one. I'm less concerned about Plex because they have pretty good documentation on their requirements and I found all the ports I'll need (though as this is the server I imagine I could remove all the OUTPUT lines? |
Maybe. I know nothing about Plex's requirements, so I cannot say whether it ever initiates any traffic that would require an OUTPUT rule. Personally, I would move all the Plex related rules to a subchain that is restricted to trusted hosts, unless you intend to offer Plex service to anonymous Internet users. |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Tue Jun 20, 2017 3:38 am Post subject: |
|
|
| Hu wrote: | | As I understand man iptables, using -j RETURN invoked the policy for the chain, which you set to DROP above. |
I thought that RETURN simply returned to the previous chain. In my examples this would, essentially, result in the default policy (in this case DROP). However, I thought that in a more complicated chain configuration it could lead to other possibilities. I did find out that REJECT will not work as a default policy, however. It needs to be set on a per rule basis (unless I'm missing something somewhere, this hadn't worked for me before).
| Hu wrote: | | Not overkill, just wrong. Your INPUT rule is fine, but your OUTPUT rule says that this Gentoo machine is always permitted to send outbound traffic claiming to be from your desktop. It is unlikely this rule will ever be hit, even during the emergency scenario it is meant to handle. You likely want -d, not -s. |
| Hu wrote: | | As above, I think you missed my point here. |
You are correct, I did. This makes sense. I understand -d/-s, but I'm enough of a novice with this that I overlooked considering this. I'll try to be better with this.
| Hu wrote: | | As for your question, if your OUTPUT policy is DROP, then you need a rule to allow the initial OUTPUT packet so that the connection can be created. Once created, stateful tracking will eliminate the need for per-purpose mirrored INPUT rules. If your OUTPUT policy were ACCEPT, all outbound traffic would be permitted and would, where appropriate, create connection tracking entries that would then eliminate the need for specific INPUT rules (assuming that, as with your rules, INPUT had a rule to ACCEPT ESTABLISHED). |
Is there 'good practice' in this regard? My initial thought is to maintain DROP as the default so that I'll have to have better control over who is able to communicate with who through the firewall. At the same time, I could also see an argument for ACCEPTing all OUTPUT and DROPping all INPUT unless RELATED,ESTABLISH is set to ACCEPTed. I imagine this is an 'easier' solution, though less secure.
| Hu wrote: | | Yes, the earlier entry allowing all access to a Gentoo mirror should have been sufficient, assuming that all FTP service was provided by the mirror you whitelisted. Remember that some of these names map to multiple addresses, so you might not have whitelisted the same host that Portage then tried to use. |
Also, as you pointed out, my mixing up -s/-d may have played a role in this. What would you suggest to allow portage access for these downloads? You already mentioned preferring non-ftp downloads, but outside of that how do I let IPTABLES know that I trust Gentoo servers?
| Hu wrote: | | In most cases, OUTPUT -p udp --dport 53 -j ACCEPT combined with your stateful INPUT rule should be sufficient. There is no need for the tcp OUTPUT rule I quoted. The INPUT rules are only needed if you run a DNS server, so you can remove those also. |
Before I saw you replied to my post I was actually trying to test some of what we're talking about by starting with a fresh set of chains and adding rules one by one (more on this in a moment). What I was able to test was portage syncing and I discovered this very point (that opening port 873, which is required for syncing, and DNS via UDP is required). However, my understanding is that TCP is not only also used for DNS, but is sometimes preferred. I imagine having it open to both protocols would be the better option in my scenario?
| Hu wrote: | | Personally, I would move all the Plex related rules to a subchain that is restricted to trusted hosts, unless you intend to offer Plex service to anonymous Internet users. |
ie: create a 'plex' chain where all needed INPUT ports would point and populate this with specific IPs for allowable machines?
For a quick step back to my redoing these rules here is my updated iptables rulesets that includes modifications based on our conversation. Note that this set also includes the fail2ban chains that should have been there before as well. Also, the -L -n --line-numbers version. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21635
|
| Posted: Wed Jun 21, 2017 1:52 am Post subject: |
|
|
| alienjon wrote: | | I thought that RETURN simply returned to the previous chain. In my examples this would, essentially, result in the default policy (in this case DROP). |
You are correct. I prefer explicit -j DROP over -j RETURN + -P DROP because it states the intent at the usage site. The policy is just there to catch anything that slips through.
| alienjon wrote: | | Is there 'good practice' in this regard? My initial thought is to maintain DROP as the default so that I'll have to have better control over who is able to communicate with who through the firewall. At the same time, I could also see an argument for ACCEPTing all OUTPUT and DROPping all INPUT unless RELATED,ESTABLISH is set to ACCEPTed. I imagine this is an 'easier' solution, though less secure. |
In principle, using DROP for OUTPUT is more secure. In practice, if you allow outbound http and https, then you have such a huge egress path that trying to confine the other ports is largely pointless.
| alienjon wrote: | | Also, as you pointed out, my mixing up -s/-d may have played a role in this. What would you suggest to allow portage access for these downloads? You already mentioned preferring non-ftp downloads, but outside of that how do I let IPTABLES know that I trust Gentoo servers? |
Prepare to whitelist them all, configure Portage to download only from specific whitelisted mirrors, or configure the firewall to permit all traffic on those ports from user portage to any destination. Each path is a tradeoff.
| alienjon wrote: | | However, my understanding is that TCP is not only also used for DNS, but is sometimes preferred. I imagine having it open to both protocols would be the better option in my scenario? |
TCP can be used for DNS, but most queries are done over UDP. There is likely little harm in permitting DNS over TCP.
| alienjon wrote: | | ie: create a 'plex' chain where all needed INPUT ports would point and populate this with specific IPs for allowable machines? |
Yes. You could instead create INPUT rules that match allowed addresses and point it to a chain which matches permitted ports. Either approach achieves the desired results. |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Wed Jun 21, 2017 2:26 am Post subject: |
|
|
| Hu wrote: | | or configure the firewall to permit all traffic on those ports from user portage to any destination. |
I wondered if this was possible a while back. I remember reading through the manpages, but must have been inundated with all the information and either missed this bit in the text or missed that particular manpage altogether.
| Hu wrote: | | Yes. You could instead create INPUT rules that match allowed addresses and point it to a chain which matches permitted ports. Either approach achieves the desired results. |
And would be as efficient as the other - same number of calculations, if I'm conceptualizing this correctly.
Wow, thanks for all the help with this. Despite reading through documentation, several tutorials, and a handful of online discussions there really wasn't a good introduction I came across in regards to building a good firewall. I imagine that the varied configurations and options available (not to mention kernel and module versions) play a big role, but even still some of this felt like it would be better suited in a college course. Thanks again for the help! |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21635
|
| Posted: Wed Jun 21, 2017 3:45 am Post subject: |
|
|
The number of calculations would not necessarily be equal. Consider the two expressions: | Code: | | (A || B || C || D || E) && (Y || Z) |
| Code: | | (Y || Z) && (A || B || C || D || E) |
In the first, a non-matching packet needs to fail the five-way test before the short-circuit operation can conclude the packet will not match. In the second, it needs to fail a two-way test. Thus, to maximize efficiency, you want to order the rules such that the cheapest tests come first. Within a disjunction, order the predicates in order of most likely to least likely. For example, if C, D, and E are all equal cost to compare, and E happens more often than C, you want E || C || D.
It is unlikely you will be handling enough traffic on this machine that the difference will matter in this exercise. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
