LinuxQuestions.org
Help answer threads with 0 replies.
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-06-2011, 05:15 PM   #1
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 37

Rep: Reputation: 13
Slackware rc.firewall (with logging) script


A friend, and myself, decided to fool around making a good quality, totally configurable, firewall script for Slackware, which also logs incoming dropped packets.

Just copy the code below into your favourite text editor and save the file as rc.firewall then copy it into your /etc/rc.d/ directory (as root user).

After setting up the config section in the script, run these commands;
chmod 755 /etc/rc.d/rc.firewall
/etc/rc.d/rc.firewall start

Voila!

Code:
#!/usr/bin/bash

#############################################
#
# Slackware rc.firewall 1.1 - June 5, 2011
# by: Aal     [aal<at>chickencatcher.co.uk]
#     Penthux [junk<at>penthux.net]
#     Copyright 2005-2011
#
# enjoy!
#
# This script is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version. See the GNU General Public License 
# for more details. <http://www.gnu.org/licenses/>
#
#############################################

# Enter the necessary details in the System Firewall Configuration.
# Check these settings carefully. Misconfiguration means, NO FIREWALL!

#########################################
##### System Firewall Configuration #####

## Specify your server LAN IP [not localhost] and eth* ID
SERVER_IP="192.168.4.11"
NIC_ID="eth0"

## Enable DROPPED packets logging
#  Set this to LOGGING_DROP=0 if you don't need logs [ON is default].
LOGGING_DROP=1

## Use colour text output 0=OFF / 1=ON [ON is default]
USE_COLOUR=1

## Specify ALLOWED / TRUSTED IP Adresses
#  IP's or IP ranges added here are auto added to each service.
# 
#  Enter the ALLOWED IP range of your local network. 
local_network_range="192.168.0.1/24"

#  Enter any IP's which you want to ALLOW access.
#  Change the var values if you need to and make sure you address 
#  them properly.
my_ip1="10.20.30.40" 		# Change all these IPs to suit your own.
my_ip2="50.60.70.80"		# Create and delete new vars as needed.
my_ip3="90.100.110.120"
myaccess="${my_ip1} ${my_ip2} ${my_ip3}"

my_home="11.12.13.14"
my_office="15.16.17.18"
son_college="19.20.21.22"
my_mate_frank="23.24.25.26"
myremote="${my_home} ${my_office} ${son_college} ${my_mate_frank}"

my_timesrv="80.80.80.80"	# ntp server IP address, for example.
ntp_ip="${my_timesrv}"

## TRUSTED Access Groups

# GLOBAL Trusted Groups
# ** This is generally only IP's on your LAN **
group_trusted="$local_network_range"

# Trusted SSH Groups
# Access: incoming ssh (port 22)
group_ssh="$myaccess $myremote"

# Trusted FTP Groups
# Access: incoming ftp (port 21/20)
group_ftp="$myremote"

# Trusted HTTP Groups
# Access: incoming webserver (port 80)
group_http=""

# Trusted VNC Groups
# Access: incoming vnc (port 5969)
group_vnc="$myaccess"

# Trusted Samba Groups [Network Sharing]
# Access: incoming samba (port 137, 138, 139, 445)
group_samba=""

# Trusted NTP Groups
# Access: incoming ntp requests (port 123)
group_ntp="$ntp_ip"

##### End of System Firewall Configuration #####
################################################

## Use IPTABLES
IPX=iptables

## Firewall text output settings
if [ $USE_COLOUR -eq 1 ]
then 
 # Colour text output
 PREFIX="\e[1;34mFirewall: \e[00m"
 MSG_ALERT="\e[1;31m** WARNING! ** \e[00m"
 MSG_USAGE="${PREFIX}\e[37mUsage: $0 { start | stop | restart } \e[00m"
 MSG_BOOT="${PREFIX}\e[1;32mInitialising. \e[00m"
 MSG_START="${PREFIX}\e[32mFirewall is now \e[1;32mACTIVE \e[0;32mon\e[1;34m `hostname` \e[0;32m[\e[1;34m${SERVER_IP}\e[0;32m]. \e[00m"
 MSG_STARTING="${PREFIX}\e[32mLoading Firewall rules... \e[00m"
 MSG_STOP="${PREFIX}${MSG_ALERT}\e[31mFirewall is now DISABLED! \e[00m"
 MSG_STOPPING="${PREFIX}\e[32mFlushing Firewall rules... \e[00m"
 MSG_RESTART="${PREFIX}\e[1;32mRestarting... \e[00m"
 MSG_VERSION="${PREFIX}\e[37mSlackware rc.firewall 1.1 by Aal & Penthux - Copyright 2005-2011. \e[00m"
 MSG_LOGGING_DROP="${PREFIX}\e[32mDropped packages logging: \e[1;32mENABLED! \e[00m"
else
 # Standard text output
 PREFIX="Firewall: "
 MSG_ALERT="** WARNING! ** "
 MSG_USAGE="${PREFIX}Usage: $0 { start | stop | restart } "
 MSG_BOOT="${PREFIX}Initialising."
 MSG_START="${PREFIX}Firewall is now ACTIVE on `hostname` ${SERVER_IP}. "
 MSG_STARTING="${PREFIX}Loading Firewall rules... "
 MSG_STOP="${PREFIX}${MSG_ALERT}Firewall is now DISABLED! " 
 MSG_STOPPING="${PREFIX}Flushing Firewall rules... "
 MSG_RESTART="${PREFIX}Restarting... "
 MSG_VERSION="${PREFIX}Slackware rc.firewall 1.1 by Aal & Penthux - Copyright 2005-2011. "
 MSG_LOGGING_DROP="${PREFIX}Dropped packages logging: ENABLED! "
fi

## This function flushes the currently active firewall
function stop {
  #stop
  ## Change the system policy to ACCEPT everything.
  $IPX -PINPUT ACCEPT
  $IPX -POUTPUT ACCEPT
  $IPX -PFORWARD ACCEPT
  $IPX -t nat -PPOSTROUTING ACCEPT
  $IPX -t nat -PPREROUTING ACCEPT
  $IPX -t nat -POUTPUT ACCEPT

  ## Empty all previously set firewall rules.
  $IPX -F
  $IPX -X
}

### This function defines firewall rules and activates them
function start {
  #start
  echo -e "${MSG_BOOT}\n${MSG_STARTING}"
  #### Defining firewall rules.
  ## ACCEPT everything from localhost
  $IPX -AINPUT -i lo -j ACCEPT

  ## DROP packets which are invalid
  $IPX -AINPUT -m state --state INVALID -j DROP

  ## ACCEPT all incomming connections from connections made by ourselves
  $IPX -AINPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

  ##### Create TRUSTED member Group
  ##  Members: Group 'trusted'
  $IPX -Ntrusted
  for line in ${group_trusted} ; do $IPX -Atrusted -s $line -j ACCEPT ;done

  ### Create group: ssh
  ## Members: Group 'ssh' / 'trusted'
  $IPX -Nssh
  for line in ${group_ssh} ; do $IPX -Assh -s $line -j ACCEPT ;done
  $IPX -Assh -j trusted 	# add trusted to ssh

  ### Create group: ftp
  ## Members: Group 'ftp' / 'trusted'
  $IPX -Nftp
  for line in ${group_ftp} ; do $IPX -Aftp -s $line -j ACCEPT ;done
  $IPX -Aftp -j trusted 	# add trusted to ftp

  ### Create group: http
  ## Members: 'hhtp' / 'trusted'
  $IPX -Nhttp
  for line in ${group_http} ; do $IPX -Ahttp -s $line -j ACCEPT ;done       
  $IPX -Ahttp -j trusted 	# add trsuted to http

  ### Create group vnc
  ## Members: 'vnc' / 'trusted'
  $IPX -Nvnc
  for line in ${group_vnc} ; do $IPX -Avnc -s $line -j ACCEPT ;done
  $IPX -Avnc -j trusted 	# add trusted to vnc
  
  ### Create group: samba
  ## Members: 'samba' / 'trusted'
  $IPX -Nsamba
  for line in ${group_samba} ; do $IPX -Asamba -s $line -j ACCEPT ;done
  $IPX -Asamba -j trusted 	# add trusted to samba

  ### Create group: NTP
  ## Members: 'ntp' / 'trusted'
  $IPX -Nntp
  for line in ${group_ntp} ; do $IPX -Antp -s $line -j ACCEPT ;done
  $IPX -Antp -j trusted 	# add trusted to ntp

  ### Enable the rules for every group
  ## ssh
  $IPX -AINPUT -m state --state NEW -p TCP --dport 22 -j ssh

  ## ftp
  $IPX -AINPUT -m state --state NEW -p TCP --dport 21 -j ftp
  $IPX -AINPUT -m state --state NEW -p TCP --dport 20 -j ftp

  ## http
  $IPX -AINPUT -m state --state NEW -p TCP --dport 80 -j http

  ## vnc
  #$IPX -AINPUT -m state --state NEW -p TCP --dport 69 -j vnc
  $IPX -AINPUT -m state --state NEW -p TCP --dport 5969 -j vnc

  ## samba
  $IPX -AINPUT -m state --state NEW -p UDP --dport 137 -j samba
  $IPX -AINPUT -m state --state NEW -p UDP --dport 138 -j samba
  $IPX -AINPUT -m state --state NEW -p TCP --dport 139 -j samba
  $IPX -AINPUT -m state --state NEW -p TCP --dport 445 -j samba

  ## ntp
  $IPX -AINPUT -m state --state NEW -p TCP --dport 123 -j ntp

  ### REJECT packets on port 113 (identd)
  ## This is because we don't want any identd timeouts.
  $IPX -A INPUT -p TCP --dport 113 -j REJECT

  ### Now all the rules have been enabled, put the policy on DROP
  $IPX -PINPUT DROP
  $IPX -POUTPUT ACCEPT
  $IPX -PFORWARD DROP

##### Dropped packet logging parameters
if [ $LOGGING_DROP -eq 1 ]
then
  ### Log DROPPED packages
  LOGLIMIT="2/s"
  LOGLIMITBURST="10"
  $IPX -N LOGDROP
  $IPX -A LOGDROP -p tcp -m limit --limit $LOGLIMIT --limit-burst $LOGLIMITBURST -j LOG --log-prefix "FIREWALL :Denied TCP: "
  $IPX -A LOGDROP -p udp -m limit --limit $LOGLIMIT --limit-burst $LOGLIMITBURST -j LOG --log-prefix "FIREWALL: Denied UDP: "
  $IPX -A LOGDROP -p icmp -m limit --limit $LOGLIMIT --limit-burst $LOGLIMITBURST -j LOG --log-prefix "FIREWALL: Denied ICMP: "
  $IPX -A LOGDROP -f -m limit --limit $LOGLIMIT --limit-burst $LOGLIMITBURST -j LOG --log-prefix "FIREWALL: Denied FRAGMENT: "
  $IPX -A INPUT -p icmp -i $NIC_ID -j LOGDROP
  $IPX -A INPUT -p udp -i $NIC_ID -j LOGDROP
  $IPX -A INPUT -p tcp -i $NIC_ID -j LOGDROP
  echo -e "${MSG_LOGGING_DROP}"
fi
}

#### Firewall Commands: rc.firewall { start | restart | stop | version }
case "$1" in
  start)
    stop
    start
    echo -e "${MSG_START}"
    ;;
  stop)
    #stop
    echo -e "${MSG_STOPPING}"
    stop
    echo -e "${MSG_STOP}"
    ;;
  restart)
    #stop
    echo -e "${MSG_STOPPING}"
    stop
    echo -e "${MSG_STOP}"
    #restart
    echo -e "${MSG_RESTART}"
    start
    echo -e "${MSG_START}"
    ;;
  version)
    #version
    echo -e "${MSG_VERSION}"
    ;;
*)
    echo -e "${MSG_USAGE}"
    echo -e "${MSG_VERSION}"
esac

#
#eof <*>
I hope u all enjoy it! We did. :>
 
Old 06-06-2011, 06:39 PM   #2
bgeddy
Senior Member
 
Registered: Sep 2006
Location: Liverpool - England
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810

Rep: Reputation: 227Reputation: 227Reputation: 227
That's certainly interesting although I haven't really analysed it much yet. I have always tended to use the easy firewall generator script to generate a basic iptables script and then amend it to suit along with the marvellous work from Oskar Andreasson.

Your offering is interesting to me as I am interested in iptables scripts, especially those for gateways, routers and the like, so thanks for publishing. I must admit trawling through logs can be fascinating to see who's scanning my public ip address. So much so I have eventually turned off logging on my current, hardware-based, home router as these things can be kind of addictive and time consuming Thanks again.

Edit: After scanning I have just realised I misspelt who's and I'm a stickler for spelling (it was posted as "whose" - apologies from stupid me).

Last edited by bgeddy; 06-06-2011 at 07:33 PM. Reason: Avoid spreading idiocy.
 
Old 06-06-2011, 06:50 PM   #3
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 37

Original Poster
Rep: Reputation: 13
Quote:
Originally Posted by bgeddy View Post
I must admit trawling through logs can be fascinating to see whose scanning my public ip address.
That's mainly why we did it this way, bgeddy.

I'm well aware of the easy firewall generator script but there's nothing like a bit of D.I.Y. to keep the old grey matter awake.

Thanks for your kind comments. It's what makes the sharing worthwhile.
 
Old 06-07-2011, 05:26 PM   #4
mike_booth76
LQ Newbie
 
Registered: May 2006
Posts: 17

Rep: Reputation: 3
Nice piece of work. THanks for sharing.

Up the Boro.


Mike
 
Old 06-08-2011, 01:15 AM   #5
tallship
Member
 
Registered: Jul 2003
Location: On the Beaches of Super Sunny Southern San Clemente, California USA
Distribution: Slackware - duh!
Posts: 520
Blog Entries: 3

Rep: Reputation: 112Reputation: 112
Thumbs up Great treatment on the implementation of a bastion.

Well @Penthux, I like the flow of what you've done there

I'm kinda with bgeddy with respect to what I usually do - and that's use the Easy firewall gen script HERE that Eric adapted, and take it from there.

Nowadays I have a very customized variant of that, with things I turn off and on, and although I've got a couple of unmaintained variations for use in routers and such, I never use them anymore, as I've completely left the Linux camp for that type of purpose built enterprise (or home) firewalling.

I only bastion fwall my Linux machines nowadays. I've gone back to BSD for serious firewall routers, opting instead for pfSense.

Yet I can indeed see that I want to incorporate a substantial portion of your script into my bastions on Linux

Thanks and great work - even if it was just an excercise in gray matter aerobics

Kindest regards,
 
Old 06-08-2011, 03:58 AM   #6
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
I'm willing to try this, has it been tested much ? I've tested the EFG for a while and it works well.
 
Old 06-09-2011, 12:51 AM   #7
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 37

Original Poster
Rep: Reputation: 13
Quote:
Originally Posted by H_TeXMeX_H View Post
I'm willing to try this, has it been tested much ? I've tested the EFG for a while and it works well.
Hi, and thanks to you all very much again for your comments and feedback.

Well, TexMex, I have been running variations of this rc.firewall code since March/April 2005. It works, and has always worked, flawlessly. When I was a Slackware newbie, and very green about security, I ran my box without any form of firewall what-so-ever. Which was fine for about 3 months until I got home one day to find my hard drives trashed and command prompt barely functioning. We learn quickly in this game, don't we? So, that's the reason why this rc.firewall script initially came into being. Over the years it's been modified and changed, for multiple reasons, and has never let me down. So, yes, I guess you could say it has been tested _much_ and thoroughly.

I forgot to mention in my OP about putting an entry in crontab to make sure the firewall is active constantly. Here's my crontab line, which I simply added at the end of the hourly, daily, weekly, (etc) entries:

Code:
#
# Check that the rc.firewall is active every 10 minutes:
*/10 * * * * /etc/rc.d/rc.firewall start
I'm absolutely certain, beyond all doubt, when the settings are configured properly this rc.firewall script will perform it's duty perpetually and perfectly. I hope it impresses you, as much as it has gained my admiration over the years I've been running it. :>

Thanks, once again.
 
1 members found this post helpful.
Old 06-09-2011, 11:56 AM   #8
marnold
Member
 
Registered: Dec 2005
Distribution: Slackware64 14.1
Posts: 255

Rep: Reputation: 32
Thanks, Penthux! I was looking for something like this. Up to this point I've basically been relying on my router's firewall to block anything, but it hasn't had a firmware update in a long time and that's making me jumpy. It'll be interesting to see if anything gets logged. I assume that everything goes to syslog like normal, right? My scripting skillz leave a little something to be desired, so I'm not the best as deciphering what you wrote.

*Edit* After trying to ping my box from my laptop I discovered that, yes, they go to syslog.

Last edited by marnold; 06-09-2011 at 12:05 PM.
 
Old 06-09-2011, 02:12 PM   #9
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 37

Original Poster
Rep: Reputation: 13
Quote:
Originally Posted by marnold View Post
Thanks, Penthux! I was looking for something like this. Up to this point I've basically been relying on my router's firewall to block anything, but it hasn't had a firmware update in a long time and that's making me jumpy. It'll be interesting to see if anything gets logged. I assume that everything goes to syslog like normal, right? My scripting skillz leave a little something to be desired, so I'm not the best as deciphering what you wrote.

*Edit* After trying to ping my box from my laptop I discovered that, yes, they go to syslog.
Thanks marnold, and you're quite correct, as you now know. Everything gets logged to /var/log/syslog for your viewing pleasure. My logs are set on daily rotation so they are easier to manage. I must admit, there's quite some activity going on in those logs which I was previously unaware of. So, the hours we spent modifiying the rc.firewall script code (e.g. adding the logging) has paid off enormously. I'm not too concerned at the fly-by attempts to get to the login prompt on my box, but if anybody should spoof an allowed IP and attempt to brute-force their way past my security, the logs would certainly reflect that. As yet, all attempts to gain access via disallowed IPs have failed. They just get dropped and for the user (or robot) at the other end it looks like my box doesn't even exist. I'm strongly encouraged by our rc.firewall and it's another reason why I decided to go public with it. It's not the best, that I'm sure, but it's damned good enough for private users like myself. :>
 
Old 06-10-2011, 04:47 AM   #10
GazL
Senior Member
 
Registered: May 2008
Posts: 3,328

Rep: Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884
Quote:
Originally Posted by Penthux View Post
Code:
#
# Check that the rc.firewall is active every 10 minutes:
*/10 * * * * /etc/rc.d/rc.firewall start
You might want to re-think that.

Take a look at your firewall script. 'rc.firewall start' will run the stop function and then the start function.
'stop' will set all policies to ACCEPT and flush all rules. So what you're essentially doing is poking a bloody great hole, however briefly, in your firewall once every 10 minutes.

You'll also wipe-out the statistics every 10 minutes, but that's a lesser issue.
 
2 members found this post helpful.
Old 06-10-2011, 08:57 AM   #11
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 37

Original Poster
Rep: Reputation: 13
Quote:
Originally Posted by GazL View Post
You might want to re-think that.

Take a look at your firewall script. 'rc.firewall start' will run the stop function and then the start function.
'stop' will set all policies to ACCEPT and flush all rules. So what you're essentially doing is poking a bloody great hole, however briefly, in your firewall once every 10 minutes.
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. The IPTABLES part of the script has been running for over 5 years, GazL. it's never broken and it's never failed. Thanks for your opinion and valuable advice. But honestly, I think you're trying to make a pin-hole seem like a black hole! That's not very helpful or constructive. I love criticism but what you're saying is very, VERY, exaggerated indeed.

The time between the firewall stopping and starting is the blink of an eye. I welcome anybody to try and break their way into my server within that time-frame.

Last edited by Penthux; 06-10-2011 at 10:30 AM.
 
0 members found this post helpful.
Old 06-10-2011, 10:11 AM   #12
GazL
Senior Member
 
Registered: May 2008
Posts: 3,328

Rep: Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884
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...
Long enough to allow a connection through, and that's all that is relevant. If you want to play peekaboo through your firewall then that's entirely your choice.
 
3 members found this post helpful.
Old 06-10-2011, 10:40 AM   #13
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 37

Original Poster
Rep: Reputation: 13
Quote:
Originally Posted by GazL View Post
Long enough to allow a connection through, and that's all that is relevant. If you want to play peekaboo through your firewall then that's entirely your choice.
Yes, and that would be just 1 connection and unless they can login in that instant with the correct details, the next time they would try their IP would get dropped.

So, can you please elaborate on this "bloody great hole" theory please?
 
0 members found this post helpful.
Old 06-10-2011, 12:48 PM   #14
GazL
Senior Member
 
Registered: May 2008
Posts: 3,328

Rep: Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884
Quote:
Originally Posted by Penthux View Post
I believe the true issue here is that you're trying to "poke a bloody great big hole" in our whole rc.firewall setup.
I have no agenda, nor desire, nor motive to poke holes in anything.. I was simply pointing out a theoretical weakness that I spotted in relation to the interaction with the cronjob, in the belief I was being helpful. Silly me, I actually thought you'd appreciate the input.

Yes, calling it a "bloody great hole" was overstating it - frankly, I really didn't give the phrase all that much thought and didn't expect it to be given quite so much focus or taken quite so literally - I could have just as easily used any number of other phrases. I'll happily retract it and suggest "A tiny little hole" instead if it clears things up.

Take it how you will. I'll let my past posting history speak for my intentions. I'm done here.
 
1 members found this post helpful.
Old 06-10-2011, 01:37 PM   #15
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 37

Original Poster
Rep: Reputation: 13
Quote:
Originally Posted by GazL View Post
I have no agenda, nor desire, nor motive to poke holes in anything.. I was simply pointing out a theoretical weakness that I spotted in relation to the interaction with the cronjob, in the belief I was being helpful. Silly me, I actually thought you'd appreciate the input.

Yes, calling it a "bloody great hole" was overstating it - frankly, I really didn't give the phrase all that much thought and didn't expect it to be given quite so much focus or taken quite so literally - I could have just as easily used any number of other phrases. I'll happily retract it and suggest "A tiny little hole" instead if it clears things up.

Take it how you will. I'll let my past posting history speak for my intentions. I'm done here.
Thanks for explaining things GazL. Due to the purpose and function of our rc.firewall I take these matters very seriously and give them the upmost attention. People's Linux security depends on the stability, reliability and smooth operation of our work. When that is thrown into question it has to be judged and verified accordingly. When you say you didn't give your "bloody great hole" phrase much thought, I actually did. I spent time assessing and testing the time delay between stopping and restarting our firewall. I'm more than happy with the results of those tests.

Thank you, GazL, for casting a shadow of doubt where there was no justified reason(s) to have any doubts. I'm glad you're done here - frankly. Your posting history certainly speaks for itself, but I value quality, not quantity! ;-)

Last edited by Penthux; 06-10-2011 at 01:45 PM.
 
0 members found this post helpful.
  


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 01:39 PM
Logging in and logging out of a server in a script frankie_DJ Linux - Newbie 4 01-27-2007 11:03 PM
Firewall logging jakev383 Linux - Networking 2 12-08-2005 08:17 AM
slackware 9.1 firewall script fiftybucks Linux - Networking 0 06-21-2004 10:48 AM
slackware's /etc/rc.d/rc.firewall equivalent ||| firewall script startup win32sux Debian 1 03-06-2004 09:15 PM


All times are GMT -5. The time now is 12:20 PM.

Main Menu
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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration