ICAPS data from proxy is not working

[Qamar Vakil]

I have setup an ICAPS configuration for my Zscaler proxy to send data over Stunnel to Web Prevent following Symantec's documentation. When I try to send some data over ICAPS, I am getting the error "Multipart message body is empty"

I have pasted the logs from FileReader and an ICAP trace output. Any help will be highly appreciated.

 

Thanks

 

FileReader Log

============================================================================

Jun 5, 2018 5:53:01 PM com.vontu.messaging.FileReader start
INFO: Starting statistics manager
Jun 5, 2018 5:53:01 PM com.vontu.messaging.FileReader start
INFO: (DETECTION.2) Detection is now running
Jun 5, 2018 5:53:01 PM com.vontu.logging.LocalLogWriter write
INFO: File Reader started.
Jun 5, 2018 5:53:11 PM com.vontu.icap.RequestDispatcher run
INFO: (ICAP_CONNECTION.1201) Connection (cid=1) opened from host(127.0.0.1:38446).
Jun 5, 2018 5:53:11 PM com.vontu.icap.RequestDispatcher$ConnectionStatsManager logConnectionStats
INFO: (ICAP_CONNECTION.1203) Connection stat: REQMOD=0, RESPMOD=0, OPTIONS=0, OTHERS=1.
Jun 5, 2018 5:54:18 PM com.vontu.icap.RequestDispatcher run
INFO: (ICAP_CONNECTION.1201) Connection (cid=2) opened from host(127.0.0.1:38448).
Jun 5, 2018 5:54:18 PM com.vontu.icap.RequestDispatcher$ConnectionStatsManager logConnectionStats
INFO: (ICAP_CONNECTION.1203) Connection stat: REQMOD=0, RESPMOD=0, OPTIONS=0, OTHERS=2.
Jun 5, 2018 5:54:18 PM com.vontu.protocols.http.AbstractHttpMessageHandler generateCorruptedMessage
WARNING: Handling corrupted message
java.io.IOException: Multipart message body is empty
                at com.vontu.protocols.http.MultiPartMIME.<init>(MultiPartMIME.java:109)
                at com.vontu.protocols.http.MultiPartMIME.<init>(MultiPartMIME.java:73)
                at com.vontu.protocols.http.MultiPartFormData.<init>(MultiPartFormData.java:56)
                at com.vontu.protocols.http.MultiPartFormData.<init>(MultiPartFormData.java:51)
                at com.vontu.protocols.http.MultiPartFormProcessor.processContent(MultiPartFormProcessor.java:50)
                at com.vontu.protocols.http.HttpMessageHandler.processMessage(HttpMessageHandler.java:169)
                at com.vontu.protocols.http.AbstractHttpMessageHandler.handle(AbstractHttpMessageHandler.java:216)
                at com.vontu.protocols.http.jetty8.HttpMessageProcessor.processStream(HttpMessageProcessor.java:75)
                at com.vontu.protocols.WEBmailProcessor.process(WEBmailProcessor.java:159)
                at com.vontu.protocols.MultiStreamProcessor.processStream(MultiStreamProcessor.java:63)
                at com.vontu.protocols.L7Dispatcher.dispatchStream(L7Dispatcher.java:123)
                at com.vontu.protocols.L7Dispatcher.handleContentStream(L7Dispatcher.java:107)
                at com.vontu.protocols.L7Dispatcher.processMessage(L7Dispatcher.java:67)
                at com.vontu.messaging.chain.MessageChain.processMessage(MessageChain.java:194)
                at com.vontu.messaging.chain.MessageChain.run(MessageChain.java:118)
                at java.lang.Thread.run(Thread.java:748)
Jun 5, 2018 5:54:28 PM com.vontu.icap.RequestProcessor run
INFO: (ICAP_CONNECTION.1202) Connection (cid=2) closed(EOF).
Jun 5, 2018 5:54:28 PM com.vontu.icap.RequestDispatcher$ConnectionStatsManager logConnectionStats
INFO: (ICAP_CONNECTION.1203) Connection stat: REQMOD=0, RESPMOD=0, OPTIONS=0, OTHERS=1.
 

 

ICAP Trace output

=========================================================================================

>> 1528225085551 2 127.0.0.1:1344 127.0.0.1:38316 <<
<< 1528225085707 51
REQMOD icap://1.2.3.4:11344/reqmod ICAP/1.0
<< 1528225085707 27
Host: 1.2.3.4:11344
<< 1528225085707 23
User-Agent: ZICAP/1.0
<< 1528225085707 39
Encapsulated: req-hdr=0, req-body=650
<< 1528225085707 12
Allow: 204
<< 1528225085708 29
X-Client-IP: 5.6.7.8
<< 1528225085708 68
X-Authenticated-User: TG9jYWw6Ly9xYXZha2lsQHN0YXRlc3RyZWV0LmNvbQ==
<< 1528225085708 2

<< 1528225085709 650
POST /https-post/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: https://dlptest.com/https-post/
Accept-Language: en-US
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Content-Type: multipart/form-data; boundary=---------------------------7e2b6520512
Accept-Encoding: gzip, deflate
Host: dlptest.com
Content-Length: 749
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: _wpfuuid=194240c7-7db7-4285-932e-efaaefe5ca24; _ga=GA1.2.1689609950.1528205076; _gid=GA1.2.2119822001.1528205076; _sm_au=aaaaaaaaaaaaaaaaaaaa; _gat=1
X-Forwarded-For: 192.0.0.129
Transfer-Encoding: chunked

<< 1528225085710 5
2ed
<< 1528225085710 749
-----------------------------7e2b6520512
Content-Disposition: form-data; name="wpforms[fields][2]"

Classification : HC
-----------------------------7e2b6520512
Content-Disposition: form-data; name="wpforms_513_3"; filename=""
Content-Type: application/octet-stream

-----------------------------7e2b6520512
Content-Disposition: form-data; name="wpforms[id]"

513
-----------------------------7e2b6520512
Content-Disposition: form-data; name="wpforms[author]"

1
-----------------------------7e2b6520512
Content-Disposition: form-data; name="wpforms[post_id]"

53
-----------------------------7e2b6520512
Content-Disposition: form-data; name="wpforms[submit]"

wpforms-submit
-----------------------------7e2b6520512--
<< 1528225085710 2

<< 1528225085710 3
0
<< 1528225085710 2

>> 1528225085765 70
ICAP/1.0 204 No content
Cache-Control: no-cache
ISTag: "Vontu15.0"
>> 1528225085765 1

<< 1528225095435 0
>>Connection closed<<

[DLP Solutions]

Qamar,

Make sure you have configured the DLP Web Prevent sever and reduced the minimum data size to a small number (4-10 bytes).

Also uncheck the Trial Mode setting if you want to block anything.

Good Luck

Ronak

PLEASE MARKED SOLVED WHEN POSSIBLE

[Qamar Vakil]

Thanks I already made sure those configuration were done.

[DLP Solutions]

Does it work when you use just ICAP and not the stunnel?

Also I noticed this.. REQMOD icap://1.2.3.4:11344/reqmod ICAP/1.0

the port says 11134? not sure if that is just a typo.. usually its 1344

Check and make sure that you can connect via Telnet from the zscaler to the DLP Web Prevent server on the specificed port. It should keep an open connection with no 'hello' or banner.

Good Luck

Ronak

PLEASE MARKED SOLVED WHEN POSSIBLE

[Qamar Vakil]

I followed the steps outlined in this tech article https://support.symantec.com/en_US/article.TECH220170.html

 

The port 11344 is for secure ICAP i.e. ICAPS. I am able to see the traffic come over from Zscaler as indicated in my ICAP trace log output

[DLP Solutions]

I would look at the stunnel logs and see if it is connecting properly.. you may want to turn up the logging to see if it actually connects.

Is this on a Linux or windows OS?

As mentioned in the File.. you may need to make sure the communication is done properly.

Good Luck

Ronak

PLEASE MARKED SOLVED WHEN POSSIBLE

[Qamar Vakil]

Stunnel logs are set at level 7 which is the finest level and show nothing. Communications is not the issue as I see packets being tunnelled. It is running on Linux

[Kurt Nikolas]

Qamar - Did you ever get it working? I'm experencing the same issue. 

thx

------------------------------
Dell SecureWorks
------------------------------

[Greggk]

Yes I did, is your integration with MCAS?
This message contains information that is confidential and may be privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message.

[Kurt Nikolas]

No I'm trying to use zScaler. I see traffic being passed and it's just not triggered on known good test data(via https uploads on dlptest.com). I think that NonMultipartAttachment.config may need an entry but Broadcom doesn't help with anything that isn't their own proxy. Thx in advance. 

K

------------------------------
Dell SecureWorks
------------------------------

[Matthew Lopinto]

Piggybacking off of this when you get the configuration integrated, does anyone know how to drop off the "local://" that comes with the authentication header of the ICAP stream? For example: "local://[e-mail]" when it just want DLP to read "[e-mail]". It causes issues with the policies if you have a tiered approach because when it hits AD it doesn't recognize that value.