IP Address Based System Access

ApexityIT

Have you considered directing to specific login page based on visitor IP address? Or even just restricting access to the technical side to specific IPs?

Ex: If it's coming from an IP in our /28, route to admin login. If it's coming from anywhere else, send to the client portal login.

Would eliminate a lot of bot-login attempts on the technician side, and would make it easier for customers to access the client portal by just going to our support URL rather than having to go to the URL then click "looking for the client portal?"

ApexityIT

Additionally, support for a second domain that takes visitors direct to the client login would be great. Ex our subdomain takes us to technician login, domain we publicize for clients takes them to client portal.

wrongecho

ApexityIT I played around with Apache and splitting the internal/client portals into two subdomains seems pretty easy to do.

In the below:

ITFlow is served from /var/www/itflow.example.com
Techs use itflow.example.com if they have an allowed IP
Clients are redirected to use clients.example.com/portal

Apache config: itflow-example.conf

# Internal users

<VirtualHost *:443>
	ServerName itflow.example.com
	DocumentRoot /var/www/itflow.example.com
	SSLCertificateFile [...]

	RewriteEngine On

	# Redirect anyone on /portal/ to the clients vhost
	RewriteRule ^/portal/(.*)$ https://clients.example.com/portal/$1 [R=302,L]

	# Only allow tech access for a specific IP address
	RewriteCond %{REQUEST_URI} !^/guest_.*
	RewriteCond expr "! -R 'your-ip-here/32'"
	RewriteRule ^ https://clients.example.com/portal/ [R=302,L]

</VirtualHost>


# External users
<VirtualHost *:443>
	ServerName clients.example.com
	DocumentRoot /var/www/itflow.example.com
	SSLCertificateFile [...]

	RewriteEngine On

	# Default deny
	<Directory /var/www/itflow.example.com>
			Require all denied
	</Directory>

	# Allow portal
	<Directory /var/www/itflow.example.com/portal>
			Require all granted
	</Directory>

	# Allow logos and avatars
	<Directory ~ "/var/www/itflow.example.com/uploads/settings/*">
			Require all granted
	</Directory>

	<Directory ~ "/var/www/itflow.example.com/uploads/clients/*">
			Require all granted
	</Directory>

	<Directory ~ "/var/www/itflow.example.com/uploads/users/*">
			Require all granted
	</Directory>

	# Allow stylesheets, javascript, json, icons and fonts
	<FilesMatch ".*\.(css|js|json|ico|woff|woff2|ttf)$">
			Require all granted
	</FilesMatch>

	# Allow guest_X.php files
	<FilesMatch "^/guest_.*">
			Require all granted
	</FilesMatch>

</VirtualHost>

Bigbug

By setting a security key in admin security settings you can achieve both of that

I personally have my itflow behind cloudflare proxy and WAF with bot protection on and regional access set to US only. This eliminates bots and reduces your attack vector

I have set rules in Apache to only allow traffic that comes to the cloudflare monitored domain this eliminates direct traffic to the ip

ApexityIT

To be blunt here, I don’t like that. That’s security by obscurity more than anything... And one more thing for us to remember, too 😅

Would love consideration for IP based routing…

We do use cloudflare. I owe the WAF stuff some time, as it certainly helps like you said. I’ve never used those to the full extent of their purpose. I am making a broad assumption that our ITFlow instances get quite a bit of bot traffic, I’ve never looked into the logging.

wrongecho

Have you considered directing to specific login page based on visitor the IP address?

Yes I have mentioned it before but we decided against it. Do this in your firewall, your WAF or in Apache.

If you allow clients to use the client portal you have to allow some extra paths but otherwise just keep the whole thing behind a VPN, or in your case Cloudflare Access?

By setting a security key in admin security settings

-

That’s security by obscurity more than anything

It's not really meant as some amazing security feature but to help ward off bots and the like. Security is all about layers. It also redirects clients nicely to their login page.

https://security.stackexchange.com/questions/44094/isnt-all-security-through-obscurity

We do block IPs after a few failed logins within the app. I haven't looked into pointing Fail2Ban at the Apache logs but it's also probably possible.

wrongecho

I looked into Fail2Ban & it seems possible - https://docs.itflow.org/fail2ban

brandtmoore

We've actually implemented a similar approach with a few of our clients at Network Computer Pros, and it's been a solid addition to their layered security model. Routing traffic based on IP can absolutely reduce bot login attempts, especially when the technician/admin panel is consistently being targeted. For one setup, we limited the admin login interface to a defined internal IP block and redirected all other traffic straight to the client-facing portal. This minimized confusion for users and locked down the backend significantly.

I’d echo the benefits of pairing that setup with a good WAF, especially when using Cloudflare. It’s not a silver bullet, but when used properly blocking bad ASNs, enabling rate limits, and tightening geo-access, you really cut down on noise.

That said, you're right to weigh the trade-offs. IP-based rules can be brittle, especially in dynamic IP environments or with remote staff. In those cases, we’ve recommended implementing VPN access or zero-trust gateways to preserve usability without sacrificing too much security.

Always appreciate these conversations lots of good perspectives here.