Re: A firewall won't stop this one
From: Stephen K. Gielda (steve_at_No-Spam-packetderm.com)
Date: 11/07/03
- Next message: Rip Van Winkle: "Who made Lovsan"
- Previous message: Volker Birk: "Re: help please"
- In reply to: Volker Birk: "Re: A firewall won't stop this one"
- Next in thread: Volker Birk: "Re: A firewall won't stop this one"
- Reply: Volker Birk: "Re: A firewall won't stop this one"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 7 Nov 2003 06:37:23 -0500
In article <bofq5n$l13$01$1@news.t-online.com>, bumens@dingens.org
says...
> Stephen K. Gielda <steve@no-spam-packetderm.com> wrote:
> > That depends. For example, I have a network firewall, layered security,
> > and my hosts are bastion. On top of that I implement IPF on each host
> > for further access control to limit NFS, etc.
>
> Hm... with NFS in this sentence I find it difficult to talk about
> security at all ;-)
True. But restricting access only to systems that require access is
better than leaving it open to all systems, correct?
>
> > I consider that more
> > secure than not running IPF because without IPF every host on my network
> > can exploit new portmapper exploits as they appear. With IPF it limits
> > my exposure.
>
> For that you're right - but IPF never had such an exploit and I cannot
> see how that should work for now. I must repeat it: I'm not arguing
> against any host based filtering. Not at all. My point were the so
> called "Personal Firewalls", which you find mainly on Windows systems.
>
> >> > Tiny will not run any unapproved exe, nor give mem or disk access to
> >> > unapproved processes when properly configged.
> >> You saw what I did? I did not run an executable. I just told the Windows
> >> Explorer to do things for me.
> > Yes, but that code to get exploder to run that app in a combo box call
> > will not get executed if tiny is set up properly.
>
> Of course it will not - this box executes by using ShellExecute, and
> the shell functions they will have superseeded. You even can superseed
> them by using Windows' Policies, as we both know.
>
> What I tried to point to is the fact that with the messaging system
> you can force the allowed applications to do for you what your
> "Personal Firewall" tries to deny for your process. So you're bypassing
> any "sandbox".
No argument there, but a system with tiny restricting access to mem,
disk, and processes is more secure than a system without any
restrictions to mem, disk, and processes.
>
> And there are many ways to bypass the "sandbox". Shatter attacks,
> doing system calls but using system libraries, adding Explorer
> extensions, etc. pp.
>
> > Though I agree
> > shatter or DLL injection is possible, but much more difficult than
> > without tiny.
>
> Why? I cannot see that.
How familiar are you with Tiny?
>
> >> You never saw VHDL code, did you?
> > I used to work for Viewlogic. Verilog, Verisim, etc are software.
>
> Then you should know that there is source code for hardware.
> If you want OpenSource-Hardware, have a look at http://www.opencores.org/
Yeah, I wasn't thinking of making the designs open but was stuck on
thinking about the finished product.
>
> > You said above in this post that "host based filtering does make your
> > host unsecure but not secure."
>
> Sorry, that is a misunderstanding. I just meant that adding untrustworthy
> code to an untrustworthy system does not add security.
>
> ipf is another thing. By using ipf on FreeBSD you're not adding code at
> all - it's already in the kernel.
>
> And a FreeBSD kernel is not an untrustworthy system for what I can see.
>
> > For example,
> > my NFS servers are more difficult to compromise for anyone on my local
> > net with IPF further controlling access than without. That is an added
> > layer and worthwhile one.
>
> Hm... I think the problem with NFS is that it is unsecure by design.
> I cannot see how ipf could help there.
By restricting access to the NFS server. If my file server and a
secretary's system are on the same net and he/she should not have access
to the file server there is no need to allow her machine to even see the
open ports.
>
> > Same goes for remote buffer overflows, if your network is
> > compromised and no host based filtering is implemented it is easier for
> > someone to compromise your hosts than if you had further access control
> > via port filtering that only allowed specific hosts rather than all.
>
> Sorry, no. Not at all. If you're only doing port filtering, nothing
> changes. There is no difference in that a port is closed by a port
> filter or by not having a listening process at that port. So not
> starting processes which listen on that ports does the same job. It
> does that job even better.
The port restriction changes it. Take this example, two systems on the
same hub, one is the NFS server and one is a general box that does not
need access to that NFS server. Portmapper has a new exploit and the
NFS box has not yet been patched. In your model if I'm in control of
that system that doesn't need access, because it can access that NFS
port, I can compromise the NFS server from that box. In my design, I
don't allow that box to even see the open NFS ports, you cannot
compromise the NFS server from that box. That is more secure than your
design.
>
> The only point for port filtering could be, that some addresses in
> your network may use a service and some may not. Then, when a daemon
> does not support that, port filtering can help. But NFS daemons all
> support that BTW.
>
> I'm not only arguing against "Personal Firewalls", I must repeat.
> I also showed alternatives, i.e. the scripts for which I posted
> links here, which stop Windows to have so many unwanted services.
>
My point is not unwanted service, my point is wanted services, but not
wanting every single host on that network segment to have access to
those wanted services. It's another layer of security and it is better
than without it for the example I gave above. I'm not arguing that it
is the end all of security, nor even that it is totally 100% secure,
just that it is a level of access control that does not exist without
that port filtering and as such it's better to restrict running services
only to machines that need it than to leave it open to every unsecured
machine on the Net.
/steve
-- You simply cannot get more server side control of your e-mail without running your own mail server and knowing how to program. http://www.cotse.net/privacyservice.html
- Next message: Rip Van Winkle: "Who made Lovsan"
- Previous message: Volker Birk: "Re: help please"
- In reply to: Volker Birk: "Re: A firewall won't stop this one"
- Next in thread: Volker Birk: "Re: A firewall won't stop this one"
- Reply: Volker Birk: "Re: A firewall won't stop this one"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
