Combining port forwarding and host access control

[joris luijsterburg]

Hey all,

I was testing having a separate DNS for irods in combination with using the host access control list and found something interesting. It means that I can make it work the way it is, but I am wondering if this is correct or not.

Situation:
I have irodsserver zoneA, running on hostname.localdns.com, ip 10.0.0.1, irods 4.3.1
I have a second server running on 10.0.0.2
I made a separate DNS entry, for hostname.publicdns.com that will point to hostname.localdns.com. This loadbalancer does not give the original ip to irods.
In zoneA I have a user Alice.

In the server_config.json I added the following:

   "host_access_control": {
        "access_entries": [
{               "user": "irods",               "group": "irods",               "address": "0.0.0.0",               "mask": "255.255.255.255"    },
{               "user": "Alice",               "group": "none",               "address": "10.0.0.2",               "mask": "0.0.0.0"           }
        ]
    },

    "host_resolution": {
        "host_entries": [
            {
                "address_type": "local",
                "addresses": [
                    "hostname.publicdns.com",
                    "hostname.localdns.com",
                    "hostname"
                ]
            }
        ]
             
 
While on server 10.0.0.2 I put in my irods_environment.json:
    "irods_host": "hostname.publicdns.com",

I do an iinit, and the connection fails. This is expected, because the route goes via the loadbalancer, irods will see the ip of the loadbalancer instead of 10.0.0.2, so the host access control will prevent Alice from connecting.

I now change my irods_environment.json to:
"irods_host": "hostname.localdns.com",

I again do an iinit, which succeeds, which is also expected, since I allowed Alice to logon from this specific IP.
I follow up with an iput of a small file, which succeeds, and an iput of a large file which succeeds. But, the little detail is in the last action. It looks like the host access control runs on the initial connection, and not on the transfer connection itself, sine this is the result of my iput:

Al...@10.0.0.2:~$ iput -fKPV file50M.txt
0/1 -  0.00% of files done   0.000/50.000 MB -  0.00% of file sizes done
Processing file50M.txt - 50.000 MB   2024-06-27.14:58:36
From server: NumThreads=4, addr:hostname.publicdns.com, port:20127, cookie=1889497040
file50M.txt - 37.500/50.000 MB - 75.00% done   2024-06-27.14:58:37
file50M.txt - 50.000/50.000 MB - 100.00% done   2024-06-27.14:58:37
   file50M.txt                    50.000 MB | 0.737 sec | 4 thr | 67.836 MB/s


As you can see the filetransfer itself actually goes over hostname.publicdns.com, which would not be allowed by the host access control. I can see the logic, the host access control probably kicks in in the initial stage, when still connected to hostname.localdns.com, and does not do the check when the filetransfer itself actually starts.
For me this actually means there is no problem where I expected one, because it means I can still use the host access control in combination with the loadbalancer, and the loadbalancer handing out a different ip to irods poses no issues.

However, if I implement it like this in production, will that be future proof, or do I need to set things up differently? For further clarification of the usecase, I plan to make admin users logon only from within our VPN, while all other users can logon from any place they would like.


regards,
Joris

[Alan King]

Hi Joris,

If I'm understanding your scenario correctly, then this shouldn't be a problem in the future. The situation indicates to me that the host_access_control configuration is not being applied for legacy parallel transfers as it does for other connections. We will be moving away from legacy parallel transfer in the future in favor of something similar to the multi-1247 parallel transfer implemented in the python-irodsclient.

I agree with your assessment that this is a bug, however. The host_access_control configuration should apply to any connection with the server. If you're up for it, please file an issue on GitHub for this situation so we can track it. Or let me know and we (the Consortium... or maybe just me :p) will file one.

Or, if I misunderstood the problem, please let us know about that as well.

Thanks,

Alan

--
--
The Integrated Rule-Oriented Data System (iRODS) - https://irods.org
 
iROD-Chat: http://groups.google.com/group/iROD-Chat
---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/irod-chat/95269917-8431-4111-ad38-da90a52bcc52n%40googlegroups.com.

--

Alan King

Senior Software Developer | iRODS Consortium

[joris luijsterburg]

Hey Alan,

There might be two bugs, where one bug is for me actually a feature that solves the other one, so maybe we can get it a bit more clear before filing. Or, I might be misunderstanding usage of host_resolution.

The issue for me might be more in the host_resolution. The problem that I had is the following:

Alice connects from machine  10.0.0.2 to hostname.localdns.com in her irods_environment.json,

But when she transfers a large file, irods will tell her to connect to hostname.publicdns.com(lets say ip is  10.0.0.3) to do the actual transfer.

What happens now because of the loadbalancer in front of the irods server, is that irods no longer sees 10.0.0.2 as the ip adress of Alice, but 10.0.0.3!

Alice is allowed to connect from 10.0.0.2 to irods, but not from 10.0.0.3. It seems like irods will not give Alice the option to choose between

"hostname.publicdns.com"(blocked for Alice by  host_access_control )

"hostname.localdns.com"(not blocked for Alice) 

or "hostname"(not blocked for Alice), 

but it always gives hostname.publicdns.com. If then the host_access_control would be implemented on all levels, I would have an issue with making sure Alice can only login from  within a 'safe' network.

The same might also be in play when having to be redirected to a resource server, if the only option given by irods to the client is to connect to the publicdns, but I didn't test this because we don't have a resource server currently.

So while there might be a bug in the host_access_control checking, that bug being there might solve an issue that I would otherwise have with a potential bug with the host_resolution.

Regards,

Joris