Firepower cant handle long HTTP request (SCEP request)

[lyutov_dv]

Hi!

I have a problem... We have A SCEP server behind firepower and i want to limit access to it from some networks only with specific URL (<server address>/certsrv/mscep/mscep.dll/pkiclient.exe&operation=). I want to do it to prevent connecting to admin part of SCEP server.

I created an access rule for this URL and it works when client is trying to recieve CA cert but it doesnt work to send SCEP request. I think it happens because it cant reassymbly long TCP or HTTP stream and it cant see the full URL. When i capture traffic i see what firepower blocks connection before client sends full request.

What TCP or HTTP parameters on firepower should i tune to avoid this behavior?

[Marvin Rhoads]

If you're trying to create an ACP that filters on an https URL you would need to decrypt and re-sign to fully parse the full URL (i.e. including the section following the top level domain (if using DNS) or server address).

URLs of up to 255 characters should be supported by default.

[lyutov_dv]

It's HTTP request.

[Marvin Rhoads]

OK.

Can you share the access control policy details you are using?

Generally an ACP will be first match rule only - so if the more specific rule isn't first it will never be hit.

[lyutov_dv]

There are no deny rules before the rule i describe

The problem here what firepower cant reassymbly tcp packets and receive full http request to retrieve URL from it.
For exmple everything is ok if http request is not so long as SCEP request

For example:
SCEP CACertREQ works - http://<scep_server_name>/certsrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert&message=<scep_server_name>

But SCEP CAReq doesnt - http://<scep_server_name>/certsrv/mscep/mscep.dll/pkiclient.exe?operation=PKIOperation&message=MIIJhgYJKoZIhvcNAQcCoIIJdzCCCXMCAQExDzANBglghkgBZQMEAgEFADCCBH0G%0ACSqGSIb3DQEHAaCCBG4EggRqMIIEZgYJKoZIhvcNAQcDoIIEVzCCBFMCAQAxggFG%0AMIIBQgIBADAqMBMxETAPBgNVBAMTCExhbW9kYUNBAhNuAAAXOuA02LSTzSTdAAAA%0AABc6MA0GCSqGSIb3DQEBAQUABIIBAEWh1othOUg%2Fy3ZRqtOVk1DEx%2FqXnjlAakrE%0AzfCTDQvolIHRLu4tQ4DH%2FL0TlnBBX%2FKHVASGpIXZvcvmNnvuXrGvq%2BS9viXpsbUe%0AHZAwmx3W%2B9yrdGwXaZFMtIJNTqoBsK1F%2B2TSrBGNAjpCNE5uoP3q4sVS4OM5qf99%0AV%2FnYrJTUAJxANHl61oYYBIZBxhE7iOA3D15UP354I4hYnpcM7yQAEik18WjAN4QM%0A1YeoQ5O1mXCCE4jdFScNBs42zboCl%2BlVPv2p%2FiKieiMGfYbb9J2YKfUlDxAgS9sa%0AbczLtVL0jT3uU0eB2IHHft1zpAKnv0KFF85BvXc1lx7Vmt3leVIwggMCBgkqhkiG%0A9w0BBwEwEQYFKw4DAgcECMQ2FgcYommXgIIC4IGaAXsvM%2ByFjrtNO%2FooUwXIE68Y%0AQEVtISPn3NjL7....

[Rahul Govindan]

Can you check if the Intrusion rule with GID 119 SID 15 is enabled and set to drop? Rule should be called "(119:15) HI_CLIENT_OVERSIZE_DIR". The documentation for this rule states:

This event is generated when the http_inspect pre-processor detects a request for a URL that is longer than a specified length. This may indicate an attack or an attempt to evade an IDS.

The default length seems to be 500 characters. 

[lyutov_dv]

"(119:15) HI_CLIENT_OVERSIZE_DIR" is disabled but the connection is blocked by Default access rule not IPS