RFC: firewall-hint_v1.3

Henning Rohde Rohde.Henning at gmx.net
Sun Aug 12 10:12:02 PDT 2001

Hi Jeff,

Thanks again for editing, your comments show me that your knowlegde has
quite some deep roots.

I would like to invite you to make at first one "idiot-proof"-Firewall,
a script that can be copy'n'past-ed, and, if you agree that it makes
sense, a second dokument containing not only a script but being a
comprehensive chapter about "Security at networking with Linux".
I do imagine this like Gerard and Balu and Eric Olinger
did it about Optimization.
Even if this second document would not fit anymore into our one chapter,
many of the security-related documents on linuxdoc.org are quite a bit
outdated, at least IIRC.

Please allow me to do some more intensive snipping to clear the table,
I do agree with every point snipped-out, if you feel the need to discuss
them any further, speak up!  ;-)

jbauman at adsl-63-193-249-142.dsl.snfc21.pacbell.net wrote:
>>But I do only mention where to edit, I do not recommend this edditing.
>>Those who know why they want stuff not to be put elsewhere either know your way
>>or deliberately pay the effort to edit the Makefile.
> I guess I was thinking of the LFS books as a model here -- you're always told
> what commands to use to do the install. Is what we're writing to be
> substantially different from LFS? What model should we use?
If you'd like to follow my invitation we would follow the style of the
LFS-Book for the firewalling-script; I'd like to give the comprehensive
concept a style of using suggestions, those who will use it won't feel
comfortable at being commanded.

>>>>Now compile and install iptables and the utilities for saving and restoring
>>>>via 'make && make install experimental install-experimental'.
> An alternative would be to recommend that people use a script to set up their
> firewalls. Saving and restoring rulesets is not really necessary, then.
> As the KNOWN-BUGS file in the iptables packages says,
> "4) iptables-restore and -save still have problems. Sorry."
> I would not want my firewall security relying on this.
OK, I will take these lines out.
Personally I use them for a second way to display my set of rules, in some
cases the layout of 'iptables-save |less' is better readable than a
'iptables -L -n -v'.

>>>>Alternativly, if you want to ping your box to enshure it's still alive:
>>>iptables -I INPUT  -p icmp -s -m icmp --icmp-type
>>>echo-request -j ACCEPT  # only accept pings from the 20.20.20 network.
>>Again, you're right.	But, why did you chose
> Just a random example. Thought it was a bit more concrete than a
> <your-ip-address-here> sort of thing.
> If the script has to be idiot-proof, then your way is the only way to go.
> As I said above, IF this is possible... Clearly for someone needing to ping
> from anywhere, it is not possible.
OK, lets add a fifth example about one-way-pinging, and a sixth one
with pinging from limited sources.
I'd like to suggest to use, it's my universities net,
this way we would have a more realistic explanation with noone being
offended and at least I could debug in case of copy'n'paste!	;-)

> I'm making the assumption that anyone who can get through LFS in the first
> place is not an idiot.

Hmm, allow me to refer to Gerard or Jesse, I don't remember who, when and
where, but somewhere on LFS, I think, I've read the statement that the
Book has become so detailed and explenatory that even rookies have started
to build a LFS!

Have a look at the mailinglists: IIRC many threads are started by rookies,
mumbling about "the Book does not work for me", ending with Gerard
discovering a typo they (mis-)entered, or errors at copy'n'past or steps
they left-out by overlooking them.
I do not want to call anyone an idiot, bet a rooky-proof script is what I
want to give.

I feel the need to reduce the number of "script does not work..."-mails,
at least I hope to do so with playing on this level.

>>At least IMHO, pings do not harm
> Obviously you've never been the subject of a smurf attack.
You're right, personally I surf the 'net via DSL, this is the scope for
the proposed script.

>>>These rules should be placed early in the chain, before any ACCEPTs, other
>>>than perhaps ESTABLISHED,RELATED connections.
>>Hmm, do you really think that these lines are necessary?
>>I do not doubt that they are helpful for 'the highest security', but Linux is
>>IIRC not vulnerable.
>>They will, like pinging, prevent a automatik dial-off, but because they are
>>caught by stateful-filtering they do not offer any ways to access harmfully any
>>services, at least if I understood the topic correctly.
>>Even scanning does not harm as long as firewalling is done correctly.
> What are you saying, that Linux is not vulnerable to scans? Or that there
> will never again be a bug discovered in a Linux package that is remotely
> exploitable?
Hmm, one moment please, let's define 'scanning':
At least IIRC a scan is the attempt to find out, which services are
accessible on a given host / net.
We may include to this definition further but automatic research for
offered services that suffer known vulnarabilities.

What I neither do proclaim is that the one who does this scanning is
himself harmless nor that there won't be any bugs!
But what I do proclaim is that the act of scanning taken foritself does
not harm and that a exploit of any service would not be prevented by
denying scanning.

Consider the case of having a
(I) solely surfing client:
because it offers not a service, this box solely suffers from
vulnerabilities in the implementation of the used protocols / sockets
(connection-highjacking, ping of death), buffer-overflows in applications
(exploited by malicious servers) and DoS-Attacks satturing it's link.
If I've forgotten any please correct me!

IMHO, none of these dangers is related to scanning, again, please correct
me if this is wrong!

(II) Server
If it's Admin wants it to be accessible to the public it's existance is
publicly known and at least one offered service is publicly known!

A scan gives the attacker an idea about offered but, for now, not
announced services.
If it's Admin wants the server to offer this bunch of services to the
public , he will have setup his firewall to allow corresponding access
and traffic.
Do you really think, that a vulnerability of the mail-service on any
mail-server listed as a MX for it's Domain stays secret because scanning
would be denied?

The exploiting of this vulnerability is done, unfortunately, in the
borders of common definitions of 'corresponding access / traffic',
at least in current implementations of firewalls.

Deny-ing scanning makes IMHO only sense if you (being security-admin for
some network) do not know about services that your hosts offer,
although being responsible for them.
Or, in other words, it helps if you mistakenly have forgotten to secure /
stop a service.

Oh, I nearly forgot something: detection of installed Trojans and
It's a question of the structure of your network and of your
strategical security how you deal with these, to know who did scan you
does IMHO not help.

What are you doing if you read _yesterday's_ log and see that you've
been scanned?
Denying the source IP the scan originated, yesterday morning?
Predictably it will come from an IP assigned to dial-ups for an unknown
ISP, somewhere in lawless foreign countries.
Furthermore it seems to be common to do the scanning from one link and the
accessing from another one.

As always there is no principle without an exception:
One of my friends takes part in the "honey-pot-net":
He's one of those guys who setup appearently unprotected hosts that are
actively monitored for attemps of cracking.
If an attack has been monitored their firewall is dynamically reconfigured
to deny any access from the attacker.

> If someone is scanning me, I want to know about it, and I want to provide as
> little information to that person as possible.

Most of the scans that were done on my firewall were aimed to get the
information, if a Win9x/ME was running on it.

As long as we do stateful-filtering even the mentioned stealthy scans do
not harm because they were written for stateless filtering done by ipchains.

As soon as the filtering-code in our kernel is buggy itself this may prove
elsewise, but in that case everything we talk about is lost!

> ... You must be terribly confident in .. your firewalling skills ...

This has nothing to do with being confident but with having a true
concept of security.

Allow me to remind you of the ever-proofed principle:
	KISS, keep it small 'n' simple!

> I'm beginning to wonder if the best approach to this whole thing might not
> be to provide instructions for installing iptables, and then just point
> them to resources and say, "figure out what you need for your own
> situation" rather than trying to provide rulesets. There are plenty
> of resources out there that already do this.

Hmm, at one thought you're right: we will definitly not be able to
construct the one and perfect firewall, being perfect until the universe
The web is full of examples of these 'perfekt firewalls' containing every
ever so nifty tweak and ever obscure idea to fight the cracker.
Most make you suffer in that moment, when something unusual has to be
setup and you're lost in the need to do debugging.

But what we can give is an rooky-proof script that does not contain too
many caveats that mean need for support from us.
This script may not fit into any immaginable situation and may not prevent
any immagenable attack, but one thing we have to remember always:

The effort spent into an attack corresponds with the value the cracker
expects to gain out of it.
If you are responsible for such great values that you expect great
efforts done by potential crackers, you won't be in the need to rely on
my hint!

Hopefully, that I did not proof to be an idiot myself, I'd again like to
invite you to write with me both documents, one, that's rooky-proof for
the beginners, and a second one, that is a comprehensive collection of
security-concepts for a outline of security in depth.


PS: I leave it to you if we should continue this discussion off-list.
PPS: If somebody else is interested in listening, speak up and we will
     stay on list.

More information about the blfs-book mailing list