tickets #113327
closedShould we allow mirrors on dynamic IPs?
Added by emendonca almost 2 years ago. Updated almost 2 years ago.
100%
Description
I maintain a RMT server for a (rather large) SUSE corporate customer in Brazil, and yesterday I got a call from their network security team regarding some suspect activity while downloading packages from download.opensuse.org.
The case is, while downloading the SLE-15-SP4-Updates (5591) repository provided by SCC, it hit a mirror that is running on a high port (18555) and on a dynamic IP DNS hostname (mrfeps.myftp.org). This triggered a lot of alarms and concerns on whether this is a reputable source. They are very strict about network access and supply-chain security, being a financial institution, so this puts us in a very tight spot.
Please consider NOT allowing dynamic IPs for mirrors.
Updated by pjessen almost 2 years ago
- Priority changed from High to Normal
- Private changed from Yes to No
a) I don't see how we can prevent it, the mirror operator's setup is simply not under our control.
b) I may not have thought enough about it, but I don't see any real issue ?
Updated by avicenzi almost 2 years ago
pjessen wrote:
a) I don't see how we can prevent it, the mirror operator's setup is simply not under our control.
b) I may not have thought enough about it, but I don't see any real issue ?
a) To access stage.o.o the IP address must match the domain name reverse lookup, this is a simple control that would rule out mirrors that do not have a valid domain and fixed IP.
b) How reliable is this type of mirror? If a mirror has no fixed IP, it means it's not using an "enterprise-grade" internet provider, and following that logic, might as well not have a reliable power supply, and other things. In such a case, the mirror can be unstable, and unreliable, and zypper can timeout frequently.
We already have enough complaints about the mirror quality in Brazil, allowing anyone to host a mirror is great, but there should be at least a minimum requirement so we don't make things worse.
I've been working with hosting providers and universities in Brazil (and South America) to increase the number and quality of mirrors in SA in general, I know that these, at least meet the minimum requirements for reliability.
Updated by pjessen almost 2 years ago
avicenzi wrote:
pjessen wrote:
a) I don't see how we can prevent it, the mirror operator's setup is simply not under our control.
b) I may not have thought enough about it, but I don't see any real issue ?a) To access stage.o.o the IP address must match the domain name reverse lookup, this is a simple control that would rule out mirrors that do not have a valid domain and fixed IP.
Sure, but last time I looked at download.o.o, that was already in place :-) Judging by the logs, mrfeps.myftp.org is not using stage.o.o nor rsync.o.o.
b) How reliable is this type of mirror? If a mirror has no fixed IP, it means it's not using an "enterprise-grade" internet provider,
and following that logic, might as well not have a reliable power supply, and other things. In such a case, the mirror can be unstable, and
unreliable, and zypper can timeout frequently.
I think you are extrapolating based on a minimum of data. Most providers will allocate a fixed IP-range for a price, we already have a number of smaller mirrors on 1Gbit/s consumer networks with a /29 range. With a perfectly good mains supply :-)
Updated by emendonca almost 2 years ago
The thing is, it affects our enterprise customers directly.
SLE updates usually come from updates.suse.com. However, after 15.3, SLE shares some repositories with download.opensuse.org, namely, SLE-15-SP3-Updates and SLE15-SP4-Updates
(repositories 5077 and 5591 on RMT, respectively). Plus, Leap is offered as a "product" as well, including the Backports repositories.
It's hard to justify to the customer that he needs to trust opening his firewall/proxies to updates coming from a dynamic DNS host on a non-standard TCP port, hosted who knows where.
Updated by pjessen almost 2 years ago
- Status changed from New to Feedback
emendonca wrote:
The thing is, it affects our enterprise customers directly.
SLE updates usually come from updates.suse.com. However, after 15.3, SLE shares some repositories with download.opensuse.org, namely, SLE-15-SP3-Updates and SLE15-SP4-Updates (repositories 5077 and 5591 on RMT, respectively). Plus, Leap is offered as a "product" as well, including the Backports repositories.
It's hard to justify to the customer that he needs to trust opening his firewall/proxies to updates coming from a dynamic DNS host on a non-standard TCP port, hosted who knows where.
"hosted who knows where" goes for all of our mirrors, but I do accept your point.
However, I really think you ought to address such enterprise concerns to SUSE, not to openSUSE. Your customer is apparently quite happy to trust our infrastructure which is being run by a small bunch of unpaid volunteers from who knows where :-) - with no obligation other than their own commitment.
For this specific case, why not just continue to block that non-standard port, i.e. ignore that specific mirror? I expect it will have been created with a lower priority anyway, so preference should be given to "better" mirrors.
Updated by emendonca almost 2 years ago
pjessen wrote:
"hosted who knows where" goes for all of our mirrors, but I do accept your point.
However, I really think you ought to address such enterprise concerns to SUSE, not to openSUSE. Your customer is apparently quite happy to trust our infrastructure which is being run by a small bunch of unpaid volunteers from who knows where :-) - with no obligation other than their own commitment.
I will (SUSE employee here).
For this specific case, why not just continue to block that non-standard port, i.e. ignore that specific mirror? I expect it will have been created with a lower priority anyway, so preference should be given to "better" mirrors.
I hope so. Just brought that up because it has generated questions from the customer side, and apparently, people at SUSE are unaware this happens at least since 15.3.
Updated by pjessen almost 2 years ago
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
emendonca wrote:
pjessen wrote:
"hosted who knows where" goes for all of our mirrors, but I do accept your point.
However, I really think you ought to address such enterprise concerns to SUSE, not to openSUSE. Your customer is apparently quite happy to trust our infrastructure which is being run by a small bunch of unpaid volunteers from who knows where :-) - with no obligation other than their own commitment.I will (SUSE employee here).
Okay, that's great. Thanks.
For this specific case, why not just continue to block that non-standard port, i.e. ignore that specific mirror? I expect it will have been created with a lower priority anyway, so preference should be given to "better" mirrors.
I hope so. Just brought that up because it has generated questions from the customer side, and apparently, people at SUSE are unaware this happens at least since 15.3.
It sounds like an oversight by someone.
I am closing this as resolved. I really do not see any problem with one of our mirrors being run on a dynamic IP. It supports our entire user base, and someone is still volunteering time and resources to do that.