It seems that Check Point has changed the way that policies are compiled/handled. At one installation I saw a VPN connection break right after the policy was installed the first time from the upgraded management server. Right after that “According to the policy the packet should not have been decrypted” started appearing in the logs and traffic started being dropped.

After a bit of looking around on the Check Point support site about the message it pointed to multiple objects having similar VPN domains. After going through the object database, I managed to find a “copy” of the peer GW object. Basically 2 gateway objects had same external IP address and similar VPN domains defined. Fortunately that “duplicate” entry wasn’t in use so I deleted it. After deleting the duplicate entry and pushing the policy again, the traffic started flowing again.

I wonder why the upgrade verification process showed no errors or warnings. To me it seems they should have shown some sort of warnings about it, as it breaks things.

It seems that I have stumbled upon a interesting Check Point firewall NAT behavior. Namely the firewall does something that it is not ordered to do, it translates the source IP to a different one than in the policy.

Had a static inbound NAT rule where the source address of the client was supposed to be faked to another static address. What happened was that yes the policy installed fine. Yes the client IP address was changed and hidden from the service. But it was changed to an incorrect address. The rule stated that the client IP address be changed to for example 172.16.2.10, but what it was translated to was 172.16.2.100. And the new address did not exist anywhere in the policy database.

And after upgrading that particular management server to R80.20 it refused to compile the policy with that NAT rule in place. Fortunately recreating the NAT rule removed the issue.

The error in the FWM debug logs was for that issue:“Invalid Object in Source of Address Translation Rule 57. The range size of Original and Translated columns must be the same.”

The interesting thing is, that it was fixed simply by deleting the rule and just re-adding it. And yes it was a 1 address to 1 address translation, not a network to 1 address.

Basically what they say is that, the user needs to add a chatbot to their contact list and ask it for money. Then the chatbot gives them a “key” that is valid for a day. Although the service has a 80$ transaction limit, it still feels like a bad idea to me. I can already feel the new “malware wave” coming that tries to exploit this thing on the phones.

When thinking about this service, I really would love to see the analysis they made to say this is a really secure thing to do. How is this channel secured? How are they protecting people against “theft via malware”? I feel like I need to do some research in to that.

The Check Point upgrade guide for R80.20 is quite clear in saying that on a secondary server you should perform a clean install. All is fine and dandy with that. I don’t know if I am the first one to actually run in to a problem with it.

When using the CPUSE clean install feature in the WebUI, it seemed to work. That is after I had resized the partitions to give it enough space to perform the upgrade. It was arguing that 30GB of free space is actually 29.83GB. So, after making the current active install partition smaller all seemed well. Until the reboot that is.

After the server rebooted, I could see the new WebUI and felt excited, that it actually kept the original IP address. As CPUSE had warned that all settings will be wiped that was a nice surprise.

Unfortunately, the nice things ended there. I was unable to log in. The default “admin/admin” combo didn’t work or the previous credentials that i had. Found no hint on the Check Point support site either.

After a bit of googling around ended up just downloading the clean install ISO file and re-installing the machine. If I had used the ISO before instead of the CPUSE, I would have saved a lot of time. I guess that CPUSE clean install feature is not that clean yet.

Yesterday I happened to read a warning by the Estonian police, that there is a new malware campaign. The fact that there is a malware campaign going on is not news to anyone. But what actually caught my attention was the translation quality on the phishing sites.

The warning had a screenshot of a site spreading malware was the classic your computer is infected with a virus scam, but for smart phones. Sites like that have been used for a long time. But the quality of translation has been really bad for those sites. This time the message had quite good quality and a lot of people might actually fall for it.

The message there basically stated that the user had visited a site containing malware or porn and might be infected with a virus. It also contained a threat that your ISP will block your internet access. They have scripted the ISP part, so that they try to get the ISP name from your IP address.

Besides the rise of quality of the phishing text and translation based on the localization info, a lot of the phishing sites have also moved on to using HTTPS. Malware sites have started using certificates that are accepted by web browsers making them a bit harder to detect by unsuspecting users.

It is the first time in years I felt like doing a refresher to my parents on recognizing malicious sites.

Although the issue I am writing about doesn’t exist anymore in version 13.x, it is still relevant to lower versions.

Namely when a user fails to change their password before their password expires completely they can’t log in to the web interface any more. They don’t get an error saying that their password is expired. Neither do they get a prompt to change it. They actually get an error about invalid credentials.

Initially when investigating the issue, I changed the affected users passwords manually. But then I asked one user to try and log in using SSH. What happened was, he was prompted to change his password. After that, he could successfully log in to the web interface again. And no that user did not have CLI permissions. So if you are not in a hurry to upgrade to versions 13.x and up, you still have a workaround.

As it turns out F5 Big-IP LTM devices apply/check password policy only when the user changes their password. What it means is, that users that existed prior to the policy being applied will not have their password expire, etc.

I know that checking the password strength after it has already been set that is “kind of hard”. But the least you can do is set the passwords to expire according to the policy. In the case no expiry time exists it should be set to all users, to make the device actually comply with the policy that it has configured. So, in my opinion that is F5’s oversight.

So in order to actually enforce the policy you must take care that your users change their passwords after the password policy changes to actually apply them.

Although politicians and law-making is not something I usually would write about, it is something I just found interesting.

I think by now everyone who has an e-mail address has come in to contact with spam e-mails. Usually they are sent to sell you something or do some phishing. But as it turns out sending spam e-mails can also make politicians vote in certain ways.

A few days ago, I happened to hear a old recording of a radio show that had multiple politicians as guests. And Indrek Tarand an Estonian representative at the EU was one of them. When the topic of the new “EU copyright bill” came up, he did something that I wasn’t expecting. He completely baffled me with his reasoning behind his decision.

Namely, he said he voted for the bill, because the people who are against the bill supposedly used AI to send spam to him to try make him vote against it. And voting for the new law was his way of reacting to the hundreds of e-mails he got.

So as it turns out, you don’t need to spend a lot of money to lobby a politician in to voting some way. Just try and press the right buttons by sending them spam e-mails. They might just vote your way just because you spammed them not to do it.

As it turns out the Australian House of Representatives has actually passed the “Telecommunications Assistance and Access Bill”. It is basically an anti-privacy bill that should come in to effect as a law early in 2019. It basically requires tech companies to provide access to users encrypted data to law enforcement agencies. Talk of similar laws has been around for a long time already, but no one had actually passed such laws.

Although quite a few people are calling it an anti-encryption bill, it actually doesn’t require the weakening of end to end encryption in the applications/services. What they require is that access to unencrypted data be provided in from the end devices or from some other point where the data is in plain text form. In that sense it is a bit better than other anti-privacy laws that I have heard of. They have acknowledged that weakening the encryption would grant anyone access to the data. But is forcing tech companies to make call-home features or back-doors to everything better? I think that it is a bit better than having weak encryption.

But I also think that such anti-privacy features can still be abused by hackers. As soon as you add a back-door, there is a risk that someone could get access to it and abuse it. There is no guarantee that only the legitimate users would get access to it. And as always it is said that the features would be only used when necessary. So they are trying to say that it wouldn’t be an all-out spying campaign on all the users all the time. But then the good old question comes to mind. How can you be sure that they are not spying on everyone? Simple, you can’t be. As soon as the possibility of eavesdropping exists there is no guarantee of privacy.