mirror of
https://github.com/amidaware/tacticalrmm.git
synced 2026-04-26 23:15:57 +03:00
[GH-ISSUE #917] IP and FQDN Whitelisting #2510
Labels
No labels
In Process
bug
bug
dev-triage
documentation
duplicate
enhancement
fixed
good first issue
help wanted
integration
invalid
pull-request
question
requires agent update
security
ui tweak
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tacticalrmm#2510
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @asasin114 on GitHub (Jan 4, 2022).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/917
It would be super handy to have a whitelist with the ability to add IP addresses and FQDN's that allow agent communication and interface access for an additional layer of security. I'm super impressed with the security that has already been used out of the box and I think this would be a fantastic addition to that stack. Obviously I can do this with firewall rules on a gateway placed in front of the TacticalRMM installation and I do use that functionality but having it baked into the suite itself would take things to another level.
@dinger1986 commented on GitHub (Jan 4, 2022):
currently you can do it with ufw as well, but shall leave it open incase the devs want to control this from the ui
@bc24fl commented on GitHub (Jan 5, 2022):
If this was "baked" into the suite, how would you handle those agents on a DHCP static address that have not already been whitelisted?
@asasin114 commented on GitHub (Jan 5, 2022):
That's where the FQDN comes in. If you have a dynamic DNS setup with a DHCP address then whitelisting the FQDN will ensure the DHCP address is covered in most situations.
Taylor Bornyk
CTO - Insight Hosting
Direct: 306-500-9150 Office: 306-500-0234
From: bc24fl @.>
Sent: Tuesday, January 4, 2022 8:08:43 PM
To: wh1te909/tacticalrmm @.>
Cc: Taylor Bornyk @.>; Author @.>
Subject: Re: [wh1te909/tacticalrmm] IP and FQDN Whitelisting (Issue #917)
If this was "baked" into the suite how would you handle those agents on a DHCP static address?
—
Reply to this email directly, view it on GitHubhttps://github.com/wh1te909/tacticalrmm/issues/917#issuecomment-1005320365, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AADFZ3WS6NQUMW7V6J5Q4DLUUOR2XANCNFSM5LHV4XHQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
@bc24fl commented on GitHub (Jan 5, 2022):
What are your thoughts on addressing remote users with laptops?
@asasin114 commented on GitHub (Jan 5, 2022):
Those users will be using a VPN to direct their traffic through the office when on the road so they will communicate back to Tactical through that.
Taylor Bornyk
CTO - Insight Hosting
Direct: 306-500-9150 Office: 306-500-0234
From: bc24fl @.>
Sent: Tuesday, January 4, 2022 9:26:57 PM
To: wh1te909/tacticalrmm @.>
Cc: Taylor Bornyk @.>; Author @.>
Subject: Re: [wh1te909/tacticalrmm] IP and FQDN Whitelisting (Issue #917)
What are your thoughts on addressing remote users with laptops?
—
Reply to this email directly, view it on GitHubhttps://github.com/wh1te909/tacticalrmm/issues/917#issuecomment-1005352045, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AADFZ3R2QP2KOCJWZ3E4YB3UUO3ADANCNFSM5LHV4XHQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
@bc24fl commented on GitHub (Jan 5, 2022):
And if they can't get on VPN or their VPN isn't configured to route all their traffic as common across many organizations, or you just need unattended access? I'm asking these questions because I'm also looking for a solution to that problem but I don't think Tactical can handle it correctly. This would be a good discussion to have with the Tactical discord community to get more ideas.
@asasin114 commented on GitHub (Jan 5, 2022):
Great questions @bc24fl! We've been talking about some of this internally as well. Seeing as all of our clients are managed and our stack allows us to rapidly deploy road warrior VPN services the way we want them configured we don't see much of an issue in terms of connectivity on that front. The problem does, obviously, arise when a machine is out of accessible service for a period of time. In that scenario we have 2 options:
I haven't been in the Discord much other than to browse around here and there but I'd be more than happy to bring this subject up over there.
@silversword411 commented on GitHub (Jan 5, 2022):
VPN
SDN
DDNS
Port Knock
These are the general techniques I know about, add any others you can think of.
@bc24fl commented on GitHub (Jan 5, 2022):
I’ve contemplated doing the whole private network thing using vpn/sdn but I just don’t feel comfortable having all my managed client computers part of essentially the same network. It’s my understanding from conversations with others however that you can isolate segments (ie: companies) from each other. One such tool that may work is Nebula but I haven’t yet done enough research to know for sure and how secure it really is.
So as a temporary solution I began developing an in house solution that essentially runs an agent on each remote client that authenticates with a light web service which whitelists Ips/Ports on the servers I need open. Then every night it flushes out all the dynamic Ips it added the day prior. Since my servers are generally housed in one of the major cloud providers, I can use their API’s to easily do this on their provided virtual firewalls (In AWS it’s a Security Group). Sounds hackish, maybe, but it’s better than having all my servers exposed to the public.
@NiceGuyIT commented on GitHub (Jan 5, 2022):
First, I do not think TRMM should manage the architecture for your systems. You'll get into the chicken-or-the-egg scenario where TRMM is managing the network to allow clients into the network so they can be managed by TRMM.
There are two parts: on-boarding and maintenance.
The maintenance is relatively simple because you already authenticated the agent. Maintenance involves rotating certificates, rotating credentials, revoking access, etc.
On-boarding is the hard part because any program you run to give access to your system could be run by an unknown party to gain access. Example from the docs. I'm specifically talking about "always on" or automated systems, not systems where the user has to login. What happens if a user can't login to VPN and you need to access their computer to assist? Back to chicken-or-the-egg scenario.
I see two main paths:
I'm working through the details of implementing Nebula (SDN or always-on VPN) as my gatekeeper. Authentication is made via TLS cert. Revoking the cert kicks the computer out of the network. Assets don't talk to each other unless you specifically open the firewall ports in Nebula and the assets have the same CA (technically not true but good enough for this explanation). The ongoing maintenance is simple if you add a long expiration, say 10 years. A shorter lifespan would require some sort of management/automation. On-boarding is the tricky part. Since it's not rolled out yet (Nebula is used only internally), I'm holding off until I can work through path 2: on-boarding to a queue with manual approval.
Initially I thought firewalld-rest would help with the on-boarding, but after looking at the implementation, it won't work without some modification. Another option I've thought about is a TRMM style NATS setup where the client authentication is done with TLS certs and NATS is exposed to the world (or to your part of the world). The required footprint will be smaller and learning NATS will help with TRMM.
@sadnub commented on GitHub (Apr 17, 2022):
IP addresses can be whitelisted in the nginx configuration. This is probably the best option since it whitelists based on the connection ip address.
Address detection back to backend or dashboard apps will be very unreliable and we need to check HTTP headers to try and make the best guess at what the client ip address is.