Updatable Objects for MS Teams matches Github

[Thomas_Eichelbu]

Hello Folks, 

just stumbled over a possible MS Teams problem a customer is fighting for months ...
sometime the Updatable Objects IP matches on a different category ... then of course the policy doesnt match anymore, resulting in a drop.

dynamic_objects -ip 52.113.83.112

The following objects contain IP 52.113.83.112

Object name: CP_MS_Skype
Object type: Updatable Object

Object name: CP_Azure_Azure
Object type: Updatable Object

Object name: CP_GH_GITHUB
Object type: Updatable Object

so IP 52.113.83.112 should be an IP from the O365 MS Teams Range 52.122.0.0/15
https://learn.microsoft.com/de-de/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worl...

this results in a drop on my policy:

@;81095432.634111613;[vs_0];[tid_19];[fw4_19];fw_log_drop_ex: Packet proto=6 10.10.42.68:57203 -> 52.113.83.112:3478 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "POLICY" rule 922;


did anybody notice this already as well?
i was always thinking this Updatable Objects are quite reliable ... but why this IP can matche on sometimes totally different categories? CP_GH_GITHUB & CP_MS_Skype

[Lesley]

I assume you mean 52.112.0.0/14 and not 52.122.0.0/15 , 52.113.83.112 matches the first subnet. 

The issue is that Microsoft states it belongs to them and Github does the same, that it belongs to Github.. Since Github uses more specific subnet I would pick them. But anyway there is something strange going on, outside reach of Check Point. Check Point uses 3d party info to fill the tables. And if both tables claim the ip is for them what can you do 🙂

Here you can find that Github uses 52.113.83.0/24

https://api.github.com/meta

[JaAnd]

Hi,

from my experience in the case of MS products AppCtr definitions seems to be more accurate than UO. 

Microsoft has lots of those networks to use:

https://search.arin.net/rdap/?query=52.113.83.0

[the_rock]

Can you run command -> dynamic_objects -uo "whatever name of github updatable object"

Andy

[Thomas_Eichelbu]

Hello, 

well yes:
the thing is ... both Updateable Objects contain both subnets ... based on my policy it sometimes matches the subnet on "Microsoft Teams Worldwide" then on "GitHub Services"


[Expert@XXXXXXXXXXXX:0:ACTIVE]# dynamic_objects -uo "GitHub Services" | grep 52.113
range 1037 : 52.113.9.0 52.113.9.255
range 1038 : 52.113.12.0 52.113.12.255
range 1039 : 52.113.16.0 52.113.31.255
range 1040 : 52.113.37.0 52.113.63.255
range 1041 : 52.113.69.0 52.113.69.255
range 1042 : 52.113.83.0 52.113.83.255
range 1043 : 52.113.85.0 52.113.86.255
range 1044 : 52.113.112.0 52.113.127.255
range 1045 : 52.113.129.0 52.113.130.255
range 1046 : 52.113.135.0 52.113.151.255
range 1047 : 52.113.160.0 52.113.191.255
range 1048 : 52.113.198.0 52.113.199.255
range 1049 : 52.113.205.0 52.113.206.255
range 1050 : 52.113.208.0 52.113.223.255

[Expert@XXXXXXXXXXXX:0:ACTIVE]# dynamic_objects -uo "Microsoft Teams Worldwide" | grep 52.1
range 0 : 52.112.0.0 52.115.255.255
range 1 : 52.122.0.0 52.123.255.255

when it matches on Github it results in a drop ... because the existing Github Rule does not contain the services used for MS Teams and the packet matches again on the CleanUP rule ... sure i could move around some rules ... but i consider this as a flaw .. 

[the_rock]

I totally agree, it is flaw in my view as well. Did you contact TAC about it?

Andy

[the_rock]

I also tried grepping for teams with that command, but nothing came up, but those IPs definitely match.

[Thomas_Eichelbu]

Well yes, i bet its time to contact TAC.
i will keep you informed...

[the_rock]

Thanks so much Thomas, Im also super curious about this.

Andy

[PhoneBoy]

We use the information provided by the relevant vendor for our Updatable Objects.
If there are errors in that data...

[the_rock]

@PhoneBoy I suppose no way around it other than modifying the rules?

Andy