How to enable IP reputation in as few lines as possible, and the implications?

[Ronan OBrien]

How to enable IP reputation in as few lines as possible, and the implications?

[Ronan OBrien]

en fe reputation

add responder policy drop-all-malicious client.IP.SRC.IPREP_IS_MALICIOUS

bind responder global drop-all-malicious 100 END -type REQ_DEFAULT

The implications of this is that Each and every request that comes into the appliance that is HTTP will be evaluated. The sourceIP will be looked up in the IP rep list, and if it's there, the request will be silently dropped.

It might be more appropriate to bind this to all internet facing VServers instead of a global binding. It's also nice to turn on logging. This would mean allowing customisable log messages, creating a specific log message for this protection, and then invoking it from the responder policy above.

https://support.citrix.com/article/CTX200908/how-to-create-message-action-to-log-to-syslog-on-netscaler

But the 3 lines above on their own will be sufficient to evaluate al inbound requests.

[Johannes Norz]

That's true. I totally agree about not bind IP reputation globally. I miss statements about the implications:

  

Binding globally would affect all vServers, including the ones you'll add in future, and in a non-obvious way. It won't be visible on vServer level, neither by opening the vServer, nor in visualizer.

The implication of IP Reputation feature:

 The feature is based on webroot's database. Webroot runs several sensors all over the internet and is, therefore, able to detect IP addresses of malicious computers. It puts these IP addresses into its database. An incoming request is compared to (an offline-copy of) this database. If the IP is in, IP reputation will notice.

There are several types of malicious IPs (ranging from infected PCs to TOR network endpoints), and in addition to .IPREP_IS_MALICIOUS we also have .IPREP_THREAT_CATEGORY (see here https://docs.citrix.com/en-us/citrix-adc/current-release/reputation/ip-reputation.html). That way, you could potentially filter things like TOA network endpoints. Based on my experience, I would not use thread categories like spam sources or similar, as infected PCs usually change their behaviour quite frequently. Webroot's reaction would potentially be too slow, even though they are pretty fast.

One more: Webroot's database is also available with several firewall solutions. Usually, we filter as soon as possible, so I'd prefer the filtering mechanism of the firewall. Filtering on both sides, firewall and NetScaler doesn't make sense and adds unnecessary latency.