Subject: Re: tis on rh linux 6.1

From: Joseph S D Yao <[email-masked]>
Date: Tue, 14 Mar 2000 13:04:46 -0500

[To be removed from this list send the message "unsubscribe fwtk-users" in the
BODY of a mail message to [email-masked].]

On Mon, Feb 21, 2000 at 01:55:37PM -0700, Blair Lowe wrote:
> router[ipchains]/firewall[fwtk] config. I thought that this was a 
> standard configuration? The LINUX Firewall HOWTO recommends it in 
> fact.
> 
> I suppose you could screw up your netperm-table config too, so what's 
> the difference?

FWTK is a pure TCP proxy firewall kit.  It contains absolutely nothing
that allows IP through.  Thus any attacks [which I shall not detail]
that rely on getting specific IP packets to internal hosts are blocked.
In addition, good proxies can screen the content, which they cannot if
some IP forwarding software "end-runs" them.

Some people who care more about access than this particular form of
security will open UDP or unproxied TCP ports via an IP filter of some
sort.  If that is your priority, then fine.  If you are doing it for
someone else, make sure that they understand the vulnerability
tradeoffs.  And watch those configurations, of course!

-- 
Joe Yao				[email-masked] - Joseph S. D. Yao
COSPO/OSIS Computer Support					EMT-B
-----------------------------------------------------------------------
This message is not an official statement of COSPO policies.

---

From: Blair Lowe <[email-masked]>
Date: Fri, 17 Mar 2000 13:14:49 -0700

Hi Joseph,

Thanks for your reply (and your smap patch).

I see what you mean with respect to the advantages of not allowing 
packets to be forwarded at all. Having said that, though, internal 
users usually should have transparent access to the outside, and 
running auth, and GW programs on a gateway machine means that there 
is alot of extra training, maintenance, and time spent authenticating 
on the firewall where it may not be necessary.

As far as I know, the Linux's ip_forward code just allows the kernel 
to scan packets before any other programs get a hold of them (by 
using ipchains), and it is essential for LINUX IP address 
translations (or IP Masquerading).

When I refer to turning on ip_forwarding, I am not meaning that I 
want to port forward packets to another box. That is done by a 
separate kernel module, and a program called ipmasqadm.

I don't see how using ipchains is vulnerable. If anything it is more 
robust since one is physically denying not only suspect TCP packets, 
but also icmp, and UDP packets as well. With some pinning down of the 
ftp connection ports as is done with some ftp-gw patches, and by 
running the LINUX spoof protection kernel module one should be able 
to run a VERY tight ship. The only vulnerability is by setting up a 
poor packet filter or by forgetting to turn on spoof protection.

The point is that if the packet filtering is done at the kernel 
level, then it acts as if it is a distinct router, and that turning 
on "ip_forward" in linux does not mean that you are opening anything 
up unless you have set up a poor router system with ipchains. So 
running ipchains AND fwtk is a wicked combination that gives internal 
users absolute freedom, while external services are clamped down.

Flames and furthur discussion are encouraged:)

Blair.

>tradeoffs.  And watch those configurations, of course!
Computer Engineering Inc. http://www.compeng.net
Phone: 780 499 5687 (9 - 5 MST) Fax:   780 435 0693 (24 Hours)
All email advice that is provided for free is without warrantee: use 
at your own risk.

---

From: "Bill Kocik" <[email-masked]>
Date: Mon, 20 Mar 2000 12:11:06 -0800

> on the firewall where it may not be necessary.

This is a big problem with non-transparent proxies. You end up in a mode
where you must insist that users use Product X for FTP and Product Y for
Telnet and such, because they're the only ones that support your proxy
configuration. It can be quite a pain.

> translations (or IP Masquerading).

Well, it's IP Firewalling code does that. And it doesn't really scan the
packets, it just looks at the source and destination ports and addresses.
It's just a packet filter. Forwarding allows a machine to transfer incoming
packets on one interface to outgoing packets on another.

> to run a VERY tight ship.

This is a double-edged sword. On one hand, you do get the ability to
consciously deny/reject/accept/log/whatever incoming packets that don't come
in on a port a proxy is listening on, rather than just hoping nothing's
listening on that port (as would be the case if you were using proxies
only). On the other hand, by turning on forwarding you've built a bridge
that an attacker can cross to get into your protected network. It's my
opinion that there are actually three main types of firewalls, the two most
commonly known:
"That which is not expressly prohibited is permitted"
"That which is not expressly permitted is prohibited"
...and a third type, which is how I view proxy only firewalls:
"That which is neither expressly prohibited nor expressly permitted will go
right over my head"
In the third case, you leave the operating system to deal with all packets
that the proxies don't see, and you'd better hope everything's turned off.
At the very least, you're probably leaving yourself open to attack the next
time someone discovers that sending Packet X to Port Y causes the tcp/ip
stack of Operating System Z to go ass over teakettle.

> users absolute freedom, while external services are clamped down.

I agree. A proxy server plus a packet filter or stateful inspection system
plus something like PortSentry configured properly can make for a very
formidable firewall, where each of these by themselves would fall short in
some way. The most secure would be to use a filter in this scenario without
forwarding on, the most transparent would be the same configuration with
forwarding/masquerading/nat on. Proxy what you can, and forward stuff the
proxies can't deal with.

Just my .02

Bill Kocik
Taos Mountain - "The Sys Admin Company"
Santa Clara, California
http://www.taos.com

"Logic is a systematic method of coming to the wrong conclusion with
confidence."

---

From: "Bill Kocik" <[email-masked]>
Date: Mon, 20 Mar 2000 14:46:21 -0800

> HOPE!! You should have configured it that way and had better be testing to
> ensure it
> stays that way. Anyone who configures a firewall and doesn't test it gets
> what every they get.

Hope, check, ensure, guarantee, it's all semantics. You can plainly see what
my point was. Maybe it would have been clearer/more accurate if I'd said
that the philosophy of proxy-only firewalls assumes that the OS has been
locked down, not necessarily that the admin is left to hope this is the
case. I prefer to do everything in my power leave *nothing* to human error,
even if I'm the human in question. I trust myself, but I'm not perfect.

> Nope no such beast.

Wrong. There are many well-known instances in which this has been the case.
The infamous Windows nukes/teardrops/bonks are one such example (not that
Windows is anything better than laughable as a firewall platform anyways).
For a while, the Linux kernel was also subject to similar attacks in the 2.0
series (Note: That's the *kernel*, not an application) before it was fixed.
I'm sure these are not the only cases, either.

The biggest problem I see with this is that a popular philosophy concerning
firewalls is that it's far more important to protect your local network than
it is to protect your firewall itself, and if you're using proxies only than
theoretically noone should be able to bypass the firewall to get into the
local LAN, even if the firewall itself is compromised as a sacrificial lamb.
The fatal flaw I see in this thinking is that if someone compromises the
firewall, what's to stop them from turning on port forwarding in the OS and
using it as a jumping off point to get to the rest of the network? No, I
don't personally know how this could be done, but it's theoretically
possible and that's enough for me.

> There were only a few things that too many IP stack writers (Such
> as noone would send sync with ack...)
> took for granted and if you on an os that doesn't deal with all
> possibilities then thats a
> cruddy os to use for a firewall.

Cruddy or not, there is always the chance that any operating system is
vulnerable to something along these lines, whether someone has figured it
out yet or not (Note: I said "chance", not "guarantee"). The worst exploits
are the ones that we don't know about yet. And even if this can't happen,
it's _still_ hard to argue that setting up a packet filter in addition to
your proxy isn't better security than a proxy alone. You say above that
anyone who doesn't ensure their operating system is locked down tightly by
testing their firewall deserves whatever they get (paraphrasing). My
question is, what are you testing for exactly? Known vulnerabilities? What
about as-yet-undiscovered vulnerabilities? How do you test for those? I  can
just as easily say that anyone who puts all their faith in the belief that
their OS has been made impenetrable (because nmap said so or something) and
chooses not to set up a filter also deserves whatever they get.

What's the difference?

Whether you necessarily agree with my arguments or not, I believe the point
I was going for is hard to argue against: Proxying plus filtering is
inherently safer than proxying alone (unless, of course, your filtering
software itself introduces a vulnerability....but that's a whole other
discussion ;-).

> now our it's worth .03 ;-)
> --------------------------------------------------------------------------
----
> Don Smith                               General Dynamics Information
Systems

General Dynamics, eh? I nearly took a job with a firm that wanted to place
me there once in their Michigan location. Neat company (GD, that is). Things
didn't work out between myself and the placement firm, though.

Bill Kocik

---

From: "Luis Fernando Barrera" <[email-masked]>
Date: Mon, 20 Mar 2000 19:31:14 -0600

Hi,

These arguments were very interesting. So... 

1) A firewall made of proxies +  packet filtering is the most secure version. However
    the IP forwarding option must be turned off, right? 

   Something is not clear to me... If you use IP Masquerading (i.e. NAT), you need
   to turn on the IP forwarding option, right? 
   So, the mere posibility that someone could use your FW as a bridge, it's a tragedy!

   I understand that if you have an IP network with public addresses and a machine that is
   acting like a router (i.e. IP forwarding  ON), is the biggest risk.
   However if you're using  IP Masquerading (in Linux), that means you have an internal network, with
   private addresses, and the FW box maps those addresses...So, * how can anyone use  the firewall as a bridge? * 

  Maybe this is the point...It doesn't matter if you can make a hell of a packet filter (with spoof protecion),  
  if someone (even in theory) can take advantage of the forwarding option of the firewall , and make
  the entry in your network...

Maybe someone can make a conclusion out of this...

Luis Fernando Barrera
[email-masked] 
Assist Software Development

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Bill Kocik
> Sent: Lunes 20 de Marzo de 2000 04:46 PM
> To: [email-masked]; Donald J Smith
> Subject: Re: tis on rh linux 6.1
> 
>

---

From: Bill Kocik <[email-masked]>
Date: Mon, 20 Mar 2000 22:20:14 -0800

>     the IP forwarding option must be turned off, right?

For utmost security, yes, it's best to have forwarding turned
off.

>    So, the mere posibility that someone could use your FW as a bridge, it's a tragedy!

Yes, that's true. But in configuring any firewall system one must
find a balance between security and usability that fits their
particular needs. If you need forwarding, you turn it on. If you
can't live with the risk, you don't.

>    private addresses, and the FW box maps those addresses...So, * how can anyone use  the firewall as a bridge? *

The one way that immediately pops into my head is by using source
routed frames (which any TCP/IP stack worth it's salt will drop
like a hot rock...heck, even NT does this). There may be other
ways, though, but the fact that I cannot think of more is
irrelevant. By definition, if your firewall is capable of and
willing to pass a packet from one interface to another to
facilitate communication between an external and internal host
(without proxying for it) in either direction, there's a risk.
Even if it's only a theoretical risk, it's a risk. Oh yeah,
another way just came to mind: spoofing. It's simple enough to
guard against this, but it seems every time someone thinks
they've created a secure OS/application/network, someone else
comes along and proves them wrong.

>   the entry in your network...

That's exactly it. I've just never been very good at brevity.

> Maybe someone can make a conclusion out of this...

There are no conclusions, only preludes to further discussions.
:-)

---

From: [email-masked]
Date: Tue, 21 Mar 2000 13:45:55 +0300

-----BEGIN PGP SIGNED MESSAGE-----

nuqneH,

> configuration. It can be quite a pain.

Not at all. You just say: i suggest using X,Y or Z for ftp or A,B or C
for telnet and you can get instructions <here>. If you use another
program, it is your problem to configure it.

It is generally not a good idea to use random software in corporate
environment anyways. Sometimes it is even a good idea to strictly prohibit 
usage of things not checked by IT security. (I'd say most of
times, but some people think i am too paranoid).

                                     _     _  _  _  _      _  _
 {::} {::} {::}  CU in Hell          _| o |_ | | _|| |   / _||_|   |_ |_ |_
 (##) (##) (##)        /Arkan#iD    |_  o  _||_| _||_| /   _|  | o |_||_||_|
 [||] [||] [||]            Do i believe in Bible? Hell,man,i've seen one!

---

From: Donald J Smith <[email-masked]>
Date: Mon, 20 Mar 2000 14:40:07 -0700

>> Thanks for your reply (and your smap patch).
cut above

>stack of Operating System Z to go ass over teakettle.
Nope no such beast. It is almost always not the tcp/ip stack but rather a
application
problem. There were only a few things that too many IP stack writers (Such
as noone would send sync with ack...)
took for granted and if you on an os that doesn't deal with all
possibilities then thats a 
cruddy os to use for a firewall.
>"Logic is a systematic method of coming to the wrong conclusion with
------------------------------------------------------------------------------
Don Smith                               General Dynamics Information Systems
Systems Administrator                   8005 South Chester St
                                        EngleWood, Co. 80112
Phone (303) 649-7554
FAX   (303) 649-7504			[email-masked]
Error msgs that I love: 
"Keyboard not found press F1 to continue" (pc bios)
"Harddrive controller failure insert new disk and press any key to
continue" (pc bios)
"The disk is write protected Remove the write protect or
 use another disk." (nt)
User must change his password before he logs in the first time. (nt)
------------------------------------------------------------------------------

---

From: Blair Lowe <[email-masked]>
Date: Tue, 21 Mar 2000 10:24:10 -0700

>times, but some people think i am too paranoid).

I suppose there are different degrees of how paranoid you should be 
depending on what's at stake.

The main problem I have found in setting up a firewall IS the ftp 
product. The problem is that it has a totally stupid way of 
maintaining a session (new SYN packets in the middle of a session 
???), and there are hundreds of proprietary canned packages out there 
for Windows and Mac that we CAN'T configure, and that are essential 
for some people's business (eg. the guy whose website is on your 
machine has webbuilder1-2-3 that has ftp built in).

Blair.

---

From: Donald J Smith <[email-masked]>
Date: Tue, 21 Mar 2000 12:23:38 -0700

>even if I'm the human in question. I trust myself, but I'm not perfect.
OK I didn't mean to get into semantics. My point was test your firewall no
matter what type of firewall it it.
>using it as a jumping off point to get to the rest of the network? No, I
echo 1 > /dev/proc/kernal.stuff/foward_tcpip_packets  or something like
that in RH6.0.
>> cruddy os to use for a firewall.
The main thing these tcp/ip stack attacks took advantage of was the fact that
OS tcp/ip stack programers were not taking into account all the possible
TCP/IP flags combinations. They were programming for all the reasonable
combinations
not all POSSIBLE combinations.  This flag field is only 6 bits long and I
believe
most of the stack programers are covering every combination in their current 
implementation. An else at the end of a case statement to handle (throw
away) any weird
combinations is all that should be required. 
>out yet or not (Note: I said "chance", not "guarantee"). The worst exploits
With the above implementation there is no reason a guarentee couldn't be
given.
The tcp/ip data structor is well known. Any programers that aren't
accounting for 
all possible combinations shouldn't be programing the tcp/ip stack of any os. 
>software itself introduces a vulnerability....but that's a whole other
No it is not a different discussion. By opening your firewall to include
filtering you must 
add code to the kernal(potentially bad) and allow packets (potentially bad)
thru your firewall directly. 
A proxy doesn't allow any direct ip packets thru it works at the
application level.

Now if you suggest a indepth approach with one box as the application
gateway (proxy)
and another as the packet filtering (outside the proxy) then I would agree
whole heartly with you.
You have added to the security without risking the proxy firewall.
But adding anything to the proxy firewall adds to the risk.
I happen to like linux's ipchains/packet filtering stuff and will use it on
a proxy firewall when I believe it 
adds to the security but thats only when I don't have a GOOD proxy app for
something that needs to pass thru the 
proxy firewall. (example upd-relay )

---

From: "Bill Kocik" <[email-masked]>
Date: Tue, 21 Mar 2000 12:43:18 -0800

> matter what type of firewall it it.

I won't disagree with you there.

> combinations is all that should be required.

That's fine. But whatever the reasons were, there have been in the past
attacks that resemble sending Packet X to Port Y to crash Operating System
Z. That's all I was saying. I never discussed the reasons for these
vulnerabilities, only that they have existed in the past and that they could
crop up again in the future, and a proxying only firewall will not defend
(itself) against them (that is...the internal network would be safe).

> all possible combinations shouldn't be programing the tcp/ip stack of any
os.

You missed what I was saying. I was saying that I don't guarantee that any
particular OS is vulnerable to one of these attacks, only that there was a
chance that any of them might be. I wasn't talking about guaranteed
security.

> No it is not a different discussion.

That was a figure of speech. Are you always like this?

> By opening your firewall to include
> filtering you must

Yes.

> A proxy doesn't allow any direct ip packets thru it works at the

Right.

> But adding anything to the proxy firewall adds to the risk.

Even the proxies? I mean, come on, can you honestly say that you're better
off *not* adding firewall software to your firewall? "Yes sir, we feel the
naked operating system is pretty secure, and we're afraid that adding
Firewall 1 might introduce unknown vulnerabilities." See how that sounds?

But, I do see your point, to a degree. I just personally feel that the
benefits of the packet filter far outweigh the considerably small risk that
they themselves are vulnerable. I can't swallow that you're safer not
filtering than using a filter that could theoretically be exploitable. I
suppose putting them on a seperate machine would be the safest possible way
to use them, though. I think at this point you and I are almost totally in
agreement on the technical issues, with perhaps some differences in
philosophy.
:-)

> proxy firewall. (example upd-relay )

I like it, too. Currently I'm using Solaris (with parts of FWTK and parts of
T.Rex) as my firewall, and have been arguing for weeks with ipfilter about
outbound FTP. I never had this much of a problem with IP Chains.

Bill Kocik

---

From: [email-masked]
Date: Wed, 22 Mar 2000 14:37:32 +0300

-----BEGIN PGP SIGNED MESSAGE-----

nuqneH,

I just don't believe. I've never seen ftp programs that had username/server
name hardcoded that way so one can not set it up to use user@host syntax.

Haven't seen webbuilder, though, but i think it's unlikely to expect such
a strange behavior.

                                     _     _  _  _  _      _  _

---

From: "Luis Fernando Barrera" <[email-masked]>
Date: Wed, 22 Mar 2000 12:20:52 -0600

> > all possible combinations shouldn't be programing the tcp/ip 
> stack of any
> os.
> 

Everything above is correct, no programmer should be doing systems
if he/she is not accouting for all the possible combinations... However, the programmers
are humans, so * always * will be a chance that exists a security hole.
If you are security aware, it's better not to put a door in front of your house, than
putting a door with a lot of locks, even if they're the most secure locks in the world...
Of course in that case you would't be able to  leave/enter your house, that's the tradeoff!

> > proxy firewall. (example upd-relay )

The point again is that with packet filtering you have to turn on the IP
forwarding option in the firewall, which is a bad idea...right?

Sorry if my comments were a little behind the conversation... but I think
parts of it are private an others are not...

Luis Fernando Barrera
[email-masked]

---

From: Donald J Smith <[email-masked]>
Date: Wed, 22 Mar 2000 12:41:17 -0700

>Of course in that case you would't be able to  leave/enter your house,
that's the tradeoff!
Ok using your analogy we have a door now do we add an alarm (by drilling a
hole in the door) or
do we believe door is better without the hole. 

In the linux-bastille code the programers have added ipfw/ipfilter to get a
simple network intrustion audit capability.
Since this is a host based security configuration application this seems
like a good ideal.

In some firewalls I've built I only load a couple of the proxies. 
So I guess my point is that it reallys depends on what your trying to
implement as to weather adding 
a packetfilter ON your firewall adds to the security or not.