This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

WAF bad reputation checks and http.dnsbl.sorbs.net

It seems the check for http.dnsbl.sorbs.net is not working correctly. My test IP is not listed here http://www.sorbs.net/lookup.shtml but UTM tells me

"Client is listed on DNSRBL http.dnsbl.sorbs.net"

 

I also see this on customer UTMs (had to disable bad reputation checks) - so it seems to be a general problem...

 

Anybody can confirm this too?

 

regards



This thread was automatically locked due to age.
Parents
  • RBLs are optimized for preventing malicious email, so they blacklist dynamic IP address ranges, especially residential address ranges, since email coming from that type of addresses is probably indicative of an infected machine.   So a block result does not mean that you are infected, it just means that you should not be the source of outbound SMTP traffic on port 25.

    When you apply that logic to WAF, you block your own home IP address.  
    The WAF RBL lookups are 

    Options 

    1) Change your WAF settings to

    Leave "Block clients with bad reputation"  = ON
    But set "Skip remote lookups for clients with bad reputation" = OFF

    This disables RBL lookups.   I am unsure what the enabled setting accomplishes.

    2) Change the RBL lookups used for email to exclude filters based on dynamic IP, leaving the known-malicious addresses in place.  This weakens your email defenses, but improves  your WAF defenses.

    On a similar note, some RBL lookups (notably Spamhaus) will be useless if you use a public DNS like Google, because the result will always be "not blocked".    This is because Google does a zone transfer of everything available, but some spam filters do not give away their filter database via zone transfer.   The solution is to use your own DNS server, which will walk the tree until it finds the uncached RBL result that you need.

     

Reply
  • RBLs are optimized for preventing malicious email, so they blacklist dynamic IP address ranges, especially residential address ranges, since email coming from that type of addresses is probably indicative of an infected machine.   So a block result does not mean that you are infected, it just means that you should not be the source of outbound SMTP traffic on port 25.

    When you apply that logic to WAF, you block your own home IP address.  
    The WAF RBL lookups are 

    Options 

    1) Change your WAF settings to

    Leave "Block clients with bad reputation"  = ON
    But set "Skip remote lookups for clients with bad reputation" = OFF

    This disables RBL lookups.   I am unsure what the enabled setting accomplishes.

    2) Change the RBL lookups used for email to exclude filters based on dynamic IP, leaving the known-malicious addresses in place.  This weakens your email defenses, but improves  your WAF defenses.

    On a similar note, some RBL lookups (notably Spamhaus) will be useless if you use a public DNS like Google, because the result will always be "not blocked".    This is because Google does a zone transfer of everything available, but some spam filters do not give away their filter database via zone transfer.   The solution is to use your own DNS server, which will walk the tree until it finds the uncached RBL result that you need.

     

Children
No Data