LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Are iptables-based firewall Policy settings the perfect back-stop? (https://www.linuxquestions.org/questions/linux-security-4/are-iptables-based-firewall-policy-settings-the-perfect-back-stop-4175638113/)

boombaby 09-10-2018 11:21 AM

Are iptables-based firewall Policy settings the perfect back-stop?
 

Hello, Any...


If I have an iptables-based firewall that does not explicitly drop an incoming ssh attempt, but my INPUT policy setting is DROP, then will my firewall automatically stop all incoming ssh attempts (ie port 22).


1.
So, to put that another way. Given that that appears to be behind the inherent design (of iptables, and "Policy" settings) can I safely "assume" the Policy setting alone is really enough to stop unwanted connections?

2.
Would it be worthwhile (no matter what) to include a Drop All last rule, or would that just be an unnecessary thing?

3.
Same with ICMP fragments and SYN floods etc. If I do not explicitly block them will the DROP Policy setting on INPUT be enough to stop them?


Regards,
boombaby
_

MensaWater 09-10-2018 01:33 PM

In a chain the rules are read from top to bottom. Once something matches a rule it doesn't check further rules.

On RHEL/CentOS systems (prior to 7 which uses firewalld as a front end to iptables) the default input chain always ended with a rule like:
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

That rule essentially says to reject everything. If none of the rules above that explicitly did an ACCEPT for given traffic (e.g. port 22, port 443 etc..) it meant it wasn't allowed because it wouldn't match any of those so would go to that final rule that matches everything and be rejected.

More than one user has mistakenly added rules to the input chain below that rule and wondered why they didn't work. It is because the REJECT rule matches everything so when it gets there it never gets to following rules.

boombaby 09-10-2018 10:43 PM


Thanks, MensaWater...


Although I am not skilled in profressional Security, I was pretty sure that I can do things that way - insert that as a last rule. (Thanks for the explicit.)


However, if the POLICY setting works (as implied) then I should not need to have an explicit rule to stop port-x (ie "x" meaning a specific port, say port-22). If there is no match in the rules "above" then the Policy will stop it dead, right?

This info here...

https://www.digitalocean.com/communi...firewall-works

...(towards the bottom) probably confirms what I set out to know. I guess I just want to hear from Members/Gurus/Experts with good understanding/experience in security issues to - either - confirm belief - or advise further.


As background to my thinking, here's why I ask and want to confirm/deny what appears to be in the design... ...I don't want to add rules if they aren't necessary. I don't want "fancy"; I want "working". It's a KISS (Keep It Simple Sweetheart) approach.


If my (iptables-based) firewall Policy is to DROP anything not explicitly matching a rule then WILL that ("Policy") approach stop port-x (say port-22, SYN flood, etc)?


Here's a further thought, and question...

If, when I visit a webpage/website, I let an external system have access to my system via http and "website" requirements (ie like, but not necessarily: FTP for downloads; flash, etc) then can that also give the external site (rather, an "evil" Player) the ability to "insert" inherited access through ports, like port-x (possibly a port controlled using a localhost-derived type of port punched back OUT of the firewall) ? Is that a real possibility and threat? [Yes; I know that's a bit complicated as a question, but if that's sorted out then perhaps I can keep my firewall simple.]

Anyway, thanks so far.



Regards,
boombaby
_

boombaby 09-12-2018 05:55 AM

Neat, speedy. Is there an explanation, or just a smart statement like that?

Actually, it would be nice to get an answer to the questions.

Regards,
boombaby
_

kirukan 09-12-2018 11:00 AM

Iptable is more on layer 3 - layer 4 firewall, it doesn't have ability to understand the application (layer 7) traffic.

boombaby 09-12-2018 12:10 PM


Thanks, kirukan...

I am pretty sure I understand what you mean, but I don't have the technical knowledge to know (exactly) how the layers TRULY apply in relation to actual application of iptables as a firewall.

However, you seem like a/the person who can get to the bottom of my enquiry, and help me sort it out.

So rather than talk in technical and theoretical terms, here is a practical, basic, iptables firewall...

Quote:

TEST

iptables -L -v

Chain INPUT (policy DROP 1287 packets, 155K bytes)
pkts bytes target prot opt in out source destination
69 2760 DROP all -- any any anywhere anywhere ctstate INVALID
843K 957M ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED
625 39208 ACCEPT all -- lo any anywhere anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 753K packets, 84M bytes)
pkts bytes target prot opt in out source destination


According to the iptables Policy settings and the few rules involved - and the "theory" - it should stop anything unwanted at a fundamental level. Is that right?


So, it - because of the DROP policy setting - should stop attempts coming IN on port 22, telnet, SYN attacks, etc. Right?

As well, it - because of the localhost rule - should allow OUT port 22 and telnet (etc.) as required by programs (applications). Right?

If at the fundamental level, that is correct then my (follow-up) concern would be that programs (Applications) with a particular devious "twist" (let's say) can be made to punch holes back out of the firewall for nefarious purposes. Right?


So, see, I am trying to confirm just how good such a simple firewall is, as well as iptables themselves. Your advice, hopefully backed by knowledge and experience, would be much appreciated.


Regards,

boombaby
_

boombaby 09-14-2018 10:29 PM


Hello,

Rather than seeking "opinion" on this question I saw it as too important for security to just get answers from "studs". I was hoping that some of the very senior members and gurus - with good, extensive knowledge and practical experience - would jump in to answer. Well, I need you know.

Yes; I can read Man Pages and web links for hours, but I don't think they can go to the crux of my question.

Without taking away from the previous points & questions (esp. in post # 6) let me also try to re-word the info...

I believe that in building an iptables-based firewall I could explicitly block usage of ports and so forth "up front" in the rules, while also having a DROP policy as final fallback position. In the simple example I gave in post #6 external attempts to connect to port 21, 22 and others should be "DROPPED" (ie on the Policy setting, not a rule). Given iptables "theory" that will work.

So, in my attempt to keep it simple THAT would be a firewall!

However, if the answer is "nope", and that I must block such ports "explicitly" with a rule then wouldn't I have to block the thousands of other ports explicitly too?

See, now, why I am trying to keep it simple?

See, now, why I ask for your advice (ie experience & knowledge) in assistance?

So, anyone got that real experience and understanding? Please, step forward! I need you now. (And, P.S., I don't really mind if you are a linux stud - so long as you've got the experience.) (...with Linux.)


Regards,

boombaby
_


All times are GMT -5. The time now is 06:25 AM.