Synametrics Technologies

Hi. Putting these 3 things in 1 post since they're related security questions I was not able to find in docs/KB/forum/google:

1. Is it possible to disable the web interface of Syncrify? It appears the client uses HTTP protocol for backups on the same port that the web interface runs on so maybe they're too tightly integrated but would prefer for there to be no access to the web interface. For example if clients could backup to 1 port while the web interface was on another port then it could be easily done in the router. I see in server config you can define 3 ports, 2 HTTP & 1 HTTPS, but no "backup client only" or "disable web" options.

Assuming it's not possible in Syncrify itself, which options would work without causing problems?
* setup .htaccess/.htpassword files?
* rename/delete all the web files except what's needed for a client to backup?
* filter by URL in http proxy like squid?
* use SSL authentication where client side can only connect with cert?
* filter in firewall like iptables?
* other?

2. There is "Restrict admin to localhost" option to enable admin for localhost only but on headless server that's not exactly ideal. Is there option for local LAN only?  Or is there a config setting that can be adjusted manually to LAN subnet range instead of localhost? (Was going to enable & look at config file but I'd lock myself out without a console screen or way to remote in to run web browser on server itself)

3. Does syncrify limit failed login attempts for web interface and/or backup clients? Assuming failed logins are logged I can use FAIL2BAN but wanted to check if built in first. (I recall seeing a session history file but didn't look close enough to see if useful for FAIL2BAN)

Thx
Bill

Answered/Solved #3 already but #1 & #2 remain open at this point. YES Syncrify has built in banning. Email gets sent to admin & It gets logged in logs/Alerts.log:

2016-10-10 13:41:54,912 -  [IP_BLOCK       ] IP Address x.x.x.x has been blocked from logging in for the next ten minutes. More than 5 incorrect login attempts were made from this IP address.

So all logins from that IP are rejected for 10 minutes. The catch is login ATTEMPTS are still allowed. In other words they are faked like it's wrong password vs preventing connections from that IP address. I didn't see anywhere to specify the attempt window, # of attempts or block length.

Have Syncrify server on Centos so ended up setting up fail2ban to suppliment & have more control:

File: /etc/fail2ban/jail.local

[syncrify-iptables]
enabled = true
filter = syncrify
backend = polling
# Example if only running on single port
#action = iptables[name=syncrify, port=5800, protocol=tcp]
#multiport allows you to specify all 3 Syncrify ports if needed so using that instead
action = iptables-multiport[name=syncrify, port="5800,5801", protocol=tcp]
logpath = /Syncrify/logs/AuditTrail.log
bantime = 30
maxretry = 3
findtime = 60

File: /etc/fail2ban/filter.d/syncrify2.conf

[Definition]
failregex = ^\s-\s<HOST>\s.+?\s-\sLOGIN\s+.+?\s-\sFailed to log in
# Thanks to JDR for Fail2ban assitance!

# Example:
# 2016-10-10 11:13:24,153 - x.x.x.x 6**2 - LOGIN ***@***.com - Failed to log in using SyncrifyClient
# 2016-10-10 11:14:20,692 - x.x.x.x C***4 - LOGIN zz - Failed to log in using browser

(NOTE: Make sure selinux is configured properly or disabled or fail2ban gives permission denied error trying to access the log file)

You can test with:
fail2ban-regex /Syncrify/logs/AuditTrail.log /etc/fail2ban/filter.d/syncrify.conf

Once setup the above will detect 3 tries within 60 seconds then ban via IPTABLES for 30 seconds. Obviously that's not too useful for real world but it's good start for TESTING then adjust to more reasonable values that suit your needs.

You can manually remove a fail2banned IP with:
fail2ban-client set syncrify-iptables unbanip x.x.x.x

One thing to note is that Syncrify does not log failed attempts once a client IP is blocked. So if the built-in Syncrify block kicks in before fail2ban the above won't work. Normally that won't happen with the right fail2ban settings but really Syncrify/logs/Alerts.log should also be monitored by fail2ban for:

2016-10-10 13:41:54,912 - [IP_BLOCK ] IP Address x.x.x.x has been blocked from logging in for the next ten minutes. More than 5 incorrect login attempts were made from this IP address.

Unfortunately that is only logged ONCE per event so not really ideal for fail2ban monitoring. (It'd be nice if Syncrify logged further attempts but maybe it was meant to prevent flooding logs)

Something else to note is I never found where the built-in Syncrify blocked IP or expiry was stored on the file system so thinking it's stored in memory. A restart seemed to confirm that but further testing or dev confirmation would be needed. This also seems to imply there is no way to remove Syncrify IP blocks without a restart or waiting the 10 minutes out.

OK solved #2 (sorta):

The admin GUI only gives a toggle between "Restrict admin to localhost" being enabled or not but the actual code allows for more. Not sure why it was decided to restrict it on the admin itself except maybe to simplify.  

So far this works in testing:

Edit /Syncrify/config/umap.dat & look for allowedIP="". It'll either be "" if the "Restrict admin to localhost" box is unchecked or it'll be "localhost" if that box is checked. If you accidentally check that & hit save you'll be locked out from anywhere except the server itself using localhost which is very bad if you're running a headless GUI-less server.  So if you just want to reset it to get back it, change "localhost" back to "" & restart. Voila you can log in again from any IP.  So that solves the "locked out" issue.

As far as LAN only we got great news!  There is a special option: "intranet"  changing allowedIP to "intranet" seems to do just that & allow ONLY the loan LAN IP's. At least in my testing it appears to work.  Again remember you need to restart so that Syncrify knows you changed it.

Another option I found is comma separated list of IP's which could be used not only for local LAN instead of intranet option but also to allow specific trusted public IP's.  So just edit allowedIP to something like "192.168.1.15,192.168.1.33,10.2.2.55" or such. Same deal, seems Syncrify requires a restart unless there is a way to trigger config reload somehow.

So there you have it! You can fix it if you lock yourself out, you can limit to LAN aka intranet or you can limit by IP if so desired but those last 2 come with a catch:
NOTE: If you use anything except "" or "localhost" it will be lost if you go into Configuration->Security & hit Save.  The reason should be obvious: Syncrify web admin doesn't know about those other settings since it's just a check box toggle. (Obviously they could have done a drop down selection box and/or text field but seems they wanted to keep it simple. Might need to do a feature request..)

So we have a "sorta" fix in that it will work, it's just not supported by the web admin & there's a chance it could get over-written at some point. (Who knows perhaps even during a future upgrade) But worst case just edit the file again.

Now there's just #1 left. I have a clunky solution working using iptables in that I can just enabled Syncrify's port for know/trusted IPs/ranges but that's not really ideal for say laptops that move between locations, IP's that change etc.  Plus while it does prevent access from untrusted IP's it still allows access to the web admin by people on those trusted IP's so it only partially solves the original task.

So got a working hack for #1.  Kinda trivial actually but it seems to work to stop loading of the web admin without stopping backups.  I'll do more testing to confirm.  I also want to see which files don't include the Header file as those wouldn't get blocked but I'd imgaine any admin page SHOULD include the header & why this trick works.

edit Syncrify/htdocs/webapps/ROOT/Header.jsp

add to the beginning before everything else:

<%
if (!request.getRemoteAddr().equals("192.168.2.15")){
response.sendRedirect("http://www.google.com");
return;
}
%>

Change the IP to ONE trusted IP address that you want to be able to access the web admin with a browser. (To do more than one would require it to be more complicated. I only care for 1 so it suits my needs). You can also change the web address to anything you want. Save it & test. VOILA!

Couple things to note. This will only work if the remote IP is known/exposed. If they're connecting thru a proxy etc then it may not be possible with this trick. For my purposes it'll be LAN IP so it works. Also, the return line isn't really needed it's just a safe guard in case the client shomehow gets past the redirect.  Actually you could remove or comment out the redirect line with // leaving just the return line & the user will just get a blank page. (View source of the page to see it's nothing)

So there you have it. Perhaps there are better ways to go about it but as I said it suits my needs so will do for now.  Hopefully these 3 tricks prove useful to someone.
Bill

Update on previous findings for question #1 above. Since Syncrify has mobile theme as well need to also edit:
Syncrify/htdocs/webapps/ROOT/MDHeaderCommon.jsp
Add the same lines as above making the same changes with same caveats:
<%
if (!request.getRemoteAddr().equals("192.168.2.15")){
response.sendRedirect("http://www.google.com");
return;
}
%>

Wanted to bump this one too mostly because it's security related. Yes my hackish workarounds accomplished much of it but with the Syncrify updates being released the patches need to be applied again & ideally they'd be integrated into future Syncrify release.
Thx
Bill

Bill,

This feature's been added in build 943. Check http://web.synametrics.com/syncrify-restricting-browsers.htm for details.