LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 06-10-2011, 03:23 PM   #16
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,897

Rep: Reputation: 578Reputation: 578Reputation: 578Reputation: 578Reputation: 578Reputation: 578

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.
Old 06-10-2011, 05:34 PM   #17
tobyl
Member
 
Registered: Apr 2003
Location: uk
Distribution: slackware current
Posts: 767

Rep: Reputation: 60
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.
Old 06-10-2011, 09:03 PM   #18
marnold
Member
 
Registered: Dec 2005
Distribution: Slackware64 14.2 with AlienBob's KDE5
Posts: 277

Rep: Reputation: 39
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.
 
Old 06-10-2011, 10:34 PM   #19
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367

Rep: Reputation: 841Reputation: 841Reputation: 841Reputation: 841Reputation: 841Reputation: 841Reputation: 841
Quote:
Originally Posted by marnold View Post
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.
 
Old 06-20-2011, 03:15 AM   #20
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 264

Original Poster
Rep: Reputation: 74
Quote:
Originally Posted by tobyl View Post
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
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.
Old 06-20-2011, 05:57 AM   #21
tallship
Member
 
Registered: Jul 2003
Location: On the Beaches of Super Sunny Southern San Clemente, California USA
Distribution: Slackware - duh!
Posts: 534
Blog Entries: 3

Rep: Reputation: 118Reputation: 118
Thumbs up

Quote:
Originally Posted by Penthux View Post
For how long do you basically think this "bloody great big hole" will be a security risk, exactly? And be precise...
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:

Quote:
"...bloody great big hole"
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.
Old 06-20-2011, 08:32 AM   #22
kikinovak
MLED Founder
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,433

Rep: Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085
Quote:
Originally Posted by tallship View Post
That's just my way of offering constructive criticism for your lack of social skills
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.
Old 06-20-2011, 10:01 AM   #23
tallship
Member
 
Registered: Jul 2003
Location: On the Beaches of Super Sunny Southern San Clemente, California USA
Distribution: Slackware - duh!
Posts: 534
Blog Entries: 3

Rep: Reputation: 118Reputation: 118
Cool

Quote:
Originally Posted by kikinovak View Post
If, by "social skills", you mean...
Nope.

I mean:

Quote:
Originally Posted by Penthux View Post
For how long do you basically think this "bloody great big hole" will be a security risk, exactly? And be precise...

<edit>
You're not looking at the script itself here, you're looking at the crontab entry. The issue you're pointing out is the time delay between the firewall stopping and starting. Would you really like to know how long it takes for the firewall to stop/restart on my box? It's approx' 20 milliseconds. Admittedly that's on a dual core system with 2GB RAM, so it isn't a slow machine. Even so, if it took as long as 5 seconds to stop and start do you seriously think that constitutes "poking a bloody great big hole" in the firewall? If all the Dark Lords of Hacking in Europe got together for a "hacking Penthux's linux box conference", and they actually had my IP address, do you think giving them 15 minutes to brute-force a login would be very successful?

I believe the true issue here is that you're trying to "poke a bloody great big hole" in our whole rc.firewall setup.
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.
Old 06-20-2011, 10:26 AM   #24
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Blog Entries: 4

Rep: Reputation: Disabled
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.
Old 06-20-2011, 10:48 AM   #25
pwc101
Senior Member
 
Registered: Oct 2005
Location: UK
Distribution: Slackware
Posts: 1,847

Rep: Reputation: 128Reputation: 128
How will this play with fail2ban, which dynamically changes rules based on logfile analysis?
 
Old 06-20-2011, 11:50 AM   #26
dimm0k
Member
 
Registered: May 2008
Location: Brooklyn ZOO
Distribution: Slackware64 14.2
Posts: 514

Rep: Reputation: 53
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?
 
Old 06-20-2011, 02:14 PM   #27
kikinovak
MLED Founder
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,433

Rep: Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085
KISS solution: don't restart the firewall. Leave it running
 
Old 06-21-2011, 04:00 AM   #28
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 264

Original Poster
Rep: Reputation: 74
Quote:
Originally Posted by dimm0k View Post
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?
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 ----------

Quote:
Originally Posted by pwc101 View Post
How will this play with fail2ban, which dynamically changes rules based on logfile analysis?
No idea, you'd have to test and post your results.
 
Old 06-21-2011, 04:02 AM   #29
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 264

Original Poster
Rep: Reputation: 74
Quote:
Originally Posted by 55020 View Post
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.
I totally agree.
 
Old 06-21-2011, 04:12 AM   #30
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 264

Original Poster
Rep: Reputation: 74
Quote:
Originally Posted by tallship View Post
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,
When constructive criticism becomes a metaphor I try to focus on the productive and ignore the superfluous.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Firewall logging Zero187 Linux - Software 2 06-01-2009 02:39 PM
Logging in and logging out of a server in a script frankie_DJ Linux - Newbie 4 01-28-2007 12:03 AM
Firewall logging jakev383 Linux - Networking 2 12-08-2005 09:17 AM
slackware 9.1 firewall script fiftybucks Linux - Networking 0 06-21-2004 11:48 AM
slackware's /etc/rc.d/rc.firewall equivalent ||| firewall script startup win32sux Debian 1 03-06-2004 10:15 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

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

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration