Hi, Brian J. Murrell wrote: >> Have a look at the deprecated BLACKLISTNEWONLY > > I'm already using this with =No. > >> or the new BLACKLIST option: >> http://www.shorewall.net/manpages/shorewall.conf.html > > Probably not available in the 4.4.26.1 that I'm using on Ubuntu LTS. > Yeah: > > Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option > below.
I guess you were aware about the pro/cons when choosing an LTS release, weren't you? ;) However, it should be easy to backport a current shorewall release (you could use the official SRC package from testing/SID and re-build it against your LTS version). For me, backporting a package is much more easier than fighting with an outdated version knowing that all your problems are addressed in a current version. >> If a legitimate source will get blacklisted while doing an >> authorized port scan, your portscan rules are way too sensitive. > > Yes. Ideally, handling the portscanning that one (however > reluctantly) agrees to when one connects, say, to an IRC server as > "authorized portscanning" in opposition to unauthorized port scanning > is the way to go, however I don't want to have to play the cat & > mouse game of deciding who is authorized to do port scans because of > what my users are doing and who is just rattling door knobs randomly. > I have better things to do with my time. With "too sensitive" I meant something like: 1: Source A can try to connect to port 80 at 13:00:00. 2: Source A can try to connect to port 443 at 13:00:01. 3: Source A can try to connect to port 8080 at 13:00:02. 4: But source A cannot try to connect to port 3128 at 13:00:03 anymore, because source A was blacklisted at 13:00:02 due to your portscan rule, which only allows 3 unsuccessful scans within 5 seconds. => 3 unsuccessful connections within 5 seconds are too sensitive (The values are just examples) If you have to deal with this kind of legitimate network traffic, you cannot use such a sensitive rule (or you have to whitelist). It is the same like supporting FTP: Can you control client's FTP settings? No? So you need to allow a lot of ports because you don't know which ports your users will use. You could limit the risk if you would maintain a list of allowed FTP addresses. It's your choice. But you cannot be restrictive, be user-friendly (=not limiting the local ports) and keeping the administrative overhead low (=not maintaining a list of allowed FTP servers) all at the same time. And to be honest, I don't consider port scans as important. Furthermore I don't think I gain much information from denied traffic at all (but I am still logging denied traffic, but using a limit like Tom). Money quote: > Enabling logging of "allow" actions gives you visibility into all > traffic into the environment. This is especially important since most > threats target open ports rather than closed. Most important for me to know: What *is* normal traffic in *my* environment? With this knowledge I am able to define trigger and can set alerts to get notified when something unusual will happen. => From my point of view you are doing it wrong if you care so much about typical background noise like port scans and looking for a solution to blacklist one way, but want to bypass blacklist when you start the communication. But don't get me wrong. I am just sharing my experience with you and I am not saying that I am right :) That's why I asked for another use case to learn something new (but your IRC example doesn't convince me, sorry).. -Thomas ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
