Date: Mon, 12 Dec 2005 18:44:42 +0100 From: "Marcus Franke" <MFranke@evendi.de> To: <freebsd-pf@freebsd.org> Subject: AW: Firewall concepts Message-ID: <AE41C3C123D61B45B457F3037275842F1E0996@DC-EX-001.evendi.local>
next in thread | raw e-mail | index | archive | help
>=20 > The main problem comes when they need to offer some kind of service > that requires inbound connections, such as traditional servers, some > multimedia and p2p protocols. > Ok, but normal client machines won't need such stuff, when I detect someone using file sharing on the company machines, that will make me really angry. =20 > shared ruleset is the way to go. If the latter, then having an > independent per-machine configuration file is the way to go. You can > even implement a middle ground by use of anchors or textual inclusion > using some kind of preprocessor (email me if you want a copy of one). > Sounds interesting, you have such a software that would compile the actual ruleset for the local machine depending from textfiles which could be stored on a single directory mounted from a controlling server? For example, this is the way Windows works and fetches their policy sets from domain controllers :) > I've never been exactly sure what problem "the registry" or "active > directory" solves. The former is a hierarchical namespace containing > configuration information, which sounds like a filesystem to me. What > program variables are considered "configurable" seems somewhat > arbitrary. Can you explain what problem ActiveDirectory solves? I'm > willing to bet if you can tell me the requirements, I can point you to > an open-source solution. There is something called OpenLDAP... The registry is just a configuration database for local software. Could be done in files in /etc/ or elsewhere. Different solutions for the=20 same thing. One could be scary about flat files, others about the registry. I fear neither the one solution nor the other. And OpenLDAP is just another directory server like the ActiveDirectoy is one. They are rather similar. Just, the integration of the client software Win2k and WinXP is very high? Sorry, missing the words to express it in English. You can control the clients in the domain with good working tools from a single point. In my eyes this is a powerful solution, even when=20 only few aspects of this solutions will be used. The problem, in my eyes, isn't to fear the solution instead one should try to use its power and learn to use it for something good. Sure, there are a lot of problems in software from Redmond :) But, a lot of problems I see in daily work with windows is software that isn't programmed very well. Like software that needs write access in its own directory.. brrrr And the easy way to solve it, is to give the user more rights than it is good for him/her. There are a lot of problems with software written in php, but do we say php is evil? Or Unix is evil because there are programms written in php that will enable some people to hack my servers? > Trying to centralize access control on one firewall machine is a > useful idiom, but can become challenging as the links to "untrusted" > networks increases, for example when some internal user installs a > modem or WAP. Now the outside world has equivalent access to what was Have seen this once, a modem directly connected to the server :) And everyone could try to dial into the box. There should be a dial back rule for this. Or a good VPN.. > If increasing bandwidth doesn't do it, end-to-end encryption with be > the death knoll of a centralized firewall or NIDS system, as the ports > used and application data will be unavailable to any system in the > middle (unless of course all systems escrow their keys with the > firewall or gateway, which is complex and problematic and defeats the > purpose of end-to-end encryption). Yeah, SSL proxying.. sounds evil to me, too. Regards, Marcus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AE41C3C123D61B45B457F3037275842F1E0996>