On 13-10-23 09:06 AM, Thomas D. wrote: > Hi, Hi,
> Well, I don't like to change the way any existing features work: > > - You have to remember, that you have changed something. > > - If you ever want to use a 'traditional' blacklist, you cannot. > > - Any changes upstream will make may break your firewall. All fair points. > Two annotations: > >> My goal here is to add a drop/blacklist rule, dynamically, when fail2ban >> detects a host is doing bad things. A portscan is a good example to use >> for "bad things". But I also want to block/drop any established >> "inbound" connections that are open, for example to shut down a >> brute-force attacking of SSH that might have started before the portscan >> started. > > 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. >> The collateral damage here though is for example, IRC servers that I >> want to connect to that want to do a portscan of me to make sure I'm not >> an open relay. They end up blacklisted in the dynamic chain with no >> regard to whether the packets it's dropping are from outbound >> connections or inbound. > > That sounds like you are trying to fix the wrong problem: > > 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. > I am still wondering why somebody wants to block every connection > attempt from a source but still want to be able to contact that source > at all. Can you share more use cases with us? I just did above. IRC servers like to port scan you before you are allowed to complete a connection to make sure you are not an open proxy being used to do bad things on the IRC server. These port scans fill up logs and hide the real activity that you really want to see in a log with all of this portscanning. Yes, per above, it would be nice to have the time to play the cat & mouse game of handling each one of these "authorized" port scans in a more elegant manner but I don't have the time for that. I'm jealous of anyone that does. b.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
