Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Steve_Pearson
Participant

Traffic being dropped by Anti Malware

I'm troubleshooting a problem with users unable to log into the backblaze website. It reports an issue fetching the account however if I switch to a broadband connection it works fine!

Checking the logs I see nothing being blocked, however when I run a zdebug I see the following:

@;1564707902;[cpu_6];[fw4_2];fw_log_drop_ex: Packet proto=6 10.110.0.10:62707 -> 62.0.58.94:443 dropped by fw_handle_first_packet Reason: Anti Malware;

 

The first confusing thing is the destination IP appears to belong to Checkpoint.

The Threat prevention policy is set to Optimised but the IPS blade is not enabled (in fact at present only the anti-bot and anti-virus blades are enabled. (not idea I know but this is a temporary measure) Also note that HTTPS inspection is not enabled at present either)

I've tried creating a new rule for the machine in question, disabling all threat prevention, but the issue remains.

Any assistance would be appreciated!

Thanks in advance.

0 Kudos
25 Replies
_Val_
Admin
Admin

Can you find the corresponding logs? It might be, for example, the GW is checking SNI for that server and founds it a malware site. What do the AB logs say?

0 Kudos
Steve_Pearson
Participant

Hi Val,

There are no logs that I can find for this, I've checked in the main logs, and also logs for the AB and the AM blades, I'm only seeing the drops when running a zdebug.

Out of interest, if I try to login from my laptop running the full Harmony Endpoint suite connected to broadband, there are no problems, which indicates that the site is ok. So the issue is only when the connection is going via the gateway.

0 Kudos
the_rock
Legend
Legend

Ok, I know this may sound extreme thing to try, specially during work hours, but to be 100% sure, are you able to disable anti-bot and install policy? If that works, then we are positive something within that blade is causing it. 

0 Kudos
Steve_Pearson
Participant

That is extreme, but it would certainly prove that the AB blade is the culprit!

I'll try this later tonight if I can.

0 Kudos
the_rock
Legend
Legend

I agree, BUT, here is good news...even if you disable the blade and install policy, it would NOT wipe out any existing settings, rules, si easy to put it all back after, just re-enable the and install the policy again.

Personally, I would still make sure I have screenshots of all the existing things related to AB...better be on the safe side.

Andy

0 Kudos
Steve_Pearson
Participant

I agree 100%, record the settings first!

0 Kudos
_Val_
Admin
Admin

Look at the raw logs, search by source and destination. It is extremely unlikely there are no logs at all.

0 Kudos
Steve_Pearson
Participant

I've never tried viewing the raw logs, are you able to advise how I do this please? (I know where they are stored!)

 

0 Kudos
_Val_
Admin
Admin

Search either via SmartView or in SmartViewTracker. The latter is a legacy application available with your SmartConsole installation package. You will need to go to the SmartConsole program folder and find it.

0 Kudos
Steve_Pearson
Participant

Sorry, I didn't realise that you were referring to SmartView when you said to look at the raw logs.

I can't find Smartview Tracker in the SmartConsole folders at all.

SmartView runs but returns an error - Query failed. This is before I even type a query, and for anything I type. I suspect that this may relate to SmartEvent not being enabled? The reason for this is that we are recovering from an incident, so currently running with on box management on a 5800 applicance, and disk space is limited.

 

0 Kudos
_Val_
Admin
Admin

While you are fixing your SmartLog, here is the SmartView Tracker
Screenshot 2023-08-14 at 17.19.16.png

0 Kudos
Steve_Pearson
Participant

Thanks for that!

Running this and filtering by the users IP I see nothing more that the logging in Smartconsole unfortunately, but zdebug still shows the drops.

0 Kudos
the_rock
Legend
Legend

Thats odd, as normally, when someone has issues with log indexing, logs show perfectly fine from old school SV tracker, as @_Val_ pointed out in his screenshot.

So, you dont see anything more from there either?

Andy

0 Kudos
Steve_Pearson
Participant

No I don't, there is just some http and https traffic in the logs, but nothing going to the address that zdebug is showing, which I beleive is a Checkpoint IP address!

I've now also tried an fwmonitor for a short time whilst I tested the login process, but it only sees the packets that zdebug is dropping.

0 Kudos
the_rock
Legend
Legend

Maybe not related to you directly, but I would give this a go

https://support.checkpoint.com/results/sk/sk123075

fw ctl set int mal_conns_dep_limit 0

0 Kudos
the_rock
Legend
Legend

Hey mate,

Did you end up disabling AB blade to see if it makes any difference?

Andy

0 Kudos
Steve_Pearson
Participant

Hi, sorry for the slow reply, I work remotely and had no connection all day yesterday (drunk driver hit a telegraph pole!)

I did disable the AB blade an Monday night, and it resolved this issue, so that was a good move.

I then re-enabled it and tested again and it still worked!

I cleared the cache and rebooted the test pc, it still worked.

Couldn't do anything yesterday, tested again today and it's stopped working again!

0 Kudos
_Val_
Admin
Admin

It's a good time to open that support request with TAC

0 Kudos
the_rock
Legend
Legend

Sorry to hear about the incident. I think that based on all the testing you did, this definitely warrants TAC case. Keep us posted how it goes.

Andy

0 Kudos
Steve_Pearson
Participant

It's with TAC now, they are investigating. I'll let you know the outcome, but will be out of the office for a few days now!

the_rock
Legend
Legend

Sounds good, hopefully it gets sorted out, Im positive.

Andy

0 Kudos
Steve_Pearson
Participant

TAC have come back to me and said "it seems that the URL api002.backblazeb2.com was blocked in TC due to one of our automatic feeds"

They have whitelisted it at their end and it has resolved the issue!

Regards, Steve

0 Kudos
Lloyd_Braun
Collaborator

The default value for DNS trap IP is 62.0.58.94

more detail here:

https://support.checkpoint.com/results/sk/sk74060

It may be a query from your DNS server that is triggering anti malware/anti bot blade to return the DNS trap IP, instead of the real backblaze IP address.

0 Kudos
Steve_Pearson
Participant

Thanks for this, I was unaware of this default address.

I've changed this in the config and sure enough it now reports the same error against the trap address that I set, so it thinks that there is a problem with the DNS lookup I assume.

What bothers me is that this gateway is a temporary solution whilst we rebuild the original one with its original policy. I have access to this and there are no exceptions for this site, and it always used to work fine. It suggests that the site may have been compromised, so I'm hesitant about putting an exception in for it.

As Val suggests, I'm going to raise a ticket with TAC to see what their view on this is.

0 Kudos
_Val_
Admin
Admin

@Steve_Pearson That's odd. I advise you to open a TAC case for this: https://help.checkpoint.com

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events