Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
John_Fenoughty
Collaborator
Jump to solution

Failed to parse CP site response

In the last couple of weeks I have seen the following error alerting in flurries on multiple sites at the same time. All running R80.30 with HTTPS inspection and URL&App blade, AV, AB etc.

Has anyone else seen this, anyone resolved it?

It is filling the admin mailboxes and I’m concerned that a. Users are having problems or b. Most worryingly that potentially harmful sites are beibg accessed without protection because of ‘fail-open’.

note from these two examples that the blade reporting the issue varies as does the website involved. Goo.gl creature highly in this on multiple sites but there are plenty of other examples.

HeaderDateHour:  4Feb2020 10:49:56; ContentVersion: 5; HighLevelLogKey: N/A; Uuid: {0x0,0x0,0x0,0x0}; SequenceNum: 36; Action: ctl; Origin: fwl-0002; IfDir: >; InterfaceName: daemon; Alert: mail; OriginSicName: N/A; description: Error occur while accessing:goo.gl/forms/gn0vx7tcxe; reason: Failed to parse CP Site Response., check /opt/CPsuite-R80.30/fw1/log/rad_events/Errors/flow_8520_258746 For more details; severity: 3; ProductName: Anti Malware; ProductFamily: Network;

and also:

HeaderDateHour:  1Feb2020  9:43:46; ContentVersion: 5; HighLevelLogKey: N/A; Uuid: {0x0,0x0,0x0,0x0}; SequenceNum: 37; Action: ctl; Origin: fwl-0002; IfDir: >; InterfaceName: daemon; Alert: mail; OriginSicName: N/A; description: Error occur while accessing:cdn.videogram.com; reason: Failed to parse CP Site Response., check /opt/CPsuite-R80.30/fw1/log/rad_events/Errors/flow_8520_206678 For more details; severity: 3; ProductName: URL Filtering; ProductFamily: Network;

 

51 Replies
MartinTzvetanov
Advisor
run top and observe few minutes if any of the process is utilizing a lot of cpu. Is Internet running slow from time to time
0 Kudos
Blason_R
Leader
Leader

So what was the solution in the end? JHFA 211?

Thanks and Regards,
Blason R
CCSA,CCSE,CCCS
0 Kudos
Paul_Stephenson
Contributor

Not yet resolved. I have not installed 211 but may do later this week.

Paul_Stephenson
Contributor

Generally the pair of firewalls have CPU usage below 20%.

0 Kudos
Darren_Fine
Collaborator

I have a similar problem on a freshly upgraded R80.40 JHF T48 

 

Exact same errors  :

Blade Anti Bot

Description Error occur while accessing:/sdktunnel

Failed to handle CP Site request.,check  /opt/CPsuite-R80.40/fw/log/rad_events/Errors/flow_xxxx

 

Have had a case open with TAC since 19th they acknowledged its an issue but no fix etc .. anyone have this on R80.40 and any luck fixing it ?

Paul_Stephenson
Contributor

80.30 HFA 214 does not resolve the issue.

 

 HeaderDateHour: 23Jul2020 10:05:04; ContentVersion: 5; HighLevelLogKey: N/A; Uuid: {0x0,0x0,0x0,0x0}; SequenceNum: 47; Action: ctl; Origin: XXX; IfDir: >; InterfaceName: daemon; Alert: mail; OriginSicName: N/A; description: Error occur while ac cessing:api.usercentrics.eu; reason: Failed to parse CP Site Response., check /opt/CPsuite-R80.30/fw1/log/rad_events/Errors/flow_13967_47372 For more details; severity: 3; ProductName: URL Filtering; ProductFamily: Network;

ak4020
Contributor

good morning from austria, the problem continues with 80.40 and the last updates - we had a case open for weeks directly at cp and nobody could or did not want to solve it. from my point of view, the problem is not in the rad process (we have modified a lot here for test) but in the dns trap itself - and with these errors in the log the response takes 4000ms in some cases - which occurs to me maybe dns trap does not come together with dnssec, but Delaying the answer for so long or what I often don't see at all allowing an answer is really a very unfortunate situation.

John_Fenoughty
Collaborator

@PhoneBoy As you can see from this thread and the large variety of systems, versions and patch levels this is a widespread situation. Could you please make this known to the appropriate Check Point people to get them to look in to this and prhaps post some progress here?

Having to handle this level of 'false positive' alerts, many admins are starting to treat alerts as every day occurrences and this has a real impact on  security.

eth4_
Contributor

I am embarrassed to say how many times I've applied JHFAs and version hopped, at the request of CP support, in hopes of putting an end to these RAD alerts but they persisted from R80.20 to R80.30 (and possibly R80.40 but I can't tell at the moment because I am getting spammed so heavily by the RAD on one gateway (12,000+ alerts a day) that I have sent CP alerts straight to my deleted items folder).

I've had three SRs opened at various points through this issue and no resolution.

UPDATE:

CP contacted me about this issue to learn if the problem persists in R80.40 so I took some time to search my deleted items folder and it seems that the volume of alerts from our R80.40 clusters is 'normal' (4 out of 6000+ yesterday) so, at this point, it appears the issue is not present in R80.40.  The real test will be when we move to R80.40 on our internal clusters as they are the ones responsible for the bulk of the alerts.

0 Kudos
PhoneBoy
Admin
Admin

What does the file mentioned in the log say?
Also, if you haven't already, a TAC case is definitely in order.

0 Kudos
Paul_Stephenson
Contributor

Logfile from an alert just received

Alert info

 HeaderDateHour:  4Aug2020  9:47:19; ContentVersion: 5; HighLevelLogKey: N/A; Uuid: {0x0,0x0,0x0,0x0}; SequenceNum: 3; Action: ctl; Origin: XXX; IfDir: >; InterfaceName: daemon; Alert: mail; OriginSicName: N/A; description: Error occur while acc essing:nebulaie.webex.com; reason: Failed to fetch CP Site Resource. Timeout was reached, check /opt/CPsuite-R80.30/fw1/log/rad_events/Errors/flow_13967_683122 For more details; severity: 3; ProductName: Anti Malware; ProductFamily: Network;

---

Logifle reads:

Flow ID = flow_13967_683122
Flow Termination Status:Failed!
Flow Started (09:47:04)
Flow Ended (09:47:19)
Flow Total Runtime:15 seconds (Timed out)

Flow Steps:
Generic Trap Flow (0 Seconds)
Cloud HTTP Access(IO) (15 Seconds)
End Of Flow Steps

Flow Items:
_indicator@trapper:vsid=0
_indicator@trapper:version=0
_indicator@trapper:session=
_indicator@trapper:service=malware
_indicator@trapper:resource=nebulaie.webex.com
_indicator@trapper:key_len=18
_indicator@trapper:is_ipv6=0
_indicator@trapper:flags=0
Service=malware
Resource=nebulaie.webex.com
FlowError=Failed to fetch CP Site Resource. Timeout was reached
FetchUrl=http://cws.checkpoint.com:80/Malware/malware/6.0?resource=bmVidWxhaWUud2ViZXguY29t&key=123456
ActiveFlows=2
End of Flow Items

Flow Last 383 Debug Messages:

[rad_trap_task.cpp:42] CRadTrapTask::run: [INFO] enter to ...
[rad_chain_runner.cpp:22] CRadChainRunner::insert: [INFO] enter to ...
[rad_chain_runner.cpp:29] CRadChainRunner::insert: [INFO] insert chain 'CRadTrapperHeader:0xf28abd60 is ok
[rad_chain_runner.cpp:22] CRadChainRunner::insert: [INFO] enter to ...
[rad_chain_runner.cpp:29] CRadChainRunner::insert: [INFO] insert chain 'CRadTrapperMessage:0xf28abe60 is ok
[rad_chain_runner.cpp:22] CRadChainRunner::insert: [INFO] enter to ...
[rad_chain_runner.cpp:29] CRadChainRunner::insert: [INFO] insert chain 'CRadCacheEnabler:0xf28abf50 is ok
[rad_chain_runner.cpp:22] CRadChainRunner::insert: [INFO] enter to ...
[rad_chain_runner.cpp:29] CRadChainRunner::insert: [INFO] insert chain 'CRadTrapperFetcher:0xf28ac040 is ok
[rad_repository_container_data.h:127] CRadRepositoryContaineData::get: [INFO] enter to ...
[rad_repository_container_data.h:129] CRadRepositoryContaineData::get: [MISC] list: <CRadValueMap> free objects = 99, used 0 of 100000
[rad_repository_container_data.h:143] CRadRepositoryContaineData::get: [INFO] exit from ..
[rad_chain_runner.cpp:59] CRadChainRunner::run: [INFO] enter to ...
[rad_chain_runner.cpp:73] CRadChainRunner::run: [INFO] going to run chain 'CRadTrapperHeader'
[rad_trapper_header.cpp:228] CRadTrapperHeader::run: [INFO] enter to ...
[rad_buffer.cpp:341] CRadBuffer::read: [INFO] enter to ...
[rad_buffer.cpp:355] CRadBuffer::read: [INFO] going to read: m_dlen = 168, _limit: 16
[rad_buffer.cpp:362] CRadBuffer::read: [INFO] read: m_dlen = 152, _limit: 16, _read_bytes: 16
[rad_buffer.cpp:363] CRadBuffer::read: [INFO] exit from ..
[rad_trapper_header.cpp:208] CRadTrapperHeader::addChainData: [INFO] enter to ...
[rad_trapper_header.cpp:128] CRadTrapperHeader::addChainDataService: [INFO] enter to ...
[rad_repository_container_data.h:127] CRadRepositoryContaineData::get: [INFO] enter to ...
[rad_repository_container_data.h:129] CRadRepositoryContaineData::get: [MISC] list: <CRadValueString> free objects = 198, used 0 of 200000
[rad_repository_container_data.h:143] CRadRepositoryContaineData::get: [INFO] exit from ..
[rad_value_map.cpp:252] CRadValueMap::add: [INFO] enter to ...
[rad_value_map.cpp:271] CRadValueMap::add: [INFO] add indicator 'trapper:service' _value 'malware'
[rad_value_map.cpp:275] CRadValueMap::add: [INFO] exit from ..
[rad_trapper_header.cpp:164] CRadTrapperHeader::addChainDataService: [INFO] exit from ..
[rad_trapper_header.cpp:172] CRadTrapperHeader::addChainDataVersion: [INFO] enter to ...
[rad_repository_container_data.h:127] CRadRepositoryContaineData::get: [INFO] enter to ...
[rad_repository_container_data.h:129] CRadRepositoryContaineData::get: [MISC] list: <CRadValueUInt> free objects = 495, used 0 of 200000
[rad_repository_container_data.h:143] CRadRepositoryContaineData::get: [INFO] exit from ..
[rad_value_map.cpp:252] CRadValueMap::add: [INFO] enter to ...
[rad_value_map.cpp:271] CRadValueMap::add: [INFO] add indicator 'trapper:version' _value '0'
[rad_value_map.cpp:275] CRadValueMap::add: [INFO] exit from ..
[rad_trapper_header.cpp:200] CRadTrapperHeader::addChainDataVersion: [INFO] exit from ..
[rad_trapper_header.cpp:274] CRadTrapperHeader::debug: [INFO] enter to ...
[rad_trapper_header.cpp:276] CRadTrapperHeader::debug: [INFO] serv = 6
[rad_trapper_header.cpp:277] CRadTrapperHeader::debug: [INFO] size = 162
[rad_trapper_header.cpp:278] CRadTrapperHeader::debug: [INFO] item = 5
[rad_trapper_header.cpp:263] CRadTrapperHeader::run: [INFO] exit from ..
[rad_chain_runner.cpp:83] CRadChainRunner::run: [INFO] run chain 'CRadTrapperHeader' is ok, l_read_total = 16
[rad_chain_runner.cpp:73] CRadChainRunner::run: [INFO] going to run chain 'CRadTrapperMessage'
[rad_trapper_message.cpp:62] CRadTrapperMessage::run: [INFO] enter to ...
[rad_trapper_message.cpp:94] CRadTrapperMessage::read: [INFO] enter to ...
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1a0
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 152
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_trapper_message.cpp:126] CRadTrapperMessage::read: [INFO] read l_type: 3, l_bytes: 4
[rad_repository_container_data.h:127] CRadRepositoryContaineData::get: [INFO] enter to ...
[rad_repository_container_data.h:129] CRadRepositoryContaineData::get: [MISC] list: <CRadValueSession> free objects = 99, used 0 of 100000
[rad_repository_container_data.h:143] CRadRepositoryContaineData::get: [INFO] exit from ..
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1a4
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 148
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_buffer.cpp:309] CRadBuffer::read: [INFO] enter to ...
[rad_buffer.cpp:319] CRadBuffer::read: [INFO] going to read: m_dlen = 148, _limit: 16
[rad_buffer.cpp:331] CRadBuffer::read: [INFO] read: m_dlen = 132, _limit: 16, _read_bytes: 7
[rad_buffer.cpp:332] CRadBuffer::read: [INFO] read: _output = (session)
[rad_buffer.cpp:333] CRadBuffer::read: [INFO] exit from ..
[rad_trapper_message.cpp:143] CRadTrapperMessage::read: [INFO] read l_name: session, l_bytes: 7
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1b4
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 132
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_session.cpp:85] CRadValueSession::read: [INFO] enter to ...
[rad_buffer.cpp:341] CRadBuffer::read: [INFO] enter to ...
[rad_buffer.cpp:355] CRadBuffer::read: [INFO] going to read: m_dlen = 128, _limit: 8
[rad_buffer.cpp:362] CRadBuffer::read: [INFO] read: m_dlen = 120, _limit: 8, _read_bytes: 8
[rad_buffer.cpp:363] CRadBuffer::read: [INFO] exit from ..
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1c0
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 120
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_session.cpp:109] CRadValueSession::read: [INFO] exit from ..
[rad_trapper_message.cpp:152] CRadTrapperMessage::read: [INFO] read: data <>
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1c0
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 120
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_map.cpp:252] CRadValueMap::add: [INFO] enter to ...
[rad_value_map.cpp:271] CRadValueMap::add: [INFO] add indicator 'trapper:session' _value ''
[rad_value_map.cpp:275] CRadValueMap::add: [INFO] exit from ..
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1c0
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 120
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_trapper_message.cpp:126] CRadTrapperMessage::read: [INFO] read l_type: 1, l_bytes: 4
[rad_repository_container_data.h:127] CRadRepositoryContaineData::get: [INFO] enter to ...
[rad_repository_container_data.h:129] CRadRepositoryContaineData::get: [MISC] list: <CRadValueUInt> free objects = 494, used 1 of 200000
[rad_repository_container_data.h:143] CRadRepositoryContaineData::get: [INFO] exit from ..
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1c4
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 116
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_buffer.cpp:309] CRadBuffer::read: [INFO] enter to ...
[rad_buffer.cpp:319] CRadBuffer::read: [INFO] going to read: m_dlen = 116, _limit: 16
[rad_buffer.cpp:331] CRadBuffer::read: [INFO] read: m_dlen = 100, _limit: 16, _read_bytes: 7
[rad_buffer.cpp:332] CRadBuffer::read: [INFO] read: _output = (is_ipv6)
[rad_buffer.cpp:333] CRadBuffer::read: [INFO] exit from ..
[rad_trapper_message.cpp:143] CRadTrapperMessage::read: [INFO] read l_name: is_ipv6, l_bytes: 7
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1d4
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 100
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_uint.cpp:82] CRadValueUInt::read: [INFO] enter to ...
[rad_value_uint.cpp:94] CRadValueUInt::read: [INFO] read: m_value = 0
[rad_value_uint.cpp:95] CRadValueUInt::read: [INFO] exit from ..
[rad_trapper_message.cpp:152] CRadTrapperMessage::read: [INFO] read: data <0>
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1d8
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 96
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_map.cpp:252] CRadValueMap::add: [INFO] enter to ...
[rad_value_map.cpp:271] CRadValueMap::add: [INFO] add indicator 'trapper:is_ipv6' _value '0'
[rad_value_map.cpp:275] CRadValueMap::add: [INFO] exit from ..
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1d8
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 96
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_trapper_message.cpp:126] CRadTrapperMessage::read: [INFO] read l_type: 2, l_bytes: 4
[rad_repository_container_data.h:127] CRadRepositoryContaineData::get: [INFO] enter to ...
[rad_repository_container_data.h:129] CRadRepositoryContaineData::get: [MISC] list: <CRadValueString> free objects = 197, used 1 of 200000
[rad_repository_container_data.h:143] CRadRepositoryContaineData::get: [INFO] exit from ..
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1dc
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 92
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_buffer.cpp:309] CRadBuffer::read: [INFO] enter to ...
[rad_buffer.cpp:319] CRadBuffer::read: [INFO] going to read: m_dlen = 92, _limit: 16
[rad_buffer.cpp:331] CRadBuffer::read: [INFO] read: m_dlen = 76, _limit: 16, _read_bytes: 8
[rad_buffer.cpp:332] CRadBuffer::read: [INFO] read: _output = (resource)
[rad_buffer.cpp:333] CRadBuffer::read: [INFO] exit from ..
[rad_trapper_message.cpp:143] CRadTrapperMessage::read: [INFO] read l_name: resource, l_bytes: 8
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1ec
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 76
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_string.cpp:98] CRadValueString::read: [INFO] enter to ...
[rad_value_string.cpp:108] CRadValueString::read: [MISC] read: l_size: 18
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f1f0
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 72
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_buffer.cpp:309] CRadBuffer::read: [INFO] enter to ...
[rad_buffer.cpp:319] CRadBuffer::read: [INFO] going to read: m_dlen = 72, _limit: 18
[rad_buffer.cpp:331] CRadBuffer::read: [INFO] read: m_dlen = 54, _limit: 18, _read_bytes: 18
[rad_buffer.cpp:332] CRadBuffer::read: [INFO] read: _output = (nebulaie.webex.com)
[rad_buffer.cpp:333] CRadBuffer::read: [INFO] exit from ..
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f202
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 54
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_string.cpp:123] CRadValueString::read: [INFO] exit from ..
[rad_trapper_message.cpp:152] CRadTrapperMessage::read: [INFO] read: data <nebulaie.webex.com>
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f202
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 54
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_map.cpp:252] CRadValueMap::add: [INFO] enter to ...
[rad_value_map.cpp:271] CRadValueMap::add: [INFO] add indicator 'trapper:resource' _value 'nebulaie.webex.com'
[rad_value_map.cpp:275] CRadValueMap::add: [INFO] exit from ..
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f202
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 54
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_trapper_message.cpp:126] CRadTrapperMessage::read: [INFO] read l_type: 1, l_bytes: 4
[rad_repository_container_data.h:127] CRadRepositoryContaineData::get: [INFO] enter to ...
[rad_repository_container_data.h:129] CRadRepositoryContaineData::get: [MISC] list: <CRadValueUInt> free objects = 493, used 2 of 200000
[rad_repository_container_data.h:143] CRadRepositoryContaineData::get: [INFO] exit from ..
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f206
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 50
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_buffer.cpp:309] CRadBuffer::read: [INFO] enter to ...
[rad_buffer.cpp:319] CRadBuffer::read: [INFO] going to read: m_dlen = 50, _limit: 16
[rad_buffer.cpp:331] CRadBuffer::read: [INFO] read: m_dlen = 34, _limit: 16, _read_bytes: 7
[rad_buffer.cpp:332] CRadBuffer::read: [INFO] read: _output = (key_len)
[rad_buffer.cpp:333] CRadBuffer::read: [INFO] exit from ..
[rad_trapper_message.cpp:143] CRadTrapperMessage::read: [INFO] read l_name: key_len, l_bytes: 7
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f216
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 34
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_uint.cpp:82] CRadValueUInt::read: [INFO] enter to ...
[rad_value_uint.cpp:94] CRadValueUInt::read: [INFO] read: m_value = 18
[rad_value_uint.cpp:95] CRadValueUInt::read: [INFO] exit from ..
[rad_trapper_message.cpp:152] CRadTrapperMessage::read: [INFO] read: data <18>
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f21a
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 30
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_map.cpp:252] CRadValueMap::add: [INFO] enter to ...
[rad_value_map.cpp:271] CRadValueMap::add: [INFO] add indicator 'trapper:key_len' _value '18'
[rad_value_map.cpp:275] CRadValueMap::add: [INFO] exit from ..
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f21a
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 30
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_trapper_message.cpp:126] CRadTrapperMessage::read: [INFO] read l_type: 1, l_bytes: 4
[rad_repository_container_data.h:127] CRadRepositoryContaineData::get: [INFO] enter to ...
[rad_repository_container_data.h:129] CRadRepositoryContaineData::get: [MISC] list: <CRadValueUInt> free objects = 492, used 3 of 200000
[rad_repository_container_data.h:143] CRadRepositoryContaineData::get: [INFO] exit from ..
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f21e
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 26
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_buffer.cpp:309] CRadBuffer::read: [INFO] enter to ...
[rad_buffer.cpp:319] CRadBuffer::read: [INFO] going to read: m_dlen = 26, _limit: 16
[rad_buffer.cpp:331] CRadBuffer::read: [INFO] read: m_dlen = 10, _limit: 16, _read_bytes: 5
[rad_buffer.cpp:332] CRadBuffer::read: [INFO] read: _output = (flags)
[rad_buffer.cpp:333] CRadBuffer::read: [INFO] exit from ..
[rad_trapper_message.cpp:143] CRadTrapperMessage::read: [INFO] read l_name: flags, l_bytes: 5
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f22e
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 10
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_uint.cpp:82] CRadValueUInt::read: [INFO] enter to ...
[rad_value_uint.cpp:94] CRadValueUInt::read: [INFO] read: m_value = 0
[rad_value_uint.cpp:95] CRadValueUInt::read: [INFO] exit from ..
[rad_trapper_message.cpp:152] CRadTrapperMessage::read: [INFO] read: data <0>
[rad_buffer.cpp:382] CRadBuffer::debug: [INFO] enter to ...
[rad_buffer.cpp:383] CRadBuffer::debug: [INFO] m_data: 0xf1c1f232
[rad_buffer.cpp:384] CRadBuffer::debug: [INFO] m_dlen: 6
[rad_buffer.cpp:385] CRadBuffer::debug: [INFO] m_offset: 0
[rad_buffer.cpp:386] CRadBuffer::debug: [INFO] m_dref: 0
[rad_buffer.cpp:387] CRadBuffer::debug: [INFO] exit from ..
[rad_value_map.cpp:252] CRadValueMap::add: [INFO] enter to ...
[rad_value_map.cpp:271] CRadValueMap::add: [INFO] add indicator 'trapper:flags' _value '0'
[rad_value_map.cpp:275] CRadValueMap::add: [INFO] exit from ..
[rad_trapper_message.cpp:175] CRadTrapperMessage::read: [INFO] successfuly read (5) items, values map size = 7
[rad_trapper_message.cpp:176] CRadTrapperMessage::read: [INFO] exit from ..
[rad_trapper_message.cpp:184] CRadTrapperMessage::addChainDataVsid: [INFO] enter to ...
[rad_repository_container_data.h:127] CRadRepositoryContaineData::get: [INFO] enter to ...
[rad_repository_container_data.h:129] CRadRepositoryContaineData::get: [MISC] list: <CRadValueUInt> free objects = 491, used 4 of 200000
[rad_repository_container_data.h:143] CRadRepositoryContaineData::get: [INFO] exit from ..
[rad_value_map.cpp:252] CRadValueMap::add: [INFO] enter to ...
[rad_value_map.cpp:271] CRadValueMap::add: [INFO] add indicator 'trapper:vsid' _value '0'
[rad_value_map.cpp:275] CRadValueMap::add: [INFO] exit from ..
[rad_trapper_message.cpp:210] CRadTrapperMessage::addChainDataVsid: [INFO] exit from ..
[rad_trapper_message.cpp:83] CRadTrapperMessage::run: [INFO] exit from ..
[rad_chain_runner.cpp:83] CRadChainRunner::run: [INFO] run chain 'CRadTrapperMessage' is ok, l_read_total = 16
[rad_chain_runner.cpp:73] CRadChainRunner::run: [INFO] going to run chain 'CRadCacheEnabler'
[rad_cache_enabler.cpp:55] CRadCacheEnabler::run: [INFO] enter to ...
[rad_dataset.cpp:343] CRadDataSet::getServiceSettings: [INFO] enter to ...
[rad_dataset.cpp:327] CRadDataSet::getServiceManager: [INFO] enter to ...
[rad_dataset.cpp:336] CRadDataSet::getServiceManager: [INFO] exit from ..
[rad_dataset.cpp:352] CRadDataSet::getServiceSettings: [INFO] exit from ..
[rad_cache_enabler.cpp:92] CRadCacheEnabler::run: [INFO] service malware not required cache
[rad_chain_runner.cpp:83] CRadChainRunner::run: [INFO] run chain 'CRadCacheEnabler' is ok, l_read_total = 16
[rad_chain_runner.cpp:73] CRadChainRunner::run: [INFO] going to run chain 'CRadTrapperFetcher'
[rad_trapper_fetcher.cpp:54] CRadTrapperFetcher::run: [INFO] enter to ...
[rad_dataset.cpp:417] CRadDataSet::getQuery: [INFO] enter to ...
[rad_repository_container_data.h:127] CRadRepositoryContaineData::get: [INFO] enter to ...
[rad_repository_container_data.h:129] CRadRepositoryContaineData::get: [MISC] list: <CRadQuery> free objects = 99, used 0 of 100000
[rad_repository_container_data.h:143] CRadRepositoryContaineData::get: [INFO] exit from ..
[rad_dataset.cpp:427] CRadDataSet::getQuery: [INFO] exit from ..
[rad_query.cpp:160] CRadQuery::build: [INFO] enter to ...
[rad_http_request.cpp:103] CRadHttpRequest::build: [INFO] enter to ...
[rad_http_request.cpp:81] CRadHttpRequest::getBuilder: [INFO] enter to ...
[rad_http_request.cpp:95] CRadHttpRequest::getBuilder: [INFO] exit from ..
[rad_http_request.cpp:115] CRadHttpRequest::build: [INFO] find builder key new 'malware+0'
[rad_http_request_builder.cpp:68] CRadHttpRequestBuilder::build: [INFO] enter to ...
[rad_http_request_comp_const.cpp:27] CRadHttpRequestCompConstConst::build: [INFO] enter to ...
[rad_http_request_comp_const.cpp:31] CRadHttpRequestCompConstConst::build: [INFO] exit from ..
[rad_http_request_comp_const.cpp:27] CRadHttpRequestCompConstConst::build: [INFO] enter to ...
[rad_http_request_comp_const.cpp:31] CRadHttpRequestCompConstConst::build: [INFO] exit from ..
[rad_http_request_comp_const.cpp:27] CRadHttpRequestCompConstConst::build: [INFO] enter to ...
[rad_http_request_comp_const.cpp:31] CRadHttpRequestCompConstConst::build: [INFO] exit from ..
[rad_http_request_host_64.cpp:35] CRadHttpRequestHost64::build: [INFO] enter to ...
[rad_http_request_host_64.cpp:61] CRadHttpRequestHost64::build: [INFO] 0x95c2ff8'keylen' found (18)
[rad_http_request_host_64.cpp:78] CRadHttpRequestHost64::build: [INFO] 0x95c2ff8'flags' found (0)
[rad_http_request_host_64.cpp:90] CRadHttpRequestHost64::build: [INFO] host resource is nebulaie.webex.com
[rad_http_request_comp_val64.cpp:28] CRadHttpRequestCompVal64::buildBase64: [INFO] enter to ...
[rad_http_request_comp_val64.cpp:41] CRadHttpRequestCompVal64::buildBase64: [INFO] Base64Length: 24, Base64Allocated: 34
[rad_http_request_comp_val64.cpp:42] CRadHttpRequestCompVal64::buildBase64: [INFO] Base64: bmVidWxhaWUud2ViZXguY29t
[rad_http_request_comp_val64.cpp:47] CRadHttpRequestCompVal64::buildBase64: [INFO] exit from ..
[rad_http_request_host_64.cpp:103] CRadHttpRequestHost64::build: [INFO] build indicator 'trapper:resource'
[rad_http_request_host_64.cpp:104] CRadHttpRequestHost64::build: [INFO] exit from ..
[rad_http_request_comp_const.cpp:27] CRadHttpRequestCompConstConst::build: [INFO] enter to ...
[rad_http_request_comp_const.cpp:31] CRadHttpRequestCompConstConst::build: [INFO] exit from ..
[rad_http_request_comp_const.cpp:27] CRadHttpRequestCompConstConst::build: [INFO] enter to ...
[rad_http_request_comp_const.cpp:31] CRadHttpRequestCompConstConst::build: [INFO] exit from ..
[rad_http_request_optional_value.cpp:28] CRadHttpRequestOptionalValue::build: [INFO] enter to ...
[rad_http_request_optional_value.cpp:39] CRadHttpRequestOptionalValue::build: [INFO] unable to find 'cpradus:resend in value map
[rad_http_request_comp_const.cpp:27] CRadHttpRequestCompConstConst::build: [INFO] enter to ...
[rad_http_request_comp_const.cpp:31] CRadHttpRequestCompConstConst::build: [INFO] exit from ..
[rad_http_request_comp_nline.cpp:26] CRadHttpRequestCompNLine::build: [INFO] enter to ...
[rad_http_request_comp_nline.cpp:30] CRadHttpRequestCompNLine::build: [INFO] exit from ..
[rad_http_request_comp_const.cpp:27] CRadHttpRequestCompConstConst::build: [INFO] enter to ...
[rad_http_request_comp_const.cpp:31] CRadHttpRequestCompConstConst::build: [INFO] exit from ..
[rad_http_request_comp_nline.cpp:26] CRadHttpRequestCompNLine::build: [INFO] enter to ...
[rad_http_request_comp_nline.cpp:30] CRadHttpRequestCompNLine::build: [INFO] exit from ..
[rad_http_request_comp_const.cpp:27] CRadHttpRequestCompConstConst::build: [INFO] enter to ...
[rad_http_request_comp_const.cpp:31] CRadHttpRequestCompConstConst::build: [INFO] exit from ..
[rad_http_request_comp_nline.cpp:26] CRadHttpRequestCompNLine::build: [INFO] enter to ...
[rad_http_request_comp_nline.cpp:30] CRadHttpRequestCompNLine::build: [INFO] exit from ..
[rad_http_request_comp_const.cpp:27] CRadHttpRequestCompConstConst::build: [INFO] enter to ...
[rad_http_request_comp_const.cpp:31] CRadHttpRequestCompConstConst::build: [INFO] exit from ..
[rad_http_request_comp_const.cpp:27] CRadHttpRequestCompConstConst::build: [INFO] enter to ...
[rad_http_request_comp_const.cpp:31] CRadHttpRequestCompConstConst::build: [INFO] exit from ..
[rad_http_request_comp_nline.cpp:26] CRadHttpRequestCompNLine::build: [INFO] enter to ...
[rad_http_request_comp_nline.cpp:30] CRadHttpRequestCompNLine::build: [INFO] exit from ..
[rad_http_request_comp_nline.cpp:26] CRadHttpRequestCompNLine::build: [INFO] enter to ...
[rad_http_request_comp_nline.cpp:30] CRadHttpRequestCompNLine::build: [INFO] exit from ..
[rad_http_request_builder.cpp:81] CRadHttpRequestBuilder::build: [INFO] exit from ..
[rad_http_request.cpp:132] CRadHttpRequest::build: [INFO] Request Location 'cws.checkpoint.com:80'
[rad_http_request.cpp:133] CRadHttpRequest::build: [INFO] Request Proxy Location ''
[rad_http_request.cpp:141] CRadHttpRequest::build: [INFO] build request =
GET /Malware/malware/6.0?resource=bmVidWxhaWUud2ViZXguY29t&key=123456 HTTP/1.1
Connection: Keep-Alive
User-Agent: RAD_CLIENT
Host: cws.checkpoint.com:80


[rad_http_request.cpp:142] CRadHttpRequest::build: [INFO] exit from ..
[rad_query.cpp:175] CRadQuery::build: [INFO] build request is successful for service 'malware'
[rad_query.cpp:176] CRadQuery::build: [INFO] exit from ..
[rad_query.cpp:192] CRadQuery::startTripTime: [INFO] enter to ...
[rad_query.cpp:183] CRadQuery::startTime: [INFO] enter to ...
[rad_query.cpp:185] CRadQuery::startTime: [INFO] start time at: 1.59653e+12
[rad_query.cpp:186] CRadQuery::startTime: [INFO] exit from ..
[rad_query.cpp:194] CRadQuery::startTripTime: [INFO] exit from ..
[rad_http_request.cpp:55] CRadHttpRequest::getLocation: [INFO] enter to ...
[rad_http_request.cpp:160] CRadHttpRequest::toString2: [INFO] enter to ...
[rad_http_request.cpp:175] CRadHttpRequest::toString2: [INFO] Fixed request = http://cws.checkpoint.com:80/Malware/malware/6.0?resource=bmVidWxhaWUud2ViZXguY29t&key=123456
[rad_io_tasks_manager.cpp:84] CRadIoTasksManager::scheduleIoTask: [INFO] enter to ...
[rad_io_tasks_manager.cpp:106] CRadIoTasksManager::scheduleIoTask: [INFO] Scheduling HTTP task
[rad_thread_pools_container.cpp:49] CRadThreadPoolsContainer::instance: [INFO] enter to ...
[rad_thread_pool.cpp:50] CRadThreadPool::addTask: [INFO] enter to ...
[rad_thread_pool.cpp:65] CRadThreadPool::addTask: [INFO] task added to queue
[rad_trapper_fetcher.cpp:100] CRadTrapperFetcher::run: [INFO] exit from ..
[rad_chain_runner.cpp:83] CRadChainRunner::run: [INFO] run chain 'CRadTrapperFetcher' is ok, l_read_total = 16
[rad_chain_runner.cpp:87] CRadChainRunner::run: [INFO] succefull running the chain, l_read_total = 16
[rad_chain_runner.cpp:88] CRadChainRunner::run: [INFO] exit from ..
[rad_trap_task.cpp:64] CRadTrapTask::run: [INFO] chain successfull run pass ok, total bytes = 0
[rad_curl_task.cpp:65] CRadCurlTask::run: [INFO] enter to ...
[rad_curl_task.cpp:45] CRadCurlTask::get_my_curl_handle: [INFO] enter to ...
[rad_curl_http_task.cpp:26] CRadCurlHttpTask::configureCurl: [INFO] enter to ...
[rad_curl_http_task.cpp:36] CRadCurlHttpTask::configureCurl: [INFO] Request: 'http://cws.checkpoint.com:80/Malware/malware/6.0?resource=bmVidWxhaWUud2ViZXguY29t&key=123456'
[rad_curl_http_task.cpp:76] CRadCurlHttpTask::configureCurl: [INFO] Set curl shared object
[rad_curl_http_task.cpp:95] CRadCurlHttpTask::configureCurl: [INFO] Curl configuration done
[rad_curl_task.cpp:103] CRadCurlTask::run: [ERROR] handle: 0x96e8060 curl_easy_perform() failed: Timeout was reached

0 Kudos
Eric_Appelboom
Participant

Same issue here. R80.30 take 217 

If one does not background Threat Prevention and URL Filtering engines from hold CPU will increase dramatically.

rad_admin stop addresses but disables reputation services.


curl_cli http://cws.checkpoint.com/APPI/SystemStatus/type/short -v OK
curl_cli http://cws.checkpoint.com/URLF/SystemStatus/type/short -v OK
curl_cli http://cws.checkpoint.com/AntiVirus/SystemStatus/type/short -v OK
curl_cli http://cws.checkpoint.com/Malware/SystemStatus/type/short -v OK but < X-Frame-Options: DENY

top -H -p `pidof rad`
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29010 admin 16 0 235m 123m 26m S 40 0.3 3:18.93 rad_resp_slow_3
29009 admin 16 0 235m 123m 26m S 39 0.3 3:33.24 rad_resp_slow_2
29008 admin 16 0 235m 123m 26m S 38 0.3 3:20.33 rad_resp_slow_1
29007 admin 16 0 235m 123m 26m S 36 0.3 2:52.33 rad_resp_slow_0
29003 admin 16 0 235m 123m 26m S 3 0.3 0:35.48 rad_cpu_0
29004 admin 15 0 235m 123m 26m S 3 0.3 0:34.95 rad_cpu_1
29005 admin 15 0 235m 123m 26m S 3 0.3 0:35.39 rad_cpu_2

Increased malware_cache to 60k but note rapid increase and non 0 rollover

19:19:12 up 1 day, 22:35, 1 user, load average: 3.95, 4.04, 3.72
[Expert@d1350001:0]# fw tab -t malware_cache_tbl -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost malware_cache_tbl 4 59800 0 0
[Expert@dc1001350001:0]# uptime
19:19:19 up 1 day, 22:35, 1 user, load average: 3.80, 4.01, 3.71
[Expert@d1350001:0]# fw tab -t malware_cache_tbl -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost malware_cache_tbl 4 59957 0 0
[Expert@1350001:0]# uptime
19:19:23 up 1 day, 22:35, 1 user, load average: 4.14, 4.08, 3.73
[Expert@1350001:0]# fw tab -t malware_cache_tbl -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost malware_cache_tbl 4 48077 0 0
[Expert@1350001:0]# uptime
19:19:28 up 1 day, 22:35, 1 user, load average: 3.89, 4.02, 3.72
[Expert@1350001:0]# fw tab -t malware_cache_tbl -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost malware_cache_tbl 4 48123 0 0

0 Kudos
John_Fenoughty
Collaborator

The promised 'bundle of improvements' discussed earlier in the thread for RAD came in sk163793

The RAD Hotfix is included in:

I have been doing some more testing today on a site with R80.30 Hotfix 214 - the problem remains pretty much the same, the rate of alerts is still many per day.

I have been looking for patterns in the logged errors:

The errors are all (as most of you know) stored in here:/opt/CPsuite-R80.30/fw1/log/rad_events/Errors

Every RAD error is here, so we can look through them all for patterns and data using grep

I ran this command: grep _indicator@trapper:resource= *

This produces a list of the URL/Resources that have had issues so I could look for patterns

They were random, lots of sites, some I know are real many subpages and other mixed sites - no obvious patterns.

---------------
Second thought:
---------------

This time running:

grep "Flow Total Runtime:" *

This produces a long list of the time the flow took, here we find a very clear pattern.

This is just an example, we have hundreds of these and they ALL fit this pattern:

The flows that run for 0, 1, 2 and 3 seconds are *ALL* bit.ly and goo.gl sites
The flows that run for 15 seconds and then time out are a wide variety of different sites

flow_8575_71242:Flow Total Runtime:3 seconds
flow_8575_72657:Flow Total Runtime:0 seconds
flow_8575_72658:Flow Total Runtime:0 seconds
flow_8575_72659:Flow Total Runtime:1 seconds
flow_8575_72660:Flow Total Runtime:1 seconds
flow_8575_73804:Flow Total Runtime:15 seconds (Timed out)
flow_8575_77486:Flow Total Runtime:0 seconds
flow_8575_77488:Flow Total Runtime:2 seconds
flow_8575_77491:Flow Total Runtime:0 seconds

So my interim conclusion is that we are observing two separate issues here:

  1. A timeout issue - which should be resolved by sk163793 but isn't resolved for me in this case.
  2. An entirely different issue with bit.ly and goo.gl type sites.

I think we may be finding that for the timeout issue this is a genuine timeout and the firewalls are struggling with the load. We'll find out soon because they are nearing end of life and being replaced with the latest higher powered devices (4400 devices being replaced with 6200). This is happening at the same time on a couple of unrelated sites so we'll get a very clear picture.

The bit.ly (and goo.gl) issue is, quite clearly, not about CPU performance but a problem with the parsing of these sites. This is the one we need much more help from Check Point to address! I will log a call for this again, now that I can get all of the performance related stuff out of the picture and TAC can focus on the bit.ly and goo.gl issue.

 

 

 

 

 

Eric_Appelboom
Participant

Hi John,

Agree that sk163793 in R80.30 Take 217 does not address the timeouts. We have no URL shortener errors with all our errors being timeout.

flow_29000_1342073:Flow Total Runtime:15 seconds (Timed out)
flow_29000_1349156:Flow Total Runtime:15 seconds (Timed out)
flow_29000_1351261:Flow Total Runtime:21 seconds (Timed out)
flow_29000_1351263:Flow Total Runtime:21 seconds (Timed out)
flow_29000_1351274:Flow Total Runtime:21 seconds (Timed out)
flow_29000_1351275:Flow Total Runtime:21 seconds (Timed out)

%50 being  XXXXXXXXXXX.safeframe.googlesyndication.com then followed by static.akamaitechnologies.com

We see the errors event when load is  below 2.00 on weekends.

Eric

 

 

 

0 Kudos
Eric_Appelboom
Participant

We are trying this even though it is apparently fixed in later takes we still have many TIME_WAIT's  https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

0 Kudos
John_Fenoughty
Collaborator

Thanks for the update. That's really relevant to this IMHO, that the firewall load does *not* seem to be the issue here. The Akamai element is frustrating, everyone uses WSUS or something better like Ivanti/Heat/Lumension to do Windows updates yet the constant telemetry noise that Windows computers make is something we have to contend with on the gateways - we've tried everything to turn it off in GPO but there's nothing that works.

I'll be logging my call later today, I expect a few days of the usual basics before we get to the relevant point. I'll link this thread into the support call.

Please do let us all know if the sk163793 changes make any difference. I suspect not, but I'm happy to be wrong!

0 Kudos
JohnFenoughty
Participant

I am working with TAC on our timeouts but I can confirm that all of the 'failed to parse' errors were fixed by the RAD bundle integrated in R80.30 hotfix 214.

I would recommend to everyone who still has the 'failed to parse' errors that they get to this hotfix version (or Hotfix Take 127 for R80.20) and let us all know if this resolves it - it looks to me like it will.

It would have been handy if Check Point had told us they were aware of this issue and were writing the fix, we'd have wasted less time trying to resolve it ourselves but I'm very happy we now have the answer.

For the test site I am now proceeding with TAC on the remaining alerts which are all timeout alerts, this matches eric_appelboom's observations. I'll report back to this thread with whatever resolves the remaining alerts.

Eric_Merillat
Contributor

Do we know if this fix has been incorporated into R80.40 yet?  Still seeing the errors after upgrading our customers MDM to R80.40.

 

Thanks,
Eric

0 Kudos
JohnFenoughty
Participant

We have just completed a full R80.40 upgrade, management server and all clusters on a UK site in the last couple of weeks. They don't have these alerts as often as some places (where I'm seeing dozens every day) but they have sufficient to cause the real problem of alert fatigue.

 

Since the upgrades the alerts still come but the wording has changes, so Check Point R&D have clearly been working in this area:

HeaderDateHour: 18Nov2020  7:04:07; ContentVersion: 5; HighLevelLogKey: N/A; Uuid: {0x0,0x0,0x0,0x0}; SequenceNum: 7; Action: ctl; Origin: DS-FWL-002; IfDir: >; InterfaceName: daemon; Alert: mail; OriginSicName: N/A; description: Error occur while acc
essing:deliveryplatform.autodesk.com; reason: RAD request exceeded maximum handing time, check /opt/CPsuite-R80.40/fw1/log/rad_events/Errors/flow_16255_8911 For more details; severity: 3; ProductName: Anti Malware; ProductFamily: Network;

Interesting. :The problem is still a timeout but the wording has changed since R80.40. It’s more informative ‘RAD request exceeded maximum handing time’ and included the URL ‘deliveryplatform.autodesk.com’ so you can be confident that no user had any experience of this as that’s the AutoCad licencing server, it’ll just have retried.

I really think this confirms my impression that just every now and again the lookup connection fails and eventually reaches timeout. If I were to set the timeout to 60 minutes (instead of 15 seconds) I think this would still break. I’ve set it to 30 seconds elsewhere (as recommended by TAC) and it makes no difference whatsoever. This is why I conclude that the connection is lost. They’re pretty rare to the hundreds of thousands of connections to URLs that ones computers make every day, most of which the user never personally requested and so never sees.

I think we would be better off if we could set this to: 'only alert of it sees more than x failures in y seconds' indicating a real problem. Does anyone know how we might be able to do this? Especially if it's a new feature in R80.40 (or perhaps R81?)

0 Kudos
genisis__
Leader Leader
Leader

I've been seeing this issue on a R80.40 GW with Jumbo HFA87.

 

Failed to fetch CP Site Resource. Timeout was reached, check /opt/CPsuite-R80.40/fw1/log/rad_events/Errors/flow_27072_170923 For more

0 Kudos
JohnFenoughty
Participant

I have given up on hoping that Check Point will resolve this. I think we are looking at a case of 'the connection gets dropped every now and again'. Out of the many thousands of URLs being sent up to Check Point for lookup by every firewall out there the number of these failures is actually very very small. Every computer on every site is making hundreds of connections in the background all the time, Microsoft Telemetry and plenty of others. Also every website is made up of many URLs other than the main URL the user is accessing. So I suspect that almost all of the time no user actually sees the site fail.

Considering all of this, and having so much else to deal with - I have created a rule in Office365 to auto-delete any email from the altering account with the words 'Failed to fetch CP Site Resource. Timeout was reached' in it. This way we continue to receive all other relevant alerts and this issue is 'buried'.

ABW
Explorer

I know this is an old thread, but just wanted to share what fixed this for me.

Like others describe here, RAD was running very hot (R81 Take 44 & 65), and there were many, many thousands of "Failed to parse CP Site Response" errors each day. None of the solutions described here, or in other threads helped.

What helped was removing the proxy (global settings), and allowing the gateways to contact the internet directly.

I don't quite know why, since IPS/URLF updates were working fine through the proxy (also on other gateways), but for some reason RAD did not like *something* about the responses, even though there were no MiTM og authentication requirements, and all requests were going through just fine.

Just putting it out there in case somebody has a similar scenario to mine. Try removing the proxy and see if it helps.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events