Boy that was a loadful. No offences if I've caused any. Firstly, I trust Linux, the author and myself too.
My experience is limited but I've got hacked and have detected portscans. Normally a portscan would take some time depending on how many ports are scanned. However, I'm identifying a portscan by finding out who is opening an port on which I'm not running any service. Secondly, the portscanner from the same IP scans machine in the subnet going thro' this router/ firewall. Thus we will be able to block the IP for the network saving other machines if they have a vulnerability on services that are open. Can the userspace area be made use of to create chains on the fly? Say maybe running a shell script as a service that takes an IP as an argument to create the chain? I do not know if userspace allows this. Mohan -----Original Message----- From: Tom Eastep [mailto:[EMAIL PROTECTED]] On Sat, 3 Aug 2002, S Mohan wrote: >Portsentry has settings where by portsentry > automatically creates a drop target chain for a specific IP from which > it has detected a portscan. > No -- Shorewall has no component that runs continuously so it has no way to monitor firewall log activity. Let me offer you some of my opinions: a) The instance of repeat port scans from the same IP address on my firewall is near zero. That observation is based on my tracking port scans over a period of a couple of years. So adding a rule because someone portscans my firewall is like bolting the barn door after the horse is gone. -Granted. But may not be valid for large network for which this is the incoming router/fw. Further, if the first unopen port being scanned spawns this rule, then we are there before he bolts - right? b) By the time that a port scan is detected, it is well under way. Again, generating rules is too little too late. c) If you trust your firewall then why should you care if someone portscans it? To avoid vulnerability on an open service port. d) If you don't trust your firewall then why the hell are you running it? e) If you don't trust your firewall, do you really feel better because the guy who wrote it doesn't trust it either and would rather spend his time writing code that generates dynamic rules when his firewall is under attack rather than spending his time improving the basic rule set so that it is impervious to attack? Again - I think this is a great effort. I'm not undermining any of this. Please be easy on this. My contention again is to save open services from a marauder. While we also need to patch vulnerabilities on services being made available, this will help reducing instances. f) If the fellow who wrote your firewall often sees repeat port scans from the same IP address, then the port scans must be finding something that might be exploited. Sure. May or may not be updated on patches. Especially on colocated boxes in ISP IDCs this would be useful. g) If every packet entering your firewall must pass a gauntlett of 10000 portscan-generated firewall rules then who wins? -- it's not you! Certainly need to consider this for performance reasons - did not strike me earlier. >From the above observations, I conclude that the only rational dynamic-rule generator is one that detects portscans quickly and instantiates blocking rules for a short period of time until the portscan is over. In other words, it tried to suppress the portscan-generated log message by adding dynamic firewall rules. I personally think that a tool that displays the Shorewall log and suppresses portscan entries would be much easier to build -- if I ever decide to do anything in this area, I will probably explore that idea... -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
