[gentoo-user] Where to put advanced routing configuration?

[gentoo-user] Where to put advanced routing configuration?

[Grant Edwards]

Let's say you wanted to configure routing of TCP packets based on destination 
port like in this example:

  http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html

[which contains a series of 'ip' and 'iptables' commands to get packets
destined for port 25 to use a specific gateway.]

How do do this the "right" way on a Gentoo system?

Based on reading http://www.gentoo.org/doc/en/home-router-howto.xml, I think 
I've figured out how to do the iptables part: you enter the 'iptables' 
commands by hand to get the iptables set up the way you want, then you do 
this:

  # /etc/init.d/iptables save
  # rc-update add iptables default

What about the 'ip' commands required to set up the tables, routes, and 
rules?  Do those go in a startup script somewhere? Does one just edit 
/etc/iproute2/rt_tables by hand? One would assume route configuration belongs 
in /etc/conf.d/net -- I've read through the advanced networking stuff in the 
handbook, but it's not apparent to me where those 'ip' command belong.

-- 
Grant

Re: [gentoo-user] Where to put advanced routing configuration?

[Kerin Millar]

On 03/10/2013 20:27, Grant Edwards wrote:
> Let's say you wanted to configure routing of TCP packets based on destination
> port like in this example:
>
>    http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html
>
> [which contains a series of 'ip' and 'iptables' commands to get packets
> destined for port 25 to use a specific gateway.]
>
> How do do this the "right" way on a Gentoo system?
>
> Based on reading http://www.gentoo.org/doc/en/home-router-howto.xml, I think
> I've figured out how to do the iptables part: you enter the 'iptables'
> commands by hand to get the iptables set up the way you want, then you do
> this:
>
>    # /etc/init.d/iptables save
>    # rc-update add iptables default

The iptables runscript is ideal for persisting the rules. However, 
during the initial construction of a non-trivial ruleset, I prefer to 
write a script that adds the rules. An elegant way of doing this is to 
use iptables-restore with a heredoc. The method - and its advantages - 
are described in this document (section 3):

http://inai.de/documents/Perfect_Ruleset.pdf

> What about the 'ip' commands required to set up the tables, routes, and
> rules?  Do those go in a startup script somewhere? Does one just edit
> /etc/iproute2/rt_tables by hand? One would assume route configuration belongs

I would use the files under /etc/iproute2 for their intended purpose and 
a postup() hook in conf.d/net for anything else. When the postup() 
function is entered, the IFACE variable is automatically set to the name 
of the interface that triggered the event. Anything that is valid bash 
can go there.

> in /etc/conf.d/net -- I've read through the advanced networking stuff in the
> handbook, but it's not apparent to me where those 'ip' command belong.

[gentoo-user] Re: Where to put advanced routing configuration?

[Grant Edwards]

On 2013-10-03, Kerin Millar <kerframil@fastmail.co.uk> wrote:
> On 03/10/2013 20:27, Grant Edwards wrote:
>
>> Let's say you wanted to configure routing of TCP packets based on
>> destination port like in this example:
>>
>>    http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html
>>
>> [which contains a series of 'ip' and 'iptables' commands to get packets
>> destined for port 25 to use a specific gateway.]
>>
>> How do do this the "right" way on a Gentoo system?

[Where to put iptables and ip routing config/commands]

> The iptables runscript is ideal for persisting the rules. However, 
> during the initial construction of a non-trivial ruleset, I prefer to 
> write a script that adds the rules. An elegant way of doing this is to 
> use iptables-restore with a heredoc. The method - and its advantages - 
> are described in this document (section 3):
>
> http://inai.de/documents/Perfect_Ruleset.pdf

Excellent reference.

>> What about the 'ip' commands required to set up the tables, routes,
>> and rules?  Do those go in a startup script somewhere? Does one just
>> edit /etc/iproute2/rt_tables by hand? One would assume route
>> configuration belongs
>
> I would use the files under /etc/iproute2 for their intended purpose
> and a postup() hook in conf.d/net for anything else. When the
> postup() function is entered, the IFACE variable is automatically set
> to the name of the interface that triggered the event. Anything that
> is valid bash can go there.

Cool.  That's the main piece I hadn't figured out yet.  Thanks!

-- 
Grant Edwards               grant.b.edwards        Yow! Now KEN and BARBIE
                                  at               are PERMANENTLY ADDICTED to
                              gmail.com            MIND-ALTERING DRUGS ...

Re: [gentoo-user] Where to put advanced routing configuration?

[Michael Orlitzky]

On 10/03/2013 04:28 PM, Kerin Millar wrote:
> 
> The iptables runscript is ideal for persisting the rules. However, 
> during the initial construction of a non-trivial ruleset, I prefer to 
> write a script that adds the rules. An elegant way of doing this is to 
> use iptables-restore with a heredoc. The method - and its advantages - 
> are described in this document (section 3):
> 
> http://inai.de/documents/Perfect_Ruleset.pdf
> 

This advice is dubious in my opinion. The `iptables` command line is the
published interface to iptables. The iptables-restore syntax is an
implementation detail, subject to change at any time.

Here are his arguments:

1. Calling iptables repeatedly is slow.

Who cares? How often do you invoke the script? Once or twice a year
when you change it.

2. There is an opportunity for someone to bypass the rules between
   dropping/recreating them.

Again, you run the script once or twice a year. Turn off the interface
beforehand if a few microseconds per year is too long to run without a
firewall.


And my counterarguments:

1. The iptables-restore syntax is uglier and harder to read.

2. You get better error reporting calling iptables repeatedly.

3. The published interface will never change; iptables-restore reads an
input language whose specification is "whatever iptables-save outputs."

4. A bash script is far more standard and less confusing to your coworkers.

5. You can't script iptables-restore! What if you want to call sed, cut,
or grep on something and pass that to iptables? You can write a bash
script that writes an iptables-restore script to accomplish the same
thing, but how much complexity are you willing to add for next to no
benefit?

Re: [gentoo-user] Where to put advanced routing configuration?

[Dragostin Yanev]

On Fri, 04 Oct 2013 17:58:14 -0400
Michael Orlitzky <michael@orlitzky.com> wrote:

> On 10/03/2013 04:28 PM, Kerin Millar wrote:
> > 
> > The iptables runscript is ideal for persisting the rules. However, 
> > during the initial construction of a non-trivial ruleset, I prefer
> > to write a script that adds the rules. An elegant way of doing this
> > is to use iptables-restore with a heredoc. The method - and its
> > advantages - are described in this document (section 3):
> > 
> > http://inai.de/documents/Perfect_Ruleset.pdf
> > 
> 
> This advice is dubious in my opinion. The `iptables` command line is
> the published interface to iptables. The iptables-restore syntax is an
> implementation detail, subject to change at any time.
> 
> Here are his arguments:
> 
> 1. Calling iptables repeatedly is slow.
> 
> Who cares? How often do you invoke the script? Once or twice a year
> when you change it.
> 
> 2. There is an opportunity for someone to bypass the rules between
>    dropping/recreating them.
> 
> Again, you run the script once or twice a year. Turn off the interface
> beforehand if a few microseconds per year is too long to run without a
> firewall.
> 
> 
> And my counterarguments:
> 
> 1. The iptables-restore syntax is uglier and harder to read.
> 
> 2. You get better error reporting calling iptables repeatedly.
> 
> 3. The published interface will never change; iptables-restore reads
> an input language whose specification is "whatever iptables-save
> outputs."
> 
> 4. A bash script is far more standard and less confusing to your
> coworkers.
> 
> 5. You can't script iptables-restore! What if you want to call sed,
> cut, or grep on something and pass that to iptables? You can write a
> bash script that writes an iptables-restore script to accomplish the
> same thing, but how much complexity are you willing to add for next
> to no benefit?
> 
> 

Hi,
Many people use netfilter for busy firewalls not just for set and
forget firewalls. Having hundreds or thousands of rules and IPs makes
managing netfilter with iptables problematic. That is when it's
advisable to change the filter in one swoop with restore or ipset.
Bottom line is your individual use case is just that, individual.

[gentoo-user] Re: Where to put advanced routing configuration?

[Martin Vaeth]

Michael Orlitzky <michael@orlitzky.com> wrote:
>
> And my counterarguments:
>
> 1. The iptables-restore syntax is uglier and harder to read.
>
> 2. You get better error reporting calling iptables repeatedly.
>
> 3. The published interface will never change; iptables-restore reads an
> input language whose specification is "whatever iptables-save outputs."
>
> 4. A bash script is far more standard and less confusing to your coworkers.
>
> 5. You can't script iptables-restore!

Well, actually you can script iptables-restore.
In fact, you can write a function "ip4tables" which emulates the
behaviour of ip4tables by storing data in variables which are then
later passed to iptables-restore, and so the user sees almost no
difference although race conditions are avoided.

However, 3. is a severe problem for such complex functions.
There should be an official way how to avoid races,
e.g. if ip4tables itself would be able to successively extend
an output file which can then be used for iptables-restore.
If you have contact to the iptables developers, please suggest
such a thing. Or maybe somebody has a bette idea?

[gentoo-user] scripted iptables-restore (was: Where to put advanced routing configuration?)

[Martin Vaeth]

>> 5. You can't script iptables-restore!
>
> Well, actually you can script iptables-restore.

For those who are interested:
net-firewall/firewall-mv from the mv overlay
(available over layman) now provides a separate
firewall-scripted.sh
which can be conveniently used for such scripting.

Re: [gentoo-user] scripted iptables-restore

[Michael Orlitzky]

On 10/13/2013 06:08 AM, Martin Vaeth wrote:
>>> 5. You can't script iptables-restore!
>>
>> Well, actually you can script iptables-restore.
> 
> For those who are interested:
> net-firewall/firewall-mv from the mv overlay
> (available over layman) now provides a separate
> firewall-scripted.sh
> which can be conveniently used for such scripting.
> 

You snipped the rest of my point =)

> You can write a bash script that writes an iptables-restore script to
> accomplish the same thing, but how much complexity are you willing to
> add for next to no benefit?

If you have a million rules and you need to wipe/reload them all
frequently you're probably doing something wrong to begin with.

With bash, you can leverage all of the features of bash that everybody
already knows. You can read files, call shell commands, pipe between
them, etc. You can write bash functions to avoid repetitive commands.
You can write inline comments to explain what the rules do.

Something like,

  # A function which sets up a static mapping between an external IP
  # address and an internal one.
  #
  # USAGE: static_nat <internal ip> <external ip>
  #
  function static_nat() {
      iptables -t nat -A PREROUTING  -d "${2}" -j DNAT --to "${1}"
      iptables -t nat -A POSTROUTING -s "${1}" -j SNAT --to "${2}"
  }

can make your iptables script a lot cleaner, and it conveys your intent
better when the rule is created:

  # Danny likes to torrent "linux isos" at work so he needs a public ip
  static_nat 192.168.1.x 1.2.3.x

I'm not saying you can't do all of this with iptables-restore, just that
you're punishing yourself for little benefit if you do.

[gentoo-user] Re: scripted iptables-restore

[Martin Vaeth]

Michael Orlitzky <michael@orlitzky.com> wrote:
> On 10/13/2013 06:08 AM, Martin Vaeth wrote:
>>>> 5. You can't script iptables-restore!
>>>
>>> Well, actually you can script iptables-restore.
>>
>> For those who are interested:
>> net-firewall/firewall-mv from the mv overlay
>> (available over layman) now provides a separate
>> firewall-scripted.sh
>> which can be conveniently used for such scripting.
>>
> [...]
> If you have a million rules and you need to wipe/reload them all
> frequently you're probably doing something wrong to begin with.

I don't know how this is related with the discussion.
The main advantage of using iptables-restore is avoidance of
race conditions. A secondary advantage is a speed improvement;
in my case, the machine boots about 2 seconds faster which can
be a considerable advantage if you start virtual machines.

> With bash [...]

(I would use a POSIX shell because it is considerably faster,
but this need not be discussed here.)

That's why I said that it can be scripted
(which was my motivation to write firewall-scripted.sh):

firewall-scripted.sh (or some similar script) gives you exactly
the same advantages, but without races, and faster.
In your example:

> function static_nat() {
>    iptables -t nat -A PREROUTING  -d "${2}" -j DNAT --to "${1}"
>    iptables -t nat -A POSTROUTING -s "${1}" -j SNAT --to "${2}"
> }

Essentially, you just have to replace "iptables" by "FwmvTables 4".
If you are too lazy to use a text editor or to replace "iptables"
by a variable (like $iptables) you can do this even by
defining the function:

iptables() {
  FwmvTables 4 "${@}"
}

Then you just put in front of your script the line

. firewall-scripted.sh

and in the end (or before you call exit):

FwmvSet 4

That's it...

> I'm not saying you can't do all of this with iptables-restore, just that
> you're punishing yourself for little benefit if you do.

*Using* firewall-scripted.sh is as convenient as using iptables directly
(you just replace one command and add two lines to your script).
Of course, the disadvantage is that some day firewall-scripted.sh might
break with iptables (and that maybe the script still has bugs...).
As I said, it would be better if something similar would be provided
by iptables itself. But the advantages are clear.

Re: [gentoo-user] Re: scripted iptables-restore

[Michael Orlitzky]

On 10/13/2013 11:19 AM, Martin Vaeth wrote:
>>>
>> [...]
>> If you have a million rules and you need to wipe/reload them all
>> frequently you're probably doing something wrong to begin with.
> 
> I don't know how this is related with the discussion.
> The main advantage of using iptables-restore is avoidance of
> race conditions. A secondary advantage is a speed improvement;
> in my case, the machine boots about 2 seconds faster which can
> be a considerable advantage if you start virtual machines.
> 

I was just reiterating that there's not much benefit to save/restore if
you're doing things properly (pontification alert!). I should say first
of all that save/restore is perfect for reboots. If you're not
*changing* anything, of course save/restore is better, and suffers none
of the problems that I mentioned: you don't read it, the output is fed
directly as input, no errors should occur...

The bash script is used a couple times a year, and really is there to
serve as the specification for what your firewall should do.

For example, I'm rebuilding our MX today. I checked the config out of
git, ran iptables-config (our script), ran /etc/init.d/iptables save,
and the firewall is up and running. When will I run the script again?
The next time I rebuild the server? That's certainly the last time I ran
it. We have firewalls that change more often, but not so frequently that
the speed would be a problem if it were 1000x slower.

The MX firewall is actually updated many times per day and accumulates
many rules, but they're inserted/deleted in-place by fail2ban, so a full
wipe/reload doesn't occur. If you have frequently-changing permanent
rules -- say, lots of static NAT entries going in/out for new employees
-- then you should be doing insert/delete instead of a full reload just
the same. But, add the rule to your iptables script (with a comment!) so
that you have it on the record. Once every six months or so, run the
thing to make sure nobody made a copy/paste error.

Race conditions don't really seem that serious to me. Of course, if
you're using iptables for both authorization and authentication, then
you're already doing something wrong, and you should fix that instead of
trying to make the broken thing run faster. But if not, who cares if
you're vulnerable to a brute force attack for 2 seconds? If you're
worried about that, implement a password policy. The firewall is the
last layer of defense-in-depth; if the absence of a firewall gives you
nightmares, the absence of a firewall is not your problem.

All of security is a trade-off, and in my opinion, having
human-friendly, easily-readable rules (with error checking) will prevent
more problems over time than does eliminating the race condition.

[gentoo-user] Re: scripted iptables-restore

[Martin Vaeth]

Michael Orlitzky <michael@orlitzky.com> wrote:
>>> [...]
>>> If you have a million rules and you need to wipe/reload them all
>>> frequently you're probably doing something wrong to begin with.
>>
>> I don't know how this is related with the discussion.
>> The main advantage of using iptables-restore is avoidance of
>> race conditions. A secondary advantage is a speed improvement;
>> in my case, the machine boots about 2 seconds faster which can
>> be a considerable advantage if you start virtual machines.
>>
>
> I was just reiterating that there's not much benefit to save/restore if
> you're doing things properly (pontification alert!).

For a laptop of a scientist like me this is not true at all - it must
often be connected in a different environment with different
local nets etc.
Also for other things (like portknocking using the recent module)
you need rather complex rules which are better rewritten by a script,
especially if the length of a portknocking sequence changes.
Like passwords, these sequences should better not stay the same for
too long...

> Race conditions don't really seem that serious to me.

Maybe, but I am not sure:
There might be situations where it might be possible to keep
a port open even when the rule is rewritten later on; then
you need an open system only once...
So, I could imagine that with some clever hacks an attacker
might keep ports open and then do another attack later on.
I am not an experienced hacker to know such attacks, but I
know that races can be very subtle and provide attack vectors
nobody has ever thought off.

> All of security is a trade-off, and in my opinion, having
> human-friendly, easily-readable rules (with error checking)

It is easy to switch to one method for testing and then back
when everything works: If you write $iptables ...
throughout you just have to set
iptables="iptables"
or
iptables="FvwmTables 4"
respectively. In fact, the firewall-mv script does this
(with a different mechanism) depending on a commandline switch.
Moreover, I observed that the error checking works with
iptables-restore as well as with iptables:
It shows you almost the same errors, including a line number.
So the only difference is that you have to count the lines
in the testing output instead of directly seeing the command...

Re: [gentoo-user] Re: scripted iptables-restore

[William Kenworthy]

On 14/10/13 04:07, Martin Vaeth wrote:
> Michael Orlitzky <michael@orlitzky.com> wrote:
>>>> [...]
>>>> If you have a million rules and you need to wipe/reload them all
>>>> frequently you're probably doing something wrong to begin with.
>>>
>>> I don't know how this is related with the discussion.
>>> The main advantage of using iptables-restore is avoidance of
>>> race conditions. A secondary advantage is a speed improvement;
>>> in my case, the machine boots about 2 seconds faster which can
>>> be a considerable advantage if you start virtual machines.
>>>
>>
>> I was just reiterating that there's not much benefit to save/restore if
>> you're doing things properly (pontification alert!).
> 
> For a laptop of a scientist like me this is not true at all - it must
> often be connected in a different environment with different
> local nets etc.
> Also for other things (like portknocking using the recent module)
> you need rather complex rules which are better rewritten by a script,
> especially if the length of a portknocking sequence changes.
> Like passwords, these sequences should better not stay the same for
> too long...
> 

...

If you are going to go to this bother ... why not use shorewall, create
a custom configuration for each site (including any changes to services)
and and have your script just copy them in and restart the various
services including shorewall?  I have a number of networks from hotspots
to places where I need combinations of vpns, web servers and asterisk
available for demonstrations in lecture theatres through to travelling
and using hotel networks.

The iptables save feature gets a bit difficult to use with complex
setups and if you are doing something dynamic with the rules (fail2ban
for instance) it can save inappropriate rules which need manual culling.

I use a simple script with autosetup using network-manager (yuk,
horrible thing!) to detect known gateways and trigger the script with
that argument for either wifi or cable as appropriate  (or setup for
anonymous hotspot for unknown wifi, basic dhcp if unknown cable) - this
is on a macbook air if that matters.

BillK

[gentoo-user] Re: scripted iptables-restore

[Martin Vaeth]

William Kenworthy <billk@iinet.net.au> wrote:
>
> If you are going to go to this bother ... why not use shorewall, create

When I checked for scripts creating rules, none fulfilled my needs.
(I do not know whether I checked shorewall at this time).
For instance, instead of dropping most packets, I want to reject them
properly, only with a rate-limit to avoid DOS. Then there is the
mentioned port knocking, some forwarding etc. pp.

> a custom configuration for each site (including any changes to services)
> and and have your script just copy them in and restart the various
> services including shorewall?

Instead of managing dozens of configurations manually,
I think it is easier to have one script which creates an
appropriate custom configuration on all my machines, depending
on certain files in /etc and other tests. That's why I always
run my firewall script on startup (or if I severely change
the configuration).

> I use a simple script with autosetup using network-manager

network-manager is on my university's laptop (with Ubuntu -
not my decision), but on any "safe" machine (running Gentoo)
I refuse to install the gaping security hole "polkit"
which unfortunately is a hard dependency of network-manager.
As soon as "polkit" is on an machine on which you use a browser,
it makes no sense to spend time pretending to make it secure:
Barring your back door even more when the front door of your house
was removed is rather pointless...

Re: [gentoo-user] Re: scripted iptables-restore

[William Kenworthy]

On 14/10/13 20:08, Martin Vaeth wrote:
> William Kenworthy <billk@iinet.net.au> wrote:
>>
>> If you are going to go to this bother ... why not use shorewall, create
> 
> When I checked for scripts creating rules, none fulfilled my needs.
> (I do not know whether I checked shorewall at this time).
> For instance, instead of dropping most packets, I want to reject them
> properly, only with a rate-limit to avoid DOS. Then there is the
> mentioned port knocking, some forwarding etc. pp.
> 
>> a custom configuration for each site (including any changes to services)
>> and and have your script just copy them in and restart the various
>> services including shorewall?
> 
> Instead of managing dozens of configurations manually,
> I think it is easier to have one script which creates an
> appropriate custom configuration on all my machines, depending
> on certain files in /etc and other tests. That's why I always
> run my firewall script on startup (or if I severely change
> the configuration).

Been there, done that, after the various disasters of editing/sed'iting
in place config files I took the cowards way out - at least when it all
goes wrong its now easy to fix, and is a LOT less fragile, especially
after upgrades :)  Its also a lot harder to do once you get to some of
the weirder environments with conflicting requirements.  Keep in mind
that shorewall or similar wont handle all the parts needed to make this
work ... vpn's, services etc will need scripting as well, but they
certainly make the firewall part easier and more secure.

Also, if you are editing iptables scripts yourself have a look at
shorewall, monmotha or most other "professional" scripts - can you
guarantee you are covering as many bases as these do? - I always shudder
when I see someone put together a "few" rules and think its as good as
something thats stood the test of time and review.  Or think of it this
way, you are using port knocking and trying for extreme "defence in
depth", but use a home brew firewall ...  I dont see anything strange
about your requirements and think they should be within the capability
of most firewall setups and a knowledgeable admin.

I totally agree on network manager - its a pita.  In this cae its a left
over from an abortive attempt to like gnome3 ... I am now using LXDE but
everytime I try and strip more gnome out of the system it either breaks
or reinstalls the gnomey bits Ive just removed :(

Maybe a reinstall during the Christmas break - prezzies!

BillK

Re: [gentoo-user] Re: scripted iptables-restore

[Michael Orlitzky]

On 10/13/2013 04:07 PM, Martin Vaeth wrote:
>>
>> I was just reiterating that there's not much benefit to save/restore if
>> you're doing things properly (pontification alert!).
> 
> For a laptop of a scientist like me this is not true at all - it must
> often be connected in a different environment with different
> local nets etc.

Sure, but do the rules change? Is there a better ruleset that
accomplishes the same thing with fewer (or universal) rules? How many
rules do you have at the location requiring the most rules?

Most laptops should be OK with the following:

  iptables -P INPUT DROP
  iptables -P FORWARD DROP
  iptables -P OUTPUT ACCEPT

  iptables -A INPUT -p ALL -i lo -j ACCEPT
  iptables -A INPUT -p ALL -m conntrack \
    --ctstate ESTABLISHED,RELATED -j ACCEPT
  iptables -A INPUT -p ALL -m conntrack \
    --ctstate INVALID -j DROP

  ALLOWED_ICMP="0 3 4 8 11 12"
  for icmp_type in $ALLOWED_ICMP; do
    iptables -A INPUT -p icmp --icmp-type $icmp_type -j ACCEPT
  done

And creative setups should only require a few more rules. This all takes
under (1/10) of a second on my laptop.


> Also for other things (like portknocking using the recent module)
> you need rather complex rules which are better rewritten by a script,
> especially if the length of a portknocking sequence changes.
> Like passwords, these sequences should better not stay the same for
> too long...

Port knocking is cute, but imparts no extra security. A better, secure
way to achieve the same goal is with OpenVPN. And that doesn't require
you to play games with your firewall.

If you use your laptop at hotels, universities, and conferences, you'll
have a much happier time connecting to OpenVPN on tcp/443 (which nobody
can block) than you will trying to connect directly.


>> Race conditions don't really seem that serious to me.
> 
> Maybe, but I am not sure:
> There might be situations where it might be possible to keep
> a port open even when the rule is rewritten later on; then
> you need an open system only once...
> So, I could imagine that with some clever hacks an attacker
> might keep ports open and then do another attack later on.
> I am not an experienced hacker to know such attacks, but I
> know that races can be very subtle and provide attack vectors
> nobody has ever thought off.

In this case, the absolute worst that could happen is that an attacker
gains access to every open port on your system. While this is bad, it's
not a clever new vulnerability: it's all of the old ones that were
already there.

If there are insecure daemons listening on public addresses, you should
fix them instead of worrying about race conditions on the firewall.
Otherwise, every machine on your LAN becomes an attack vector, and
that's a much greater risk especially if your coworkers/friends use
Windows. And if we're still talking about laptops, the "LAN" is usually
"anybody nearby."

[gentoo-user] Re: scripted iptables-restore

[Martin Vaeth]

Michael Orlitzky <michael@orlitzky.com> wrote:
> Port knocking is cute, but imparts no extra security.

It does, for instance if you use it to protect sshd and
sshd turns out to be vulnerable; remember e.g. the
security disaster with Debian.

> A better, secure way to achieve the same goal is with OpenVPN.

Using yet another service with possible holes to protect a sshd?
In this case, I would like port knocking at least for this OpenVPN.

> In this case, the absolute worst that could happen is that an attacker
> gains access to every open port on your system. While this is bad, it's
> not a clever new vulnerability: it's all of the old ones that were
> already there.

It is exactly the kind of attacks for which one usually uses iptables.
You are right, iptables is just one extra step of security, so the
worst thing which can happen is that this step is useless.
However, if you are willing to risk this only because of your own
lazyness in scripting then why do you setup iptables in the first place?

> If there are insecure daemons listening on public addresses

The problem is that nobody can be sure that some daemon is safe.
Even presumably safe services turn out to be victims of new kind
of attacks, occassionally.

Re: [gentoo-user] Re: scripted iptables-restore

[Michael Orlitzky]

On 10/14/2013 07:49 AM, Martin Vaeth wrote:
> Michael Orlitzky <michael@orlitzky.com> wrote:
>> Port knocking is cute, but imparts no extra security.
> 
> It does, for instance if you use it to protect sshd and
> sshd turns out to be vulnerable; remember e.g. the
> security disaster with Debian.
> 
>> A better, secure way to achieve the same goal is with OpenVPN.
> 
> Using yet another service with possible holes to protect a sshd?
> In this case, I would like port knocking at least for this OpenVPN.
> 

The sensitive parts of OpenVPN are audited regularly, and it uses "SSL"
-- public key auth to exchange a symmetric key, both of which use
tried-and-true algorithms/code.

Port knocking on the other hand is just security through obscurity, and
is visible over the wire (or over the air, most likely, if you're on a
laptop).

Obscurity does provide some benefit, but it gets dismissed because we
tend to ignore the constant factor when talking about these things. A
problem is "solved" if it's easy to exponentially increase the amount of
work an attacker has to do.

For an analogy, a somewhat-related issue is that of salting passwords.
Typically one stores the salt in the database in clear text, and this
tends to freak people out.

Doesn't that make it easier for an attacker to brute force your
passwords? Well, yes, but the salt isn't meant to stop a brute force
attack. It's meant to stop rainbow table attacks. The way you stop brute
force attacks is to use an algorithm with a variable number of rounds
that can slow itself down (see: bcrypt).

Hiding the salt would just be security through obscurity. You always
assume that the attacker knows the details of your algorithm, including
the constants. So while hiding the salt would make it a tiny bit harder
to brute force, we ignore it in favor of the thing that makes it
exponentially harder (variable rounds).

Similarly, putting port knocking in front of OpenVPN is like putting a
padlock on the bank vault. If someone is going to break OpenVPN, port
knocking ain't gonna stop them.


> It is exactly the kind of attacks for which one usually uses iptables.
> You are right, iptables is just one extra step of security, so the
> worst thing which can happen is that this step is useless.
> However, if you are willing to risk this only because of your own
> lazyness in scripting then why do you setup iptables in the first place?
> 

All of my iptables scripts, even the big ones, run in under a second and
get executed 2 or 3 times a year. There's some saying about a baby and
bath water.

It's not laziness I'm advocating, just simplicity. Simple,
understandable code is more likely to be correct than clever code. And
in this case, incorrect iptables code is more of a threat than the tiny
race condition.

[gentoo-user] Re: scripted iptables-restore

[Martin Vaeth]

Michael Orlitzky <michael@orlitzky.com> wrote:
> On 10/14/2013 07:49 AM, Martin Vaeth wrote:
>>
>> Using yet another service with possible holes to protect a sshd?
>> In this case, I would like port knocking at least for this OpenVPN.
>
> The sensitive parts of OpenVPN are audited regularly, and it uses "SSL"
> -- public key auth to exchange a symmetric key, both of which use
> tried-and-true algorithms/code.

So its completely as well-audited and secure as openssh was when
the Debian disaster happened. Also IIRC there are currently
some timing attacks against certain SSL modes, and who knows
when some clever hacker finds another possibility nobody
thought of up to now.

> Port knocking on the other hand is just security through obscurity

As is every password.

> and is visible over the wire

This is why you have to change it regularly. Actually, if you change
it whenever you used it, you have a rather strong method, essentially
only vulnerable if the man-in-the-middle is able to cut your
connection, and even then he has only very limited time to attack
the actual service which is protected by it.

> problem is "solved" if it's easy to exponentially increase the amount
> of work an attacker has to do.

And exactly for this reason the solution is always only a theory -
for very particularly specified problems. For practical machines,
it is good to have this *in addition* to other safety measurements:
Experience shows that rather often there are some new ideas or bugs
which can be used to avoid the exponential amount by something not
covered by the original theory.

> Obscurity does provide some benefit, but it gets dismissed because we
> tend to ignore the constant factor when talking about these things.

This is reasonable for theory, but in practice the constant factor
can be more important. Even more if it needs human intervention.

> Hiding the salt would just be security through obscurity.

And yet it is stupid if you do not do it and give away a
huge constant factor for no advantage.

> Similarly, putting port knocking in front of OpenVPN is like putting a
> padlock on the bank vault. If someone is going to break OpenVPN, port
> knocking ain't gonna stop them.

No. Port knocking is more like putting your bank vault into a
wooden box. If some new attack against SSL or the OpenVPN
implementation is found, it is like somebody has a key to
your vault. If you are a highly important target, this will
not save you, but if human resources are needed to break
whatever you did for obscurity, it makes in practice the
crucial difference.

> It's not laziness I'm advocating, just simplicity. Simple,
> understandable code is more likely to be correct than clever code. And
> in this case, incorrect iptables code is more of a threat than the tiny
> race condition.

You have a strange mentality:
One the one hand you are afraid that a rather primitive translation
of one syntax into another leads to unexpected effects, and on the
other hand you trust much more complex things like SSL and OpenVPN
which could much easier allow unexpected things with even the
slightest attempt to secure them further if you can.

Re: [gentoo-user] Re: scripted iptables-restore

[Michael Orlitzky]

On 10/14/2013 02:49 PM, Martin Vaeth wrote:
> 
>> Hiding the salt would just be security through obscurity.
> 
> And yet it is stupid if you do not do it and give away a
> huge constant factor for no advantage.
> 

(I'll just agree to disagree about the rest.)

Keeping the salt secret makes your application more complex. Rather than
"SELECT hash, salt FROM users WHERE...", you now have to "SELECT hash
FROM users WHERE..." and then pull the salt from somewhere else. (Where?
The filesystem? Do you encrypt that? How?)

What's stupid is going to all that effort for a 2x improvement when you
could twiddle a bit and get a 340282366920938463463374607431768211456x
improvement.

Re: [gentoo-user] Re: scripted iptables-restore

[Alan McKinnon]

On 14/10/2013 21:17, Michael Orlitzky wrote:
> On 10/14/2013 02:49 PM, Martin Vaeth wrote:
>>
>>> Hiding the salt would just be security through obscurity.
>>
>> And yet it is stupid if you do not do it and give away a
>> huge constant factor for no advantage.
>>
> 
> (I'll just agree to disagree about the rest.)
> 
> Keeping the salt secret makes your application more complex. Rather than
> "SELECT hash, salt FROM users WHERE...", you now have to "SELECT hash
> FROM users WHERE..." and then pull the salt from somewhere else. (Where?
> The filesystem? Do you encrypt that? How?)
> 
> What's stupid is going to all that effort for a 2x improvement when you
> could twiddle a bit and get a 340282366920938463463374607431768211456x
> improvement.
> 
> 


Keep in mind the actual original purpose of a salted hash.

If two users happen to use the same password[1], the hashes are the same
and this is revealed to anyone who can read /etc/passwd[2] i.e everyone.
Salt obscures this 1-to-1 mapping and does it in a way that it is not
computationally worth while to try get around it for the general
case[3]. It's not quite the same thing as security by obscurity - that
is hiding something in a place you think no-one will think of looking
but usually turns out to be viable to try and guess. Salt works because
brute force now doesn't need just one expensive calculation, it needs
many thousands of expensive calculations.

If the actual problem is that salt is inadequate, the solution is not to
try and hide it, but to use a more complex hashing algorithm with larger
salt. It's a race between white and black hats - they build bigger and
better rainbow tables, we implement bigger and better hashes. The
constraint is how much cpu grunt is available for purchase at a
realistic cost.


[1] This is not uncommon. The domain size of all possible passwords for
a implementation is very very large. Human psychology says that the
actual domain size of passwords people will pick is a tiny fraction of
the whole. Hence salt.

[2] Nowadays we use shadow, but the development of salt pre-dates shadow

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: scripted iptables-restore

[Michael Orlitzky]

On 10/14/2013 04:31 PM, Alan McKinnon wrote:
> 
> Keep in mind the actual original purpose of a salted hash.
> 
> If two users happen to use the same password[1], the hashes are the same
> and this is revealed to anyone who can read /etc/passwd[2] i.e everyone.

Ah, the single-entry rainbow table =)

Re: [gentoo-user] Re: scripted iptables-restore

[Tanstaafl]

On 2013-10-13 4:07 PM, Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> 
wrote:
> Like passwords, these sequences should better not stay the same for
> too long...

Forced changing of passwords (and I imagine the same can be said for 
port-knocking sequences, which I've never implemented, but am intrigued 
by, although I tend to avoid security-through-obscurity schemes) 
periodically as a way to 'better security' is one of those myths that 
just never seem to go away.

Enforce strong passwords and a policy that no one is to ever write a 
password down and put it in any publicly accessible place, and educate 
users how not to fall for phishing attacks, is the single most effective 
way to keep things secure.

Then only change a password if/when an account is compromised.

This combined with intelligent rate-limiting (with 
notifications/warnings to admins if/when a users account exceeds them) 
is all you need.

In fact I go one step further... I assign passwords, and do not even 
allow users to change them. I have always done this, and we have people 
in this office that have had the same email password (on the same gentoo 
server) for 12+ years.

I know that I'm probably the exception to this rule, and it is more luck 
than anything else, but we have never had an email account hacked (knock 
on wood).

I'm certainly not saying we are immune, but the claim that passwords 
should be forcibly changed for no reason other than the passage of some 
arbitrary amount of time is just plain dumb.

[gentoo-user] Re: scripted iptables-restore

[Martin Vaeth]

Tanstaafl <tanstaafl@libertytrek.org> wrote:
>> Like passwords, these sequences should better not stay the same for
>> too long...
>
> Forced changing of passwords

I agreee: To do this to protect *other* users will not work.
It's a different thing if you use it for protection of your own data...

Re: [gentoo-user] Re: scripted iptables-restore

[Tanstaafl]

On 2013-10-14 2:52 PM, Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> 
wrote:
> Tanstaafl <tanstaafl@libertytrek.org> wrote:
>>> Like passwords, these sequences should better not stay the same for
>>> too long...
>>
>> Forced changing of passwords
>
> I agreee: To do this to protect *other* users will not work.
> It's a different thing if you use it for protection of your own data...

True to an extent... but only if the frequency of changing the password 
doesn't result in you doing something dumb to help you remember the 
current password of the day - like writing it on a post-it and sticking 
it underneath the keyboard... ;)

One of many reasons why I use a password manager (I prefer the 
Passwordmaker firefox extension, even with all it warts - it only stores 
settings, not the passwords themselves)...

But there are still only a couple of (critical) passwords I change 
frequently (what I call frequently - every 3-6 months or more)...

Re: [gentoo-user] Re: scripted iptables-restore

[Alan McKinnon]

On 14/10/2013 20:23, Tanstaafl wrote:
> On 2013-10-13 4:07 PM, Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de>
> wrote:
>> Like passwords, these sequences should better not stay the same for
>> too long...
> 
> Forced changing of passwords (and I imagine the same can be said for
> port-knocking sequences, which I've never implemented, but am intrigued
> by, although I tend to avoid security-through-obscurity schemes)
> periodically as a way to 'better security' is one of those myths that
> just never seem to go away.
> 
> Enforce strong passwords and a policy that no one is to ever write a
> password down and put it in any publicly accessible place, and educate
> users how not to fall for phishing attacks, is the single most effective
> way to keep things secure.
> 
> Then only change a password if/when an account is compromised.

Here here. I fully agree, and I have a use case to back you up. Yes,
it's anecdotal and just my use case, but at least it's factual :-)

Access to my backend network is two-factor - ssh keys and decent
passwords. I generate the passwords in code, they have high randomity
but rememberable and I refuse to implement password expiry. People with
sensitive and powerful accounts have enough head smarts to know when to
tell me quietly they need a reset done, and everyone is happy with this.
they don't mind that I see their passwords once in plaintext, as I can
make the password anything I want anytime I want. The user's security
against me comes via the HR department backed up by employment law.

We have pentesters that exhaustively test stuff every few months. I
insist they have full access to my data, supervised by the very trusted
Risk guy, as I want them to find any weakness as opposed to the bad guys
finding them. In 5 years they have cracked one password once out of many
hundreds. One. It's an isolated case and I know how it happened - I
trusted someone and bent one rule once.

Contrast the scheme used by Windows. It uses every one of these "best
practice" tricks inccluding expiring every 30 days, password length,
complexity, special chars etc. With every audit it gets blown wide open,
usually within a few hours. reason: human being are almost uniformly bad
at selecting and maintaining passwords.

I break all the best practice rules and have never have a systemic
compromise in 5 years despite awesome tools weilded by real pros with
clue throwing the book at it. Hmmm.

The other system that does obey best practice gets ripped to pieces with
trivial ease by the same guys. Hmmmmmmmmmmm.

I can pull this off because a) few people dare go up against me and my
facts :-) and b) it's a controlled environment. Obviously this couldn't
work on a public service like say gmail.

> 
> This combined with intelligent rate-limiting (with
> notifications/warnings to admins if/when a users account exceeds them)
> is all you need.
> 
> In fact I go one step further... I assign passwords, and do not even
> allow users to change them. I have always done this, and we have people
> in this office that have had the same email password (on the same gentoo
> server) for 12+ years.
> 
> I know that I'm probably the exception to this rule, and it is more luck
> than anything else, but we have never had an email account hacked (knock
> on wood).
> 
> I'm certainly not saying we are immune, but the claim that passwords
> should be forcibly changed for no reason other than the passage of some
> arbitrary amount of time is just plain dumb.
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: scripted iptables-restore

[Walter Dnes]

On Mon, Oct 14, 2013 at 10:45:10PM +0200, Alan McKinnon wrote

> Access to my backend network is two-factor - ssh keys and decent
> passwords.

  That is *NOT* Two-factor authentication.  See
http://en.wikipedia.org/wiki/Multi-factor_authentication for the
details.  Executive summary... Two-factor authentication requires you to
present two authentication factors each time.  I.e. it's A *AND* B.
Your setup is A *OR* B.  The usual implimentations include 2 factors...
1) userID+password
2) a small credit-card-sized unit that generates random-looking
   multi-digit numbers that change every minute.

  In order to logon the user must enter both the userID+password combo
*AND* the current number on the token card.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: scripted iptables-restore

[Alan McKinnon]

On 17/10/2013 01:21, Walter Dnes wrote:
> On Mon, Oct 14, 2013 at 10:45:10PM +0200, Alan McKinnon wrote
> 
>> Access to my backend network is two-factor - ssh keys and decent
>> passwords.
> 
>   That is *NOT* Two-factor authentication.  See
> http://en.wikipedia.org/wiki/Multi-factor_authentication for the
> details.  Executive summary... Two-factor authentication requires you to
> present two authentication factors each time.  I.e. it's A *AND* B.
> Your setup is A *OR* B.  The usual implimentations include 2 factors...
> 1) userID+password
> 2) a small credit-card-sized unit that generates random-looking
>    multi-digit numbers that change every minute.
> 
>   In order to logon the user must enter both the userID+password combo
> *AND* the current number on the token card.
> 


It's a poor choice of words on my part. We do have that exact two-factor
system to access the network via VPN, but that's just a portal.

Accessing the actual backend network is a two stage process: ssh key to
the jump host, then password to get onto the actual destination.

So it's "two factor" as a generic English language phrase, not "two
factor" as a technical description of an exact thing. Keep in mind that
English is a highly overloaded language :-)



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: scripted iptables-restore

[Walter Dnes]

On Thu, Oct 17, 2013 at 08:59:15AM +0200, Alan McKinnon wrote

> Accessing the actual backend network is a two stage process: ssh key to
> the jump host, then password to get onto the actual destination.
> 
> So it's "two factor" as a generic English language phrase, not "two
> factor" as a technical description of an exact thing. Keep in mind that
> English is a highly overloaded language :-)

  I apologize.  That is arguably a two factor system.  When you said
"ssh key and password", I "jumped to delusions", assuming that it was a
standard ssh connection with the option of either key or password.  Does
the jump host restrict you to logging on to the account corresponding to
the key?  I.e. would John Smith got to the jump host with his key, could
he log in to the Jane Doe account, or only John Smith.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: scripted iptables-restore

[Alan McKinnon]

On 18/10/2013 04:30, Walter Dnes wrote:
> On Thu, Oct 17, 2013 at 08:59:15AM +0200, Alan McKinnon wrote
> 
>> Accessing the actual backend network is a two stage process: ssh key to
>> the jump host, then password to get onto the actual destination.
>>
>> So it's "two factor" as a generic English language phrase, not "two
>> factor" as a technical description of an exact thing. Keep in mind that
>> English is a highly overloaded language :-)
> 
>   I apologize.  That is arguably a two factor system.  When you said
> "ssh key and password", I "jumped to delusions", assuming that it was a
> standard ssh connection with the option of either key or password.  Does
> the jump host restrict you to logging on to the account corresponding to
> the key?  I.e. would John Smith got to the jump host with his key, could
> he log in to the Jane Doe account, or only John Smith.


I built it myself, so I done did it rite :-)

It's very much one key to one user and the only jump host the general
user (i.e. customer support) can use is the main advertised one.
Infrastructure people and my friends in NetOps have other ways of
getting into the network but those are very restricted access.

When building this, we found something interesting - dudes were sharing
keys. The mind boggles as to why anyone thought this a good idea but
that's what they were doing. I suspect some people found ssh-keygen
and/or PuTTY too difficult to wrap their wits around.

But the fix was simple - with 700+ users and 250+ hosts to manage, we do
user deployment centrally with no way to bypass it. The database field
containing the public key string was given a unique index. No more
duplicate keys :-)


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: scripted iptables-restore

[Tanstaafl]

On 2013-10-17 10:30 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> I apologize.  That is arguably a two factor system.  When you said
> "ssh key and password", I "jumped to delusions", assuming that it was a
> standard ssh connection with the option of either key or password.

Side question...

So, wouldn't the simplest two-factor authentication be an SSH key that 
required a password?

Re: [gentoo-user] Re: scripted iptables-restore

[Alan McKinnon]

On 18/10/2013 12:23, Tanstaafl wrote:
> On 2013-10-17 10:30 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> I apologize.  That is arguably a two factor system.  When you said
>> "ssh key and password", I "jumped to delusions", assuming that it was a
>> standard ssh connection with the option of either key or password.
> 
> Side question...
> 
> So, wouldn't the simplest two-factor authentication be an SSH key that
> required a password?
> 


No, there is no way to verify that a user has enabled a passphrase on an
ssh key.

Passphrases are designed to be used by the user to protect the user's
private key and cannot be controlled by the listening sshd.

The reason this is "two factor" is that hop 1 is a Unix host and like
all good sysadmins I enable key auth only. The next hop is the Cisco
routers and believe it or not, most of them are telnet only.

Yes, you heard right: telnet. Recent Cisco firmware supports ssh but a)
it kills the poor PowerPC cpu with 10 concurrent connections and b)
costs a lot of license money. Ingenious measures are in place to
mitigate the risk of telnet, it is certainly nothing like running
telnetd over the open internet.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: scripted iptables-restore

[Tanstaafl]

On 2013-10-18 7:19 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 18/10/2013 12:23, Tanstaafl wrote:
>> On 2013-10-17 10:30 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>>> I apologize.  That is arguably a two factor system.  When you said
>>> "ssh key and password", I "jumped to delusions", assuming that it was a
>>> standard ssh connection with the option of either key or password.
>>
>> Side question...
>>
>> So, wouldn't the simplest two-factor authentication be an SSH key that
>> required a password?

> No, there is no way to verify that a user has enabled a passphrase on an
> ssh key.

No... I mean...

If I create an SSH key that requires a password (ie, not a 'blank' 
password), then when I use this ssh key to connect to the system it was 
created for, and it asks for the password...

This is, as far as I can see, a poor man's 'two-factor' authentication, 
is it not?

Re: [gentoo-user] Re: scripted iptables-restore

[Alan McKinnon]

On 18/10/2013 16:05, Tanstaafl wrote:
> On 2013-10-18 7:19 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> On 18/10/2013 12:23, Tanstaafl wrote:
>>> On 2013-10-17 10:30 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>>>> I apologize.  That is arguably a two factor system.  When you said
>>>> "ssh key and password", I "jumped to delusions", assuming that it was a
>>>> standard ssh connection with the option of either key or password.
>>>
>>> Side question...
>>>
>>> So, wouldn't the simplest two-factor authentication be an SSH key that
>>> required a password?
> 
>> No, there is no way to verify that a user has enabled a passphrase on an
>> ssh key.
> 
> No... I mean...
> 
> If I create an SSH key that requires a password (ie, not a 'blank'
> password), then when I use this ssh key to connect to the system it was
> created for, and it asks for the password...
> 
> This is, as far as I can see, a poor man's 'two-factor' authentication,
> is it not?
> 


I think you are misunderstanding how ssh keys work.

You do not create "an SSH key that requires a password", instead the
user sets up private key encryption locally with a secret. To use the
key it must be unlocked (decrypted) and only then can ssh use it. This
is completely under the USER's control, who is free to protect or not
protect the private key as they feel like. sshd on the server is unable
to enforce or influence this in any way.

Secondly, the statement "use this ssh key to connect to the system it
was created for" is nonsensical. A key pair has two components - public
and private keys, and the only thing sshd cares about is whether the
user connecting has the matching private key to the public one sshd can
read locally. The user is free to use that public key on as many or as
few servers as he feels like, and again sshd is in no position to
enforce or influence this. It is completely up to the user what he does
with his keys.



Perhaps you mean that on the server end the user's account has a
password defined and sshd is configured to use PAM. The PAM config could
require that the user authenticates successfully with ssh keys AND with
the Unix password before logging the user in. This can be done, but it
is not a common configuration and does not ship out the box. It will
also confuse the living daylights out of the average user who at least
in my world is unable to differentiate between a local ssh prompt for a
key passphrase, and a remote telnet prompt for a password...




-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] scripted iptables-restore

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]

On Oct 13, 2013 9:15 PM, "Michael Orlitzky" <michael@orlitzky.com> wrote:
>
> On 10/13/2013 06:08 AM, Martin Vaeth wrote:
> >>> 5. You can't script iptables-restore!
> >>
> >> Well, actually you can script iptables-restore.
> >
> > For those who are interested:
> > net-firewall/firewall-mv from the mv overlay
> > (available over layman) now provides a separate
> > firewall-scripted.sh
> > which can be conveniently used for such scripting.
> >
>
> You snipped the rest of my point =)
>
> > You can write a bash script that writes an iptables-restore script to
> > accomplish the same thing, but how much complexity are you willing to
> > add for next to no benefit?
>
> If you have a million rules and you need to wipe/reload them all
> frequently you're probably doing something wrong to begin with.
>
> With bash, you can leverage all of the features of bash that everybody
> already knows. You can read files, call shell commands, pipe between
> them, etc. You can write bash functions to avoid repetitive commands.
> You can write inline comments to explain what the rules do.
>
> Something like,
>
>   # A function which sets up a static mapping between an external IP
>   # address and an internal one.
>   #
>   # USAGE: static_nat <internal ip> <external ip>
>   #
>   function static_nat() {
>       iptables -t nat -A PREROUTING  -d "${2}" -j DNAT --to "${1}"
>       iptables -t nat -A POSTROUTING -s "${1}" -j SNAT --to "${2}"
>   }
>
> can make your iptables script a lot cleaner, and it conveys your intent
> better when the rule is created:
>
>   # Danny likes to torrent "linux isos" at work so he needs a public ip
>   static_nat 192.168.1.x 1.2.3.x
>
> I'm not saying you can't do all of this with iptables-restore, just that
> you're punishing yourself for little benefit if you do.
>

One benefit of being familiar with iptables-save and iptables-restore : you
can use iptables-apply.

Might save your sanity if you fat-fingered your iptables rule.

Just do `iptables-apply -t 180 <( preprocessor.sh new-rules.conf)`. Changes
are done atomically. After 180 seconds, if you don't indicate to
iptables-apply that the changes are proper, it atomically reverts the whole
netfilter tables.

bash scripts are powerful, but there might be unexpected cases that render
the netfilter tables to be wildly different from what you actually want.

The file format used by iptables-{save,restore,apply} is more like a
domain-specific language; less chance of partial mistakes. And it's atomic:
Either everything gets applied, or none gets applied (without clobbering
existing in-effect rules).

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 3356 bytes --]

Re: [gentoo-user] scripted iptables-restore (was: Where to put advanced routing configuration?)

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Oct 13, 2013 5:09 PM, "Martin Vaeth" <vaeth@mathematik.uni-wuerzburg.de>
wrote:
>
> >> 5. You can't script iptables-restore!
> >
> > Well, actually you can script iptables-restore.
>
> For those who are interested:
> net-firewall/firewall-mv from the mv overlay
> (available over layman) now provides a separate
> firewall-scripted.sh
> which can be conveniently used for such scripting.
>

Thanks, Martin! I was about to create my own preprocessor, but I'll check
out yours first. If it's what I had planned, may I contribute, too?

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 781 bytes --]

[gentoo-user] Re: scripted iptables-restore (was: Where to put advanced routing configuration?)

[Martin Vaeth]

Pandu Poluan <pandu@poluan.info> wrote:
>
> Thanks, Martin! I was about to create my own preprocessor, but I'll check
> out yours first. If it's what I had planned, may I contribute, too?

Sure, patches are welcome.

Re: [gentoo-user] Where to put advanced routing configuration?

[shawn wilson]

On Fri, Oct 4, 2013 at 5:58 PM, Michael Orlitzky <michael@orlitzky.com> wrote:

>
> 1. The iptables-restore syntax is uglier and harder to read.

I don't get this - the syntax is *chain and then :tables (with
optional counters) instead of -N, and then a bunch of rules, and then
a COMMIT command (the only thing you don't get on the command line.
What am I missing or how is this uglier?

Re: [gentoo-user] Where to put advanced routing configuration?

[Michael Orlitzky]

On 10/13/2013 06:26 AM, shawn wilson wrote:
> On Fri, Oct 4, 2013 at 5:58 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> 
>>
>> 1. The iptables-restore syntax is uglier and harder to read.
> 
> I don't get this - the syntax is *chain and then :tables (with
> optional counters) instead of -N, and then a bunch of rules, and then
> a COMMIT command (the only thing you don't get on the command line.
> What am I missing or how is this uglier?
> 

That's not the syntax, because there is no syntax, but let's forget that
point anyway because it's subjective.

[gentoo-user] Re: Where to put advanced routing configuration?

[Martin Vaeth]

shawn wilson <ag4ve.us@gmail.com> wrote:
> On Fri, Oct 4, 2013 at 5:58 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
>
>>
>> 1. The iptables-restore syntax is uglier and harder to read.
>
> I don't get this - the syntax is [...]
> What am I missing or how is this uglier?

Argument separation (e.g. if you have arguments with spaces);
it seems to work most of the time if you quote into "..."
and escape backslash and doublequote signs inside with
backslash (this is what the mentioned script of firewall-mv
does), but there are cases where this is not accepted;
e.g. quoting every word was not accepted.
Since the format is undocumented, this is all ugly
trial-and-error, and only the iptable maintainers know
whether it remains the same in the next iptables release.

Re: [gentoo-user] Where to put advanced routing configuration?

[thegeezer]

On 10/03/2013 08:27 PM, Grant Edwards wrote:
> Let's say you wanted to configure routing of TCP packets based on destination 
> port like in this example:
>
>   http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html
>
> [which contains a series of 'ip' and 'iptables' commands to get packets
> destined for port 25 to use a specific gateway.]
>
> How do do this the "right" way on a Gentoo system?
>
> Based on reading http://www.gentoo.org/doc/en/home-router-howto.xml, I think 
> I've figured out how to do the iptables part: you enter the 'iptables' 
> commands by hand to get the iptables set up the way you want, then you do 
> this:
>
>   # /etc/init.d/iptables save
>   # rc-update add iptables default
>
> What about the 'ip' commands required to set up the tables, routes, and 
> rules?  Do those go in a startup script somewhere? Does one just edit 
> /etc/iproute2/rt_tables by hand? One would assume route configuration belongs 
> in /etc/conf.d/net -- I've read through the advanced networking stuff in the 
> handbook, but it's not apparent to me where those 'ip' command belong.
>
in /etc/conf.d/net just add the following (adjust as appropriate)

rules_eth1=(
    "from all to 8.8.8.8/24 lookup 101"
)

[gentoo-user] Re: Where to put advanced routing configuration?

[Grant Edwards]

On 2013-10-03, Grant Edwards <grant.b.edwards@gmail.com> wrote:

> Let's say you wanted to configure routing of TCP packets based on destination 
> port like in this example:
>
>   http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html
>
> [which contains a series of 'ip' and 'iptables' commands to get packets
> destined for port 25 to use a specific gateway.]
>
> How do do this the "right" way on a Gentoo system?
>
> Based on reading http://www.gentoo.org/doc/en/home-router-howto.xml, I think 
> I've figured out how to do the iptables part: you enter the 'iptables' 
> commands by hand to get the iptables set up the way you want, then you do 
> this:
>
>   # /etc/init.d/iptables save
>   # rc-update add iptables default

FWIW, it turns out using that facility wasn't appropriate.  The
iptables rules were dependent on info that's only available after the
interface comes up and obtains its configuration via DHCP.  So
everyting (both 'ip' commands and 'iptables' commands ended up in
/etc/conf.d.net in the postup() function for setup and the predown()
function for teardown.

-- 
Grant