I don't see the point of checking to see if it's still set to be executable. Surely anyone who had a legitimate reason for stopping it would know how to re-start it?

1 members found this post helpful.

Penthux

I think GazL made a fair point, which you took to heart. He did not criticize your contribution other than point out a potential flaw in the 10 minute restarts, which you have to admit is non standard for a firewall. You could have taken his comment a bit more constructively yourself if I may be so bold. Is there any reason why your firewall would not work effectively without the restarts? If so, your response might have been - 'well if you dont like the cron job, run it without that feature'.
Your post was generally well received, so take credit where it is due, and try to see comments as positive rather than negative criticism when possible!

tobyl

1 members found this post helpful.

Back to the script itself, would there be a simple way to adjust it for use with DHCP instead of a static IP? My son is getting a laptop and going off to school so he obviously will not always be connecting to our network here.

The problem with iptables is that it only resolves DNS entries initially and never again. Therefore, if you use a service like DynDNS, the IP will be right when the rules are initially loaded, but not refreshed until they are again reloaded (which, as GazL points out, can temporarily leave you prone to attack). Having the script re-run every 10 minutes as initially stated will allow a DynDNS setup to be feasible (provided you're willing to possibly wait 10 minutes to have to access the box if your IP changes), but introduces other security issues. I'm not sure of a good solution to this problem.

Thanks for the reply,

Yes, there is a miniscule gap, when the firewall would be down, which sees the firewall flushed. It is almost impossible to login for the duration there would be no firewall. There's no real reason why you should add it to your crontab, as I did. It will run perfectly well without the crontab entry. I'm just making sure it's always up and running by putting it in crontab.

I don't mind criticism, tobyl. I love it. GazL just came across as, "this is bloody useless it's got a bloody great hole in it. you're going to have to rethink the whole idea" to me and I responded in that manner. My fault, I know.

I'm not looking for credit, as there's not just myself involved. I simply wanted to share our efforts with the Slackware comminuty.

0 members found this post helpful.

Wow. Dude. That was harsh.

Not even kewl for the other readers who might not grasp the gravity of what he said, and which you categorically dismissed based upon your 20ms gaping hole (repeating every ten minutes with regularity too).

I think that's *precise* enough, yet perhaps only for the hardware you're running on. The *Gaping Hole* might exist for much longer durations on other peoples machines.

Gazl is absolutely, and unequivocally correct.

Your cronjob, when coupled with the way in which your firewall script inits, creates a:

It's not a tiny hole - it is a "bloody great big hole", meaning, The machine is wide open like a high schooler first timing on vodka and orange juice.

Now, how significant is that? Like Gazl indicated, probably not that big a deal for a casual surfer at an Internet Cafe.

But the facts are that they hand out awards at Black Hat events for pw3n'ing NASA and NIST boxes. 20ms is... Oh, about 1/12th the distance of the round trip between an earth station and a geostationary satellite - Not very far at all for someone with an army of irc war bots that control thousands of machines.

Are you going to simply dismiss, because it is not the most likely scenario, that all the Dark Lords of Hacking in Europe aren't actually getting together at this very moment for a "hacking adopters of Penthux's firewall killing cronjog conference"?

Such would not be wise. Indeed, maybe even foolish to assume it would never happen.

You might as well just pop your mail from 110 or better yet, why not use telnet on 23 to admin all your boxes - because it's really not that **Likely** that someone would think that anyone could be stupid enough to manage forward facing hosts with shells from telnet seesions on the open internet!

Okay now that I have your arrogantly begrudging attention, let's talk about a couple of other things. First, that of course I didn't have much concern for the complete lack of firewall whatsoever for X period of time when someone runs your cronjob (Yes, that does indeed meet the definition of a "bloody great big hole").

My concern, in contrast to that which Gazl focused on, was the issue with whacking the stats - the complete reset. I thought that was just... Well, I won't say anything overtly negative, and although it might just be me, but I tend to like looking at live data.

You only succeeded in pointing one thing out of any relevance here: That people who powerpost several times a day might miss the mark when it comes to the conveyance of their message.

After all, they're going pretty fast. I can recall a few occasions where Gazl (myself, and many others too), made a post to help someone, and when I looked at it noted, "Oh that's not really the problem, he missed it because he didn't take enough time to really see what the OP was saying" - even then, I will note that he (or whomever else powerposted) usually had some tidbit that I said, "Now that's pretty kewl, and even though it doesn't pertain directly to the matter at hand, I'm adding that to my arsenal of tools for later!".

It's a real shame you missed that opportunity Penthux. It truly is.

You see, what you could have taken his constructive criticism to task on was in soliciting other kewl ideas for what your cronjob was hastily attempting to accomplish - thereby improving even more, an already sweet little ditty you've whupped out.

Things like, how 'bout writing to a PID file and then... (Yah, don't even go there dude, we already know that's not ideal). Or the use of cgroups - a very elegant solution that I use myself in place of some of those other methods.

But no. you flamed someone trying to offer you support and most all of the posts to this thread since have been a bit soured as a result of your condescension.

@Gazl: I've actually got a bone to pick with you too here. When a firewall is completely OFF, we call that a "bloody great big hole".

Why would you, for the sake of civility with an ungrateful and arrogant scripter, risk the potential security of those less aware than you, by retracting a true statement, and further, saying it wasn't so, when it was?

Shame on you too (but only a little bit) Next time, please, just offer your condolences and move on - because you were right to point that out (It doesn't even matter how insignificant the time slice was), and retracting what you said was more a disservice to n00bs than a service to the decorum of the forums.

Just my here, but still, someone taking offense at the way in which you bring up a point is no reason to retract a valid point.

I hope that helps, And I hope you don't take my post too personally either Penthux - That's just my way of offering constructive criticism for your lack of social skills

Kindest regards,

2 members found this post helpful.

If, by "social skills", you mean posting messages with a maximum of bold and underlined text, spiced with the occasional red and blue colored font and vaguely appropriate smileys then I can only second your opinion.

1 members found this post helpful.

Nope.

I mean:

But thaqt's okay kikinovak, because I didn't intend for the post to be understood necessarily by anyone but the OP and Gazl.

Thanks anyway though

Kindest regards,

0 members found this post helpful.

It is misleading to focus exclusively on the time taken to 'login'. For one thing, it only needs the first SYN of the 'login' exchange to occur in the '20ms' window of vulnerability; after that, the rest of the login can take all the time in the world, thanks to the rule "$IPX -AINPUT -m state --state ESTABLISHED,RELATED -j ACCEPT". Besides, the old 'Ping of Death' showed that vulnerability can be a matter of a single packet, and there are far more protocols than just SSH (which is why $IPX is a poor choice of variable name, btw).

Additionally, do the maths: 20ms vulnerabilty every ten mins adds up to more than 17 and a half *minutes* of vulnerability in a year. It's nowhere near 'five nines' reliable, and it's not failsafe. Furthermore, history shows that a theoretical timing vulnerability can usually be made into an effective practical attack vector. An attacker can *engineer* the window of opportunity to be larger (for example, by throwing a massive load of traffic at the host just prior to the ten minute reload, which comes at conveniently predictable times six times an hour 24/7).

If the window of opportunity is not necessary (and in this case it definitely isn't necessary) then best practice is that it should be closed. Whilst that may not be one's own choice for one's own system, nevertheless it's best practice to follow best practice when sharing with the community. That also goes for accepting peer review comments - even the rude ones.

1 members found this post helpful.

How will this play with fail2ban, which dynamically changes rules based on logfile analysis?

Trying to grasp the concept of it all... is the reason for the cron job to "restart" the firewall to account for when the system receives a new IP address? Are there other instances where the firewall would need to be restarted?

KISS solution: don't restart the firewall. Leave it running

Hi dimm0k. It's no big deal really. If you didn't add the cronjob the firewall would run just fine. I added it as an afterthought and I'm in no way concerned about the "bloody great hole" it creates for a fraction of a second. There's no reason why you should want to restart the firewall once it's running. The only instance where you would need to stop/start the firewall is if you changed the code or config and needed to apply it.

---------- Post added 2011-06-21 at 09:01 ----------

No idea, you'd have to test and post your results.

I totally agree.

When constructive criticism becomes a metaphor I try to focus on the productive and ignore the superfluous.