LinuxQuestions.org - Generic Firewall script

Page 1 of 6

Show 50 post(s) from this thread on one page

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Generic Firewall script (https://www.linuxquestions.org/questions/slackware-14/generic-firewall-script-4175703560/)

mlangdn

11-13-2021 04:01 PM

Generic Firewall script

SCerovec asked about a generic firewall script in the suggestions for current thread. How about this? (Did't want to clutter the other thread, don't remember where I got them either for proper attribution.) I've used these for a long time.

firewall-start

Code:

#!/bin/sh



# Begin /bin/firewall-start



# Insert connection-tracking modules (not needed if built into the kernel).

#modprobe ip_tables

#modprobe iptable_filter

#modprobe ip_conntrack

#modprobe ip_conntrack_ftp

#modprobe ipt_state

#modprobe ipt_LOG



# allow local-only connections

iptables -A INPUT -i lo -j ACCEPT

# free output on any interface to any ip for any service

# (equal to -P ACCEPT)

iptables -A OUTPUT -j ACCEPT



# permit answers on already established connections

# and permit new connections related to established ones (eg active-ftp)

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT



# Log everything else: What's Windows' latest exploitable vulnerability?

iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "



# set a sane policy: everything not accepted > /dev/null

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT DROP



# be verbose on dynamic ip-addresses (not needed in case of static IP)

echo 2 > /proc/sys/net/ipv4/ip_dynaddr



# disable ExplicitCongestionNotification - too many routers are still

# ignorant

echo 0 > /proc/sys/net/ipv4/tcp_ecn



# If you are frequently accessing ftp-servers or enjoy chatting you might

# notice certain delays because some implementations of these daemons have

# the feature of querying an identd on your box for your username for

# logging. Although there's really no harm in this, having an identd

# running is not recommended because some implementations are known to be

# vulnerable.

# To avoid these delays you could reject the requests with a 'tcp-reset':

#iptables -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

#iptables -A OUTPUT -p tcp --sport 113 -m state --state RELATED -j ACCEPT



# To log and drop invalid packets, mostly harmless packets that came in

# after netfilter's timeout, sometimes scans:

#iptables -I INPUT 1 -p tcp -m state --state INVALID -j LOG --log-prefix \ "FIREWALL:INVALID"

#iptables -I INPUT 2 -p tcp -m state --state INVALID -j DROP



# End /bin/firewall-start

firewall-status

Code:

#!/bin/sh



# Begin /bin/firewall-status



echo "iptables.mangling:"

iptables -t mangle -v -L -n --line-numbers



echo

echo "iptables.nat:"

iptables -t nat -v -L -n --line-numbers



echo

echo "iptables.filter:"

iptables -v -L -n --line-numbers



# End /bin/firewall-status

firewall-stop

Code:

#!/bin/sh



# Begin /bin/firewall-stop



# deactivate IP-Forwarding

echo 0 > /proc/sys/net/ipv4/ip_forward



iptables -Z

iptables -F

iptables -t nat -F PREROUTING

iptables -t nat -F OUTPUT

iptables -t nat -F POSTROUTING

iptables -t mangle -F PREROUTING

iptables -t mangle -F OUTPUT

iptables -X

iptables -P INPUT ACCEPT

iptables -P FORWARD ACCEPT

iptables -P OUTPUT ACCEPT



# End /bin/firewall-stop

elcore

11-14-2021 02:05 AM

No idea how to make generic set of rules, I mean one could only accept :443 by default, and then get doom players complaining about :666 not being open.
There's always something not working with those generic setups, even if everything is forseen (unlikely) someone will go out of their way to create a new situation and corner case.
As for minimal set of client rules, and since :443 is the most common port these days, I'd just do something like this without complicating it too much:

Code:

IP0=example.ip.address.here

DNS0=example.dns-over-https.address.here



iptables  -F

iptables  -P FORWARD DROP



iptables -A INPUT -i lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT

iptables -A INPUT -p tcp -i eth0 -s $IP0 --sport 443 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -p udp -i eth0 -s $DNS0 --sport 443 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -j DROP



iptables -A OUTPUT -i lo -d 127.0.0.1 -s 127.0.0.1 -j ACCEPT

iptables -A OUTPUT -p tcp -o eth0 -d $IP0 --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A OUTPUT -p udp -o eth0 -d $DNS0 --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A OUTPUT -j DROP

.. and then I'd get complaints/tickets like, this random ftp server does not work, but "works on my phone".

Sure thing ftp is broken when not specified, these rules are designed to obviously break things. If you design rules to allow all things then it's not the most secure set of rules.
And some countries are known to enforce different rules, so it does not matter what generic firewall script will do and there is much potential for it to fail.
Not to mention there's also Slackware Server userbase who will all laugh at the rule which does not accept INPUT NEW, while it's a common source of trouble on clients.
So once again there will be conflict for no reason at all, as with all the other standard generic things which claim that one size fits all.

allend

11-14-2021 02:20 AM

Writing a firewall script is like making bolognese sauce, everybody has their own twist to achieve the perfect outcome.
So, I look at

Code:

# set a sane policy: everything not accepted > /dev/null

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT DROP

and think I prefer my

Code:

#######################################################################

echo -n "  Clearing any existing rules and setting default policy to DROP..."

#######################################################################

# Drop any packet coming into the box (INPUT)

$IPTABLES -P INPUT DROP

$IPTABLES -F INPUT

# Drop any packet going out the box (OUTPUT)

$IPTABLES -P OUTPUT DROP

$IPTABLES -F OUTPUT

# Drop any packet routing through the box (FORWARD)

$IPTABLES -P FORWARD DROP

$IPTABLES -F FORWARD

$IPTABLES -F -t nat



# Flush the user chain, if it exists

if [ -n "`$IPTABLES -L | $GREP drop-and-log-it`" ]; then

  $IPTABLES -F drop-and-log-it

fi



# Delete all User-specified chains

$IPTABLES -X



# Reset all IPTABLES counters

$IPTABLES -Z

that occurs at the top of script before adding any rules, because it more thoroughly washes the pots and pans before starting or restarting.

My 'drop-and-log-it' chain sends output to dmesg rather than a separate file as it maintains the sequence with other events.

Then there is the question of services that might best be opened by default.
As a network tool, ping can be very useful, but might be considered a security threat.
New users have a tough time with SSH, without the problem of a firewall blocking connection attempts.
One group of users might say CUPS should be open by default, so that all users on the LAN can access my USB connected printer. Others will say no need for that, so it should be closed by default.

Should there be example entries for NFS, Samba, SMTP, PXE, Icecream, media servers etc? Or could these be in separate files that are sourced by the rc.firewall script?

What about a laptop user who might use a wired connection, a wifi connection or a USB modem connection that require different firewall requirements?

I think the generic firewall is as simple as the universally perfect bolognese sauce.

SCerovec

11-14-2021 06:25 AM

Well, that's a start already!

I'd add hooks for pre-, -mid and post- rules, so the script has potential of seamless update without stomping out any custom rules (said game servers, samba or what have you)

Not as elaborate as <progname>.d/<numbered directory entries>, but the mere pre.<name>.sh post.<name>.sh and mid.<name>.sh scripts not shipped with but mentioned as comments in the main <name>.sh file, just like /etc/resolv.conf does for instance.

The <name> could be either firewall, iptables or something catchy instead (itc? (Ip Tables Configurator)).

The gorilla in the room is where we draw the line in the sand of what is generic?

I'd say kiosk mode usage case- a case that has nothing to be subtracted from and still be called a firewall.

mlangdn

11-14-2021 06:43 AM

@SCerovec - You said generic!

I do not do gaming, nor do I have mail servers or other special use stuff. You also said further use cases would require more reading and due diligence (paraphrased a bit...ok a lot :) ).

igadoter

11-14-2021 01:12 PM

If you want to put this into rc.firewall you will start/stop commands. Moreover what is missing is lack of indication that firewall is up. Say you can create lock file under /var. Or create fake process indicating running firewall.

Edit: If stat represents firewall statistics better put it into crontab and output to syslog. Just common place for any system information.

SCerovec

11-15-2021 12:54 PM

a skeleton:

rc.firewall:

Code:

#!/bin/bash



# The Generic Firewall Script:

#license: MIT

#



IPT=/usr/sbin/iptables

LCK=/var/lock/firewall.lock #TODO

PRE=rc.firewall_prestart

MID=rc.firewall_midstart

END=rc.firewall_poststart



# we assume all interfaces





# Insert connection-tracking modules (not needed if built into the kernel).

modprobe -v ip_tables

modprobe -v iptable_filter

modprobe -v ip_conntrack

modprobe -v ip_conntrack_ftp

modprobe -v ipt_state

modprobe -v ipt_LOG





# set $IPT to minimal drop and reject rules

function start() {

  echo "Rising the firewall..."

#check for exectutable rc.firewall_prestart

  if [ -x $PRE ]; then 

    echo "Preinitializing $IPT:"

    $PRE

  fi



  # allow local-only connections

  $IPT -A INPUT -i lo -j ACCEPT

  # free output on any interface to any ip for any service

  # (equal to -P ACCEPT)

  $IPT -A OUTPUT -j ACCEPT

  

  # permit answers on already established connections

  # and permit new connections related to established ones (eg active-ftp)

  $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

  

  # Log everything else: What's Windows' latest exploitable vulnerability?

  $IPT -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "



  #check for exectutable rc.firewall_midstart

  if [ -x $MID ]; then 

    echo "Additionally setting up $IPT:"

    $MID

  fi



  # set a sane policy: everything not accepted > /dev/null

  $IPT -P INPUT DROP

  $IPT -P FORWARD DROP

  $IPT -P OUTPUT DROP

  

  # be verbose on dynamic ip-addresses (not needed in case of static IP)

  echo 2 > /proc/sys/net/ipv4/ip_dynaddr

  

  # disable ExplicitCongestionNotification - too many routers are still

  # ignorant

  echo 0 > /proc/sys/net/ipv4/tcp_ecn

  

  # If you are frequently accessing ftp-servers or enjoy chatting you might

  # notice certain delays because some implementations of these daemons have

  # the feature of querying an identd on your box for your username for

  # logging. Although there's really no harm in this, having an identd

  # running is not recommended because some implementations are known to be

  # vulnerable.

  # To avoid these delays you could reject the requests with a 'tcp-reset':

  #$IPT -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

  #$IPT -A OUTPUT -p tcp --sport 113 -m state --state RELATED -j ACCEPT

  

  # To log and drop invalid packets, mostly harmless packets that came in

  # after netfilter's timeout, sometimes scans:

  #$IPT -I INPUT 1 -p tcp -m state --state INVALID -j LOG --log-prefix \ "FIREWALL:INVALID"

  #$IPT -I INPUT 2 -p tcp -m state --state INVALID -j DROP



  #check for exectutable rc.firewall_poststart

  if [ -x $END ]; then 

    echo "Finishing up setting up $IPT:"

    $END

  fi

  }





# clear $IPT to defaults

function stop () {

  echo "Lowering the firewall..."

  # clear iptables

  $IPT -Z

  $IPT -F

  $IPT -t nat -F PREROUTING

  $IPT -t nat -F OUTPUT

  $IPT -t nat -F POSTROUTING

  $IPT -t mangle -F PREROUTING

  $IPT -t mangle -F OUTPUT

  $IPT -X

  $IPT -P INPUT ACCEPT

  $IPT -P FORWARD ACCEPT

  $IPT -P OUTPUT ACCEPT

  }



# read the /var/run/* file's time stamps

function status () {

  echo "Checking the firewall..."

  # read the file attributes and echo them

  echo "$IPT.mangling:"

  $IPT -t mangle -v -L -n --line-numbers

  

  echo

  echo "$IPT.nat:"

  $IPT -t nat -v -L -n --line-numbers

  

  echo

  echo "$IPT.filter:"

  $IPT -v -L -n --line-numbers



  }



# unconditionally stop then start

function restart () {

  stop

  start

  }





# check how we're called and perform appropriate actions:

case $1 in

start)    start

  ;;

stop)    stop

  ;;

restart)  restart

  ;;

status)  status

  ;;

*)

    echo "Usage:"

    echo "    "$@" {start|stop|restart|status|usage}"

    echo "    to perfrom each respective action"

  ;;

esac

#

SCerovec

11-15-2021 12:58 PM

Quote:

Originally Posted by igadoter (Post 6301293)

A "running" firewall is not a "program" but rather a state of the system's gates:

A "raised firewall" means all incoming traffic is organized and sanely accounted for (DROP, LOG, whatever) instead of silently ignored (or worse yet - served).

Since there is nothing "running" there is nothing to crash either - one merely saws the branch he's sitting on (kind of literally) and has to come by foot to the machine and fix the error - or else everything works just fine more or less.

RadicalDreamer

11-15-2021 02:13 PM

Why use a generic firewall (someone will have to maintain it) instead of one of these like arno-iptables-firewall (run a script, answer questions, get a firewall) which has been around for at least about 2 decades, and is continually being updated? https://slackbuilds.org/result/?search=firewall&sv=14.2

https://github.com/arno-iptables-firewall/aif/
https://www.linode.com/docs/guides/c...ebian-5-lenny/

I wanted to ask this in the Current thread, why does Slackware need a firewall solution when computers are behind a router's firewall and there are easily installable firewalls available at slackbuilds?

FlinchX

11-15-2021 03:29 PM

At the risk of sounding cranky, may I ask what's a "generic" firewall script?

I remember myself being a total firewalling noob years ago and getting scared of those carpets of iptables rules (I'm by no means an expert now, but I already know the basics well enough to be able to support my own personal needs). I also remember instantly becoming more confident after stopping to think in terms of abstract things like "generic" or "best" or "shortest" or "safest" or whatever. My firewall ruleset always solves a well defined problem (or a set of them). I get to pick the default policy (ACCEPT ot DROP), I get to decide if I have a big subset of rules that filter all incoming traffic and another big subset of rules that filter all outgoing traffic, or if I have many per-task rule blocks containing both incoming and outgoing traffic rules etc

OP, what's your definition of "generic" in this context?

SCerovec

11-15-2021 03:39 PM

Quote:

Originally Posted by RadicalDreamer (Post 6301593)

Ever used a laptop in public place? ever used it to connect to an open hotspot?

Ever joined an install fest or a lan party?

Internet caffee?

RadicalDreamer

11-15-2021 03:59 PM

Quote:

Originally Posted by SCerovec (Post 6301613)

Ever used a laptop in public place? ever used it to connect to an open hotspot?

Ever joined an install fest or a lan party?

Internet caffee?

Yes, but are people going to install and setup Slackware at these places instead of at home behind a router with a firewall? I agree that a freshly installed OS shouldn't be straight up hooked to an untrusted network or a modem without protection to face the legions of script kiddies scouring the internet.

LuckyCyborg

11-15-2021 04:22 PM

Quote:

Originally Posted by RadicalDreamer (Post 6301620)

Believe or not, there are many people who carry their computers with them on various places and they call this particular portable computers with affection "laptops" ... ;)

I should understand that for you is unimaginable to use Slackware in a laptop supposed to carry with you and connect it to various WiFi or Ethernet networks?

Considering the Slackware's "thrilling feature" of being sent to RTFM for a more or less lame but self-made firewall, well... I tend to agree with you. :p

LuckyCyborg

11-15-2021 04:35 PM

Guys, I have a question for you:

Slackware has basically the "default" network management made by NetworkManager for "home" use, while I understand that the networking from /etc/rc.d is supposed to be used mainly by servers.

So, how integrates your Generic Firewall with the network connections managed by NetworkManager?

allend

11-15-2021 04:40 PM

I use a script /etc/NetworkManager/dispatcher.d/25_SetFirewall

Code:

#!/bin/sh



# Script to load appropriate firewall based on interface in use



INTERFACE=$1 # The interface which is brought up or down

STATUS=$2 # The new state of the interface



case "$STATUS" in

  'up') # an interface has been brought up

    case "$INTERFACE" in

      'eth0')

        exec /etc/rc.d/rc.firewall_eth0

      ;;

      'eth1')

        exec /etc/rc.d/rc.firewall_eth1

      ;;

      'wlan0')

        exec /etc/rc.d/rc.firewall_wlan0

      ;;

      'ppp0')

        exec /etc/rc.d/rc.firewall_ppp0

      ;;

      'wwan0')

        exec /etc/rc.d/rc.firewall_wwan0

      ;;

      'br0')

        exec /etc/rc.d/rc.firewall_br0

      ;;

    esac

    ;;

  'down') # an interface has been brought down

    # Load default if there is no active interface

#    if [ ! `nm-tool|grep State|cut -f2 -d' '` = "connected" ]; then

    nm-online -x || exec /etc/rc.d/rc.firewall_lo

  ;;

esac

PS - Another Slackware "thrilling feature" is to install third party software from SlackBuilds.org

All times are GMT -5. The time now is 02:18 AM.

Page 1 of 6

Last »

Show 50 post(s) from this thread on one page