I'm making
rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
and it return 403, but not always, like 30% of all request passes normally. What's the point of such behaviour?
1 Like
Welcome to our community.
We are currently blocking Russian IPs due to the war, please see Elastic підтримує Україну | Elastic Blog.
Странное решение. На уровне насрать под дверью. Чем поможет блокировка IP из РФ простым людям в Украине? При том, что в релизе разговор только об окончании продаж в РФ.
3 Likes
hello!
how about Italy?
$ curl -qsIv https://artifacts.elastic.co/packages/8.x/yum/8.1.2/kibana-8.1.2-x86_64.rpm
* About to connect() to artifacts.elastic.co port 443 (#0)
* Trying 34.120.127.130...
* Connected to artifacts.elastic.co (34.120.127.130) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=appsearch.elastic.co
* start date: Mar 24 12:59:46 2022 GMT
* expire date: Jun 22 12:59:45 2022 GMT
* common name: appsearch.elastic.co
* issuer: CN=GTS CA 1D4,O=Google Trust Services LLC,C=US
> HEAD /packages/8.x/yum/8.1.2/kibana-8.1.2-x86_64.rpm HTTP/1.1
> User-Agent: curl/7.29.0
> Host: artifacts.elastic.co
> Accept: */*
>
< HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
< Content-Length: 134
Content-Length: 134
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
< Date: Fri, 01 Apr 2022 14:51:20 GMT
Date: Fri, 01 Apr 2022 14:51:20 GMT
< Alt-Svc: clear
Alt-Svc: clear
<
* Connection #0 to host artifacts.elastic.co left intact
$ curl ipinfo.io
{
"ip": "80.211.x.y",
"hostname": "foo.bar.baz",
"city": "Rome",
"region": "Lazio",
"country": "IT",
"loc": "41.8919,12.5113",
"org": "AS31034 Aruba S.p.A.",
"postal": "00118",
"timezone": "Europe/Rome",
"readme": "https://ipinfo.io/missingauth"
}```seem to have same issue here, Slovakia is blcoked. cool
We're happy to dig into issues of IPs outside of Russia being blocked, please provide the IP you are coming from so we can dig into it.
Any non technical posts in this topic will be deleted.
We are facing similar issues. Can you have a look at the range 91.197.40.0/22? It does belong to a Swedish cloud provider and should have very little to do with Russia =)
Yep this looks like it's inadvertently impacted, we're chasing it up for you.
massive 403, pls sort it!
# curl -qs ipinfo.io | jq '.'
{
"ip": "80.211.174.xxx",
"hostname": "x.y.z",
"city": "Rome",
"region": "Lazio",
"country": "IT",
"loc": "41.8919,12.5113",
"org": "AS31034 Aruba S.p.A.",
"postal": "00118",
"timezone": "Europe/Rome",
"readme": "https://ipinfo.io/missingauth"
}
Is this from all IPs in the range @tibyke? If not, please DM me the relevant one.
I only have one address in that range, and it has been blocked for a couple of months now. (obviously I haven't done anything bad at all)
btw it's 971 backwards.
how come you don't know what the rules are? you set them up don't you?
I do not, no.
I'll get it checked.
any update on this one? (still 403)
# curl -qso/dev/null https://artifacts.elastic.co/packages/8.x/yum/8.2.0/kibana-8.2.0-x86_64.rpm -w "%{http_code}\n"
403
# curl -qso/dev/null https://artifacts.elastic.co/packages/8.x/yum/8.2.0/kibana-8.2.0-x86_64.rpm -w "%{http_code}\n"
200
thx!
Hi everyone, we're really sorry you're experiencing these issues. This is a very difficult problem to resolve so I wanted to at least explain why it's happening.
Elastic must comply with US and other applicable laws and rules regulating international trade. As you likely have heard, numerous Russian entities and persons have been sanctioned by the US, EU and many other governments as a result of Russia’s invasion of Ukraine. In addition, extremely strict controls have been imposed on exports of technology, including Elastic products, to Russian users.
These sanctions and controls prohibit conducting any business with sanctioned companies and persons and bar Elastic from exporting its technology to Russia. The standard way to determine network access is with geoip lookups, and we rely on our network providers to do accurate geoip lookups. This service is hosted through GCP. Google is a US-based company, and therefore has to obey those laws. Note that even if Google did not already provide this protection, we're obligated by US law to do it anyway. However, that's not technically what's causing the errors here.
When you encounter an IP that's blocked, I'm afraid all you can do is report it to us and wait while we engage the support team on your behalf. We actually experience this issue inside Elastic with our own cross-provider traffic and must work around it too. Thank for your continued patience.
Finally, please know that while we stand with Ukraine, we at Elastic are heartbroken that the people of Russia are also suffering from the actions of the Russian government. Many of our own employees have been directly affected by this conflict and we join the world in hoping that it will end as soon as possible.
6 Likes
Hello, I have full understanding in that you guys follow the requirement however it would be nice to update your GEOIP database before enforcing this.
We still experience issues with on of our /22 that was moved to Sweden over 2 years ago.
Would it be possible for you guys to "fix/check" our IP range? 91.197.40.0/22
Thanks in advance and just let me know in case of any questions/problems
ubuntu@testvm1:~$ curl -I https://artifacts.elastic.co/packages/7.x/apt/pool/main/e/elasticsearch/elasticsearch-7.16.1-amd64.deb
HTTP/2 403
content-length: 134
content-type: text/html; charset=UTF-8
date: Fri, 10 Jun 2022 12:28:42 GMT
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
Welcome to our community! 
We aren't all guys though.
As Drew mentioned above, we do rely on Google's lookups here. We will raise this range with them and get it corrected.
2 Likes
my 403 is back again! what's going on here guys (and girls) ?
IP is the same as above
I've chased it up.
1 Like
any update?