|
||||||||
Hi Brandon, On Sun, 2004-02-22 at 09:52, Brandon Holland wrote: > In my opinion, whether or not something is legal doesn't necessarily > mean I want to ALLOW it on my network. I could give several examples > here, but I think we understand this. Agreed - ping replies, for one - but it was just a comment, not a "reason" as such. > Now, I personally like the idea of protecting against port scans. > Whether or not it's illegal, I don't care to let anyone know WHAT ports > I have open. Even if I'm as safe as possible, someone running a port > scan "across the board" to find that I have port 3245 open as a web port > and they have a new web vuln for apache 2.whateverihave then this could > sufficiently protect me. (Assuming that the portscan block has engaged > prior to the scanner trying port 3245.) Personally, I have nothing against blocking IPs that have hit varius ports in a specified period of time, such as a port scan would do. I just don't know if it would be applicable to m0n0wall's "small, secure" ideology. > Secondly, the "Anti DoS" idea to me is not anywhere near as important, > as a true DoS can't really be blocked. Maybe this could help however. > (I think about potential kernel panics etc from certain (unknown to us > as of now) vulns. Blockinn return ACKs would make sense. However, how much more in terms of CPU and RAM resources would this require? It would, of course, be disabled by default were it actually added. > Since these kinds of things can't be provided internally to the network > and I believe fall under the definition of firewall as found via > google's web def - > <firewall_def> > A firewall is a set of related programs, located at a network gateway > server, that protects the resources of a private network from users from > other networks. Basically, a firewall, working closely with a router > program, filters all network packets to determine whether to forward > them toward their destination. A firewall is often installed away from > the rest of the network so that no incoming request can get directly at > private network resources. There are a number of firewall screening > methods. A simple one is to screen requests to make sure they come from > acceptable (previously identified) domain names and IP addresses. For > mobile users, firewalls allow remote access in to the private network by > the use of secure logon procedures and authentication certificates. > </firewall_def> > > I'm actually for them. For what - firewalls? So am I. There are many definitions of a firewall. I'm sure the Google definition is but one of the multitude, and probably quite unlikely to be the accepted industry definition, however it is probably close. > However - it still must match the current setup: simple, small and > efficient would be a good start, and then it must match Manuel's purpose > too. Agreed. My initial arguement against this was due to the added complexity it would result in, the added size, the added resource requirements, and the added likelihood a vulnerability in code could compromise the firewall, therefore your LAN. I still think they'll be things quite a way down the "wish list", but they have a right to be wished for by people. I'm just not holding my breath on their inclusion. :) -- Regards, Hilton Travis Phone: +61-(0)7-3343-3889 Manager, Quark AudioVisual Phone: +61-(0)419-792-394 Quark Computers http://www.QuarkAV.com/ (Brisbane, Australia) http://www.QuarkAV.net/ Open Source Projects: http://www.ares-desktop.org/ http://www.mamboband.org/ Non Linear Video Editing Solutions & Digital Audio Workstations Network Administration, SmoothWall Firewalls, NOD32 AntiVirus Conference and Seminar AudioVisual Production and Recording War doesn't determine who is right. War determines who is left. |