Thanks for taking the time to research, write, and send this to 
Scientific Linux!  The best way to get this included in a new version of 
Scientific Linux is to get the fix included further up stream.[1]  That 
way groups other than this one can benefit from your work on this 
issue.  From our side we try not to deviate very much from what our 
upstream provider is doing.  Our hope is that by following them closely 
we reduce the possible problems our users encounter.  But this can lead 
to some tension in the application of patches, particularly patches that 
fix problems.

One of the best ways we can give back to our upstream providers is fixes 
like this one.  I hope that you can open a bug with them so that 
everyone can benefit from this.  As a point of etiquette, they prefer 
not to have mention of SL on their bug tracker.  Our source, for any 
package they provide, is their source.  Any patches we apply are noted 
in the changelog with justifications and generally attributed to Connie, 
Troy, myself, or the Scientific Linux Development list.

Right now our commitment to improving SL, assisting upstream in fixes, 
and generally trying to give back to the linux community at large gives 
us pause before applying any patch for upstream packages which doesn't 
have an associated bugzilla number.  They've given us so much, we want 
to try and give back where we can and help encourage others to do so in 
the spirit of the open source movement.

Again, thank you for your efforts here!  Please feel free to continue to 
contribute regularly to [log in to unmask]



[1] http://bugzilla.redhat.com/


On 2/24/20 6:06 AM, tech wrote:
> As this is a "system component" feature,  I hope this is the right list
>
> Scientific Linux 7.7, with latest update.
>
> If there are more than 255 IP addresses associated with a service in 
> /etc/hosts.deny,  then when any service which calls tcp_wrappers is 
> invoked,  the process hangs, eventually taking 100%CPU.
> Any new request to tcp wrappers invokes another process which likewise 
> eventually reaches 100% CPU.   Effectively initiating an unintended  DoS
>
> I run exim as my MTA
>
> I run a script which looks for certain messages
>
>>     "no host name found for IP address"
>>     "rejected after DATA"
>>     "refused: too many connections"
>
> in the /var/log/exim/   mainlog, rejectlog and paniclogs
> which indicate invalid connections to the server, and then places the 
> Class C  IP address of these in hosts.deny, against exim
>
> extract below from hosts.deny
>
>> exim: 1.215.,103.141.,103.16.,103.20.,103.230.,103.233.\
>> ,103.69.,103.74.,103.76.,109.100.,109.224.\
>> ,109.61.,109.72.,112.78.,114.199.,115.75.\
>> ,117.103.,121.65.,122.228.,123.143.,125.138.\
>
> In the past two weeks, the number of "exim reject messages" has 
> increased such that the number of IP addresses  associated with exim 
> in hosts.deny reached  256, with the result,  as explained above,  
> that each connection to the email server started a new instance of 
> exim, which never completed,  and eventually grabbed 100% CPU.
>
> The logs are rotated every week and the list of IPs is refreshed.
>
> The prevalence of hacking is on the increase, so to get greater than 
> 255 instances in a week is not becoming uncommon.
>
> Could the code be updated to allow more than 255/256 instances.
> (255/256 are common computing numbers!!)
>
> Thank you
>
> Me

-- 
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org