I'm planning to make the Tomcat (8.5) Manager accessible through a subdomain like this: https://tomcat.mydomain.com.
As you can see the connection is over HTTPS, but still, does this pose a security risk and is considered as 'bad practice'?
One think I did notice is that, by looking at the certificate for mydomain.com, you can see that https://tomcat.mydomain.com does exists. Which means there is not much security by obscurity.
Of course, it's important to have the tomcat accounts setup right and protected by a password, which I have.
Having the endpoint publicly accessible is not, in itself, a security risk. There are other considerations, though, that you might want to take into account when deciding whether or not to expose an administrative interface publicly:
How many people have credentials for the service?
Can all those people be trusted to have good passwords?
Can all those people be trusted not to re-use passwords across multiple sites?
Do you have lock-outs enabled (on by default if using Tomcat's authentication with the Manager app)?
Can the lock-outs be overwhelmed? (consider the lock-out implementation)
Do admins actually need public access to the Manager?
Are there additional layers of security you could add between the public and the management interface?
In general, I usually choose not to expose administrative interfaces to the public. I almost always require an administrative user to go through some other gate such as an ssh tunnel (with public-key-only access) before they can access any management interface, and then they most also authenticate a second time through that interface (i.e. you aren't automatically trusted just because you have the tunnel established).
If I were going to expose an administrative interface to the public, I think I would want something in addition to password-based authentication in the mix. Some other factor should be involved, whether that is something like a common 2FA solution like TOTP or similar, or TLS client certificates ("mutual authentication").
There is a presentation on the Tomcat web site about upgrading your credential security. There is sample code and configuration in there for how to set up TOTP within Tomcat's existing authentication system. You might want to read that presentation and consider whether you want to add protection like that to your administrative interfaces.
Related
I built out a few applications - published intranet environment - and all of them are prompting for a username and password in order to access the application (connection to this site is not private).
I am not sure if this is an IIS Setting that needs to be adjusted, I have tried adding everything on my end with the web config settings. Even explicitly turning authentication off and allowing anonymous users, does not do anything.
So my main question is could this security prompt feature be turned off through IIS since the application web.config is yielding no results?
I have the default settings that visual studio generates along with my database connection string.
There's two different things here. First, the prompt is because Anonymous Authentication is not enabled. If you don't want any sort of authentication or authorization, you can simply enable that. However, more likely, since this is an intranet, you do actually want people to be authenticated; you just don't want them to have to "login". For that, you should enable Windows Authentication.
The second piece, "Your connection to this site is not private", is either because you're running on HTTP, rather than HTTPS, or you are using HTTPS, but don't have a valid SSL cert. The latter is a very common issue in intranet scenarios, since there's usually not a public domain you can bind a cert to. In that scenario, you need to generate a self-signed cert and install it on all machines that need to access the site. Alternatively, you can set up your own internal CA, such that you can issue and validate your own internal certificates.
In either case, the message is there to let the user know that communication with this site will not be encrypted, so sensitive things, like say a username and password, will be transmitted in plain-text and can therefore be intercepted by monitoring the network traffic. That may or may not be a concern for your intranet environment, but the message is not internet/intranet-specific.
I've got server with w2k8 and IIS7 in one domain and keytab from some other foreign domain (no trusts). Is it possible to enable Windows Authentification (SPNEGO/Kerberos) to auth users in Web Application from the those foreign domain?
It's theoretically possible, but the logistics of making it work are next to impossible to implement.
I've no idea if IIS supports this or not, but it is possible in the kerberos API to say
"try to decrypt this response using every key in the keytab". In theory, this can be used
with keys from remote realms, although I've never seen code attempt it.
However, the problem is the client needs to decide the realm and principal to use to make
the request based on information outside the protocol. Thus you'd need to somehow tell all the
web clients from the remote domain to use the remote domain when contacting the webserver
in the w2k8 domain. You can do this with krb5.conf on unix machines, but it would require a
custom krb5.conf on every client using identities from the remote realm.
In general, kerberos will only work across multiple realms if there is some kind of cross realm
trust enabled.
As part of strengthening session authentication security for a site that I am building, I am trying to compile a list of the best ways to register a user's computer as a second tier of validation - that is in addition to the standard username/password login, of course. Typical ways of registering a user's computer are by setting a cookie and or IP address validation. As prevalent as mobile computing is, IP mapping is less and less a reliable identifier. Security settings and internet security & system optimization software can make it difficult to keep a cookie in place for very long.
Are there any other methods that can be used for establishing a more reliable computer registration that doesn't require the user to add exceptions to the various cookie deleting software?
If you're looking to do device authentication, you may want to consider mutually authenticated SSL. Here, you'd deploy a client identity certificate to each endpoint you'd want to authenticate. Then, you set the server up to require client authentication, so that a client would need to present a valid identity certificate in order to form the SSL tunnel.
This, of course, is not a perfect solution. In reality, this presents much of the same weaknesses as other solutions (to various degrees) Once your client identity certificates go to your clients, they are out of your control; should a client give their certificate to anyone else, you lost the device authentication that you have based on it. SSL identity certificates are generally stored in a keystore on the client which is encrypted with a password or other credential needed to unlock them. While a client certificate could still be compromised, it's somewhat stronger that just a cookie or something like that (assuming you don't have a client that is trying to give away its credential). In addition, you'd want to come up with some validation routine that a client would need to go though in order to get a credential in the first place (how do I know that this is a client device that I want to remember/register?).
Remember, these types of approaches only do device authentication, not users. There are more in-depth schemes already developed for device authentication than what I've mentioned; for example, 802.1x is a network protocol where an endpoint needs to present a client-side certificate to the network switch to get on a LAN. This is out-of-scope for a web application scenario, like what you've described, but the idea is the same (put a cryptographic credential on the client and validate it to establish the connection).
This, like all other security matters really, is a risk decision. What are you trying to accomplish with such a countermeasure? What are the threats you're trying to prevent and what are the consequences if someone does log in on an unregistered device? Only your situation can answer those questions and let you see the real risk, if you need/should mitigate it, and, if so, how strong of a solution do you need to get the risk level down to an acceptable level?
the best ways to register a user's computer as a second tier of
validation
From my point of view this approach does not offer much in the aspect of authentication.
You are not authenticating a user and have no idea who is using the PC that you would accept as being registered.
The way you describe it, this step should be a configuration rule in the firewall to accept connections from specific IPs only.
IMO the filtering of the PCs is the responsibility of a firewall and it would be much better handled by the firewall than any application level filtering.
Just think that you would have the overhead in your application to examine each request and decide whether to accept it or not.
Better leave this preprocessing overhead to the firewall. That's why it is there.
We are developing a couple of web applications and web services for our intranet. To access resources like databases or other data sources we use technical domain users and store their credentials in the config file of the web apps. Passwords must be encrypted before written to the file. (The application then have to decrypts it to access the resources.)
We do this for quite a while but now a discussion came up. Our server operations team suddenly considers it unsecure to store the passwords in config files because an attacker might successfully decrypt it, maybe by analyzing the little tool used for encryption. (It's written in .Net so indeed it's not really hard to analyse the used algorithm by using Reflector & Co.)
As an alternative they proposed to use the technical user account as app pool security context. But I'm not sure if this doesn't mean to replace one possible security hole by an actual one: If the app pool runs under the context of the domain user, the attacker dont't have to know the password anymore. He simply can use security holes in the application or try to run his own code under this app pool somehow.
What do you mean? Is there a best practice to deal with passwords in web applications?
Thanks,
Rocko
Its a very common practice for a domain user to run the app. Just ensure that account has a really small footprint - only what is needed.
I've developed a CodeIgniter project tracking app for a client which lives at a public URL but is used privately. It includes a simple REST API, used exclusively for a Dashboard widget and Cocoa menu bar app though it will grow later.
Originally designed for a small team, the app is going to be used more broadly within the (large) company. My plan to grow and secure it...
Evaluate traffic needs, project resource usage, and scale hosting accordingly.
Rely exclusively on HTTPS and purchase a decent SSL certificate.
Require authentication for the REST API.
Actively monitor for abuse and have a blacklist (or several) in place.
Are there any obvious issues that need to be addressed or best practices to follow for a private/public app such as this?
It's a rather broad question. There are several complicated facets.
SSL is good; think about enabling CI's CSFR protection
Lock down your server. Close ports like email and ftp if you don't need them. Google for tutorials or ask specific questions based on your OS.
A great guide of form-based auth stuff: The definitive guide to form-based website authentication
Make sure your permissions are how you want them. e.g. keep private things private. Design a policy for granting and revoking access.