What is/are the IPv4 addresses used by archlinux-keyring-wkd-sync? I need to tell iptables
Arch devs, What is/are the IPv4 address(es) used by archlinux-keyring-wkd-sync? I need to tell iptables not to block them so my logs quit filling up with errors. I cloned the source (pyhon...) and looked, but my feeble python skills were unable to find where the addresses or domains were listed (other than the @..... e-mail address domains for verification purposes) They may change? That is one challenge the use of varying cloud or service provider may pose. Failing there being any fixed set, I guess I could tcpdump the traffic, but if there is a list of IPs that the keyring sync uses, that would be the easiest way to go. -- David C. Rankin, J.D.,P.E.
Am 26.02.23 um 04:00 schrieb David C. Rankin:
Arch devs,
What is/are the IPv4 address(es) used by archlinux-keyring-wkd-sync?
I am not sure if I understand your question correctly. But WKD lookup works something like this: Having some kind of e-mail address (from a PGP user-id, for instance), you take the domain part, add the subdomain 'openpgpkey', and try to connect to an HTTP server there. This is in no way static and may change depending on the user-ids in pacman's keyring and TTLs in DNS. BR
On 2023-02-26 10:22:08 (+0100), Markus Schaaf wrote:
Am 26.02.23 um 04:00 schrieb David C. Rankin:
Arch devs,
What is/are the IPv4 address(es) used by archlinux-keyring-wkd-sync?
I am not sure if I understand your question correctly. But WKD lookup works something like this: Having some kind of e-mail address (from a PGP user-id, for instance), you take the domain part, add the subdomain 'openpgpkey', and try to connect to an HTTP server there. This is in no way static and may change depending on the user-ids in pacman's keyring and TTLs in DNS.
It's not as fluent as you might think, since we are only looking up @archlinux.org UIDs via WKD. The Arch Linux WKD is (currently) hosted on gitlab pages, which relates to the host of https://archlinux.page. Whether there are more redirects on the way, you'd have to check for yourself. I can also not guarantee that this host won't ever change (you'd want to ask members of the DevOps team about it). Best, David -- https://sleepmap.de
On 2/26/23 06:32, David Runge wrote:
On 2023-02-26 10:22:08 (+0100), Markus Schaaf wrote:
Am 26.02.23 um 04:00 schrieb David C. Rankin:
Arch devs,
... iptables not to block them so my logs quit filling up with errors.
I may be off base here but I'll ask anyway. Assuming you, as is typical, primarily block SYN packets for inbound traffic, the only way WKD would likely be a problem is if you either (a) blocked outbound to the arch WKD webserver or (b) you block even RELATED,ESTABLISHED coming back. Conceivable, but are you sure that's what your firewall rules do David? Or do you have some other problem that is causing you trouble possibly? Aside: you may want to consider migrating to nftables - it is a very significant improvement over legacy iptables. best, gene
On 2/26/23 14:04, Genes Lists wrote:
On 2/26/23 06:32, David Runge wrote:
On 2023-02-26 10:22:08 (+0100), Markus Schaaf wrote:
Am 26.02.23 um 04:00 schrieb David C. Rankin:
Arch devs,
... iptables not to block them so my logs quit filling up with errors.
I may be off base here but I'll ask anyway.
Assuming you, as is typical, primarily block SYN packets for inbound traffic, the only way WKD would likely be a problem is if you either (a) blocked outbound to the arch WKD webserver or (b) you block even RELATED,ESTABLISHED coming back.
Conceivable, but are you sure that's what your firewall rules do David? Or do you have some other problem that is causing you trouble possibly?
Aside: you may want to consider migrating to nftables - it is a very significant improvement over legacy iptables.
best,
gene
I've think I've found the IP using master-key.archlinux.org, but as you say there may be more redirects on the way. The issue is I block most of RIPE, I don't do business overseas, rarely outside Texas. I keep iptables stats on the number of intrusion attempts from RIPE, APNIC, AFRINIC, etc.. and ban large blocks of each -- which leads to problems such as this when some remote redirect goes through one the blocked ranges. My solution thus far has been to add specific ACCEPT rules for the software that needs updates, certbot, freshclam, etc... Which has worked quite well. However, like with archlinux-keyring-wkd-sync, it may not have a consistent IP or small range where it comes from. I'll try and get a better handle on what IPs are involved here and see if I can come up with one or more ACCEPT rules that will work with my setup. -- David C. Rankin, J.D.,P.E.
On 2/26/23 17:29, David C. Rankin wrote: ...
The issue is I block most of RIPE, I don't do business overseas, rarely outside Texas.
I keep iptables stats on the number of intrusion attempts from RIPE,These intrusion attempts are inbound and it is indeed not uncommon to
'block' ingress SYN (aka new and not related / established) connections from those you don't want accessing your services. But arch relies only on the ability to reach a website to pull the WKD info. Inbound blocks would not prevent this - just like it would not prevent you from visiting any EU website. Are you saying you block not only inbound SYN packets, but also outbound and/or every related, established connection? This would mean you are unable to visit any EU website unless you first add that website's specific IP(s) to your outbound whitelist? That would also include of course the WKD web-server as well. If this is not the case then perhaps something else is going on. As I said, just trying to understand what you're doing that may be causing a problem for you to pull a key from a web-server. best gene
On 2/26/23 16:57, Genes Lists wrote:
Are you saying you block not only inbound SYN packets, but also outbound and/or every related, established connection?
This would mean you are unable to visit any EU website unless you first add that website's specific IP(s) to your outbound whitelist? That would also include of course the WKD web-server as well. If this is not the case then perhaps something else is going on.
As I said, just trying to understand what you're doing that may be causing a problem for you to pull a key from a web-server.
best
gene
Thanks for the reply Genes, I block just inbound connections from the blocked address ranges using the INPUT chain, all outbound addresses are available. (very unsophisticated approach) I'll look at using a finer toothed comb for handling only new and not related / established. That would solve the issue so long as the WKD traffic would be considered related / established. So the problem is the sync can contact wherever it is supposed to validate the keys from, but iptables will not let the machine on the other end talk back due to the DROP rule on the address range from the INPUT chain block. -- David C. Rankin, J.D.,P.E.
On 2/26/23 22:23, David C. Rankin wrote: David - I emailed you an nftables script off-list - if its not in your spam folder, you may find it useful. Happy to share on list of course, but for now thought it better not to. best, gene
participants (4)
-
David C. Rankin
-
David Runge
-
Genes Lists
-
Markus Schaaf