I have to rely on an external hosting provider for my school website. If more than 10 students collectively log in with incorrect login details the hosting provider will launch a denial of service attack from where the incorrect loggings originated. i.e. from within the school. So this means the school will be logged out of its own resource.
Students will get their logging in details incorrect sometimes, and they also need to log in at the same time. So I do not know how to get around this problem.
Does anyone have any ideas, as it appears that I cannot get a hosting account which will avoid this from happening, and we do not have the money for an internal webserver where the settings for security can be controlled. We have been quoted £28K for one of these!
It's not clear here if you have hosted your website under shared hosting and what is (may by anti-DDoS software) causing DDoS trigger. If maximum number of concurrent users is known, you can ask web hosting provider to tweak their DDoS prevention software to allow same number of concurrent failed attempts. As an alternative, you can choose other Web Hosting type such VPS. In VPS, you will have full administrative access. So by default there is no anti DDoS software or firewall that can trigger false DDoS alerts. If you wish you can tweak/disable or enable it.
Related
I need to be able to store a user's Exchange password so I can use it to perform some task later on, using EWS. I know storing passwords in plain text is a horrid crime, so what options do I have?
In my case, my application will have access to an administrative account that will have the ability to use impersonation to work with users' Calendars. I need to store the password of this admin account so I can use it while authenticating with the Exchange server at a later time. I am not planning on using the EWS Managed API.
I have a user that created a calendar app with similar requirements. By default, an account that has these permissions globally is horrible and not recommended. Impersonation roles were granted by department that required access to the app to reduce risk scope. However if you require this globally, here's what I recommended for mitigating the account/password exposure:
Restrict the accounts functionality to Exchange services only. Features like log on locally and other general domain user privileges are not needed for an EWS service account that only needs mailbox access and impersonation roles. In this case, the account cannot log onto a computer nor can it be used for RDP. This limits exposure for malicious use.
The user/pass can be stored in your applications database and the connection string would also be stored outside of your application, there's a lot here: https://security.stackexchange.com/questions/22817/how-to-encrypt-database-connection-credentials-on-a-web-server and encrypting the password within the database; further reading: http://www.darkreading.com/safely-storing-user-passwords-hashing-vs-encrypting/a/d-id/1269374
Restrict DB server and management access. This is a larger issue than it should be if the database server is shared between groups. Audit the database server access, and re-restrict if you have too many cooks in the kitchen. The database server should also not be directly accessed by user networks but that may be a larger issue to tackle.
Restrict access to the application. As in, is it available externally or only available inside your perimeter? Either way, the application should also include authentication just to access, using Kerberos or some other SSL auth, make sure the application cannot be used to DoS the EWS services from over-access.
Create a one-off throttling policy on Exchange for this user and assign accordingly to prevent the application from breaking EWS or limiting regular user functionalities. This is something Blackberry admins learned the hard way if they didn't follow recommendations. When BES server wouldn't properly tear down connections, web services would start dropping valid client requests. As such BES had to instruct users to create a one off throttling policy for various Exchange features. I did the same for the user that created my EWS app. And a few times it saved me.
Really it will boil down to good application design and coordinating requirements with the Exchange team.
Don't's:
Don't store the username/password in Apache/IIS pages or the connection string
Don't grant global permissions for the account if you don't have to
Don't allow unauthenticated access to the application and allow unlimited connection times
Hope this helps.
Is it possible, safe and practical to use Windows Integrated Security on an Extranet?
E.g. there is an IIS website on the intranet that can be used over the LAN with integrated authentication. When the user disconnects from the LAN he wants to be able to use the browser on his domain-joined-notebook to connect to the same website over the internet (no VPN) without having to logon separately.
The question of whether it's "safe" is a question of what additional security threats you're exposing the user to in the Internet scenario, that they weren't exposed to in the Intranet scenario. Additionally, are you exposing the server to additional security threats - and assuming that the question isn't "whether to allow access to the server from the Internet" but rather "which authentication methods should we allow for this server-now-exposed-to-the-Internet", this secondary question boils down to "is it better to use Windows integrated authentication protocols or require the use of Basic, Digest or digital certificates"?
Security threats to user/client: are the user's credentials reasonably protected from attackers who "sniff them from the wire"? Windows-integrated authentication uses either NTLM or Kerberos; in extranet scenarios, the user/client can't generally rely on Kerberos, since that would require transparent access to a KDC (i.e. an Active Directory domain controller) from the Internet as well. While this can be done, it's unusual to see a security-conscious organization allow that. So we're talking about NTLM - which hashes the user's password with a "nonce" (random set of characters) that are sent from the server, so that the user's password doesn't appear in plaintext over the wire. Compare NTLM to Basic and it's a clear win; compare NTLM to Digest authentication, and it's somewhat equivalent; compare NTLM to client certificate authentication, and certs always win for security (but lose on the deployment/bootstrapping challenges). Generally you'll find your security or server admins will want to use an SSL certificate for the IIS listener that's exposed to the Internet, so that user's credentials are even more protected against "sniffers". SSL is hardly perfect and doesn't protect against more sophisticated attackers in the middle (or someone who has a trojan/bot on the client device), but it costs very little for an extra layer of peace of mind. SSL + NTLM is a reasonable choice made by many.
Security threats to server: server is exposed to unauthorized attackers trying to gain access to authenticated resources. If the server allows any AD-authenticated authentication protocols then it's equally susceptible (or not) to attacks that try to brute force a user's password, and some sort of IDS solution that raises alarm bells for repeated bad password attempts is advisable (but quite a challenge to get the signal/noise ratio down to manageable levels). The server is also exposed to the possibility that any exploitable holes (primarily in IIS, or anything else exposed through the firewall) can be used to gain privileged access to the server by an outside attacker. Better be prepared for frequent patching. Other less likely but scary-sounding security threats are possible, but that's the big ones to tackle first.
Yes, it is definitely possible to use integrated security. But, it also depends on the framework you are using for authentication. In ASP.NET you can use built in authentication module. You to set the authentication mode to "Windows" and .Net will manage it for you. You can also have different roles for managing different types of users in your web app. You web app must be available outside your LAN(i.e. your firewall should not block incoming HTTP requests)
Vamyip
As ParanoidMike points out by exposing a webapplication to the internet that uses windows authentication you are creating a brute force attack vector to hackers. To try and mitigate this threat you should consider taking the following actions:
Restrict Access by IP address
Set Accounts to Lock out after n failed login attempts.
Admin accounts cannot be set to lockout so choose obscure usernames for them.
I'm currently investigating if it is possible to exclude admin accounts all together
In the HTTPS security model, the weakest part is the list of trusted CA in the browser. There are many ways that someone could inject addition CA to the list that users will trust the wrong guy.
For example, a public computer, or PC in your company. The administrator could force you to trust a CA issued by himself, it could be very insecure with a HTTPS proxy server with HTTPS relay. As a result, they will able to SPY your message, login, and password even browser tell you that your are on trusted SSL connection.
In this case, what can web application developer could do to protect user and also the system?
As a web application developer there is very little you can do about this.
This issue needs to be dealt with further down the stack.
If someone half way around the world wants to:
a. Put a false root CA on someone's computer
b. Issue a cert for your domain under that CA
c. Impersonate your site
d. Point someone's local DNS entry for your domain to a different ip
In none of the above steps is your application involved or consulted so this is where good network administration and security is important.
Aside from that, maybe there's a legitimate reason for someone to do just this locally on their personal network. Who am I to stop them?
This is essentially what corporate web proxy filters do and they are within their rights to do it.
As far as stopping someone malicious from taking the above steps thats something that needs to be put on the administrators of your customers machines.
Theoretically speaking, if the user's terminal is owned by an adversary, you've already lost and there's nothing you can do about it -- if push comes to shove they can filter out your countermeasures or even scrape and spoof the entire site.
In practice, you can do things to make the adversary's job harder, but it's an arms race. You'll likely have to use all the same sorts of countermeasures that malicious software uses against scanners -- because from the adversary's point of view your site is behaving maliciously by trying to prevent itself from being overridden! -- and know that anything you do can and will be rapidly countered if your adversary cares enough.
You could, for example, open sockets or useXmlHttpRequest from JavaScript or applets, but you can't stop your adversary from updating their filters to strip out anything you add.
You might get more mileage by emitting polymorphic output or using other anti-reverse-engineering techniques, so it appears that no two hits to the site produce similar code/resources sent to the browser. It's an inordinate amount of work but gives your adversary a puzzle to chew on if they want to play man in the middle.
My question is pretty much summed up in the subject.The context is a problem we are facing with the account getting locked our fairly often.
My setup uses this as the service acccount for clearcase application.
There is another account by the same name (but in a different domain - a trusted domain) that runs a monitoring sofftware under this account. For eg., my setup uses the accoundt DOMAINA/clearcase_albd, while this other trusted domain runs a batch file under TRUSTEDDOMAIN/clearcase_albd.
We are suspecting this account to be causing the locking out of our service account (but at this point have not yet figured out why!)
Have pored over event logs endlessly, to no avail and have now decided to start fresh from ground zero.Am following a thread of thought and the first thing I need confirmation on is this:
Should I be seeing DOMAINA/clearcase_albd account when i run clearlicense at all?
If not, then why would another account by SAME name but from a different domain lock out my domain account?
Would greatly appreciate any help in this regard,
Thanks in advance
According to the IBM ClearCase Manual, the Rational® ClearCase® albd_server program runs with the identity of a special user account known as the Rational ClearCase server process user.
This user is a member of the Rational ClearCase administrators group, which grants privileged user status.
That account should not directly uses a license, as it is related to the albd (Atria Location Broker) process which will execute operation on behalf other users.
When a client program needs access to a service (a VOB or view server, for example) on a Rational ClearCase server host, it uses a remote procedure call (RPC) to send a request to the albd_server process on that host.
The albd_server starts the requested service if it is not already started, and provides the service’s port number to the client. Thereafter, the client communicates directly with the service.
IBM does suggest two albd accounts, for central VOB/view servers and end-user workstations. This is primarily done to prevent albd account issues (account lockouts, etc) on the albd account from impacting the VOB servers themselves.
BUT: those accounts should be on the same domain.
Note: by typing
creds clearcase_albd
You will see its SID for the current Windows domain.
You will then be able to check if that SID pops up in the clearlicense command output.
If I uncheck the "Enable anonymous access" checkbox in IIS, so as to password protect a site, i.e. by restricting read access to designated Windows accounts, does the resulting password dialogue which is then presented to all anonymous http requests, represent a security risk in that it (seemingly) offers all and sundry an unlimited number of attempts to guess at any Windows account password?
EDIT:
Okay, not much joy with this so far, so I'm attaching a bounty. Just 50 points sorry, I am a man of modest means. To clarify what I'm after: does disabling anonymous access in IIS offer a password guessing opportunity to the public which did not exist previously, or is it the case that the browser's user credentials dialogue can be simulated by including a username and password in a http request directly, and that the response would indicate whether the combination was correct even though the page was open to anonymous users anyway? Furthermore, are incorrect password attempts submitted via http subject to the same lockout policy enforced for internal logins, and if so does this represent a very easy opportunity to deliberately lock out known usernames, or alternatively, if not, is there anything that can be done to mitigate this unlimited password guessing opportunity?
The short answer to your question is yes. Any time you give any remote access to any resource on your network it presents a security risk. Your best bet would be to follow IIS best practices and then take some precautions of your own. Rename your built in administrator account. Enforce strong password policies. Change the server header. Removing anonymous access, while a password guessing risk, is a very manageable one if used with the proper layered security model.
When you choose an authentication other than Anonymous, you certainly can be subject to password hacking. However, the account that is uses is subject to the standard account lockout policies set in Local Security Policy and your Domain's security policy.
For example, if you have a local account "FRED" and the account lockout policy is set to 5 invalid attempts within 30 minutes, then this effectively prevents account password guessing, at the risk of a denial of service attack. However, setting the reset window to a value (15 minutes?) effectively limits the DOS.
Basic Authentication is not recommeded for a non-SSL connection since the password will travel in plain text.
Digest Authentication requires passwords to be stored on the server using a reversible encryption, so while better than Basic, Digest has its flaws.
Windows Integrated Authentication
includes NTLM and Kerberos.
The IIS Server should be configured via Group Policy or Local Security settings to disable LM authentication ( Network security: LAN Manager authentication level set to "Send NTLMv2 response only" or higher, preferred is "Send NTLMv2 response only\refuse LM & NTLM") to prevent trivial LM hash cracking and to prevent NTLM man in the middle proxy attacks.
Kerberos can be used, however it only works if both machines are members of the same domain and the DC's can be reached. Since this doesn't typically happen over the internet, you can ignore Kerberos.
So the end result is, yes, disabling anonymous does open you up for password cracking attempts and DOS attacks, but these can be prevented and mitigated.
You should read about differnet authentication mechanisms available: Basic, Digest, NTLM, Certificates, etc. The IETF compiled a document that dicusses the pros and cons of some of these (NTLM is propriatary MS protocol).
Bottom line is: You are not done with just disabling anonymous access. You definitely have to consider carefully what the attack scenarios are, what the potential damage might be, what user may be willing to accept and so on.
If you introduce authorization you need to address the risk of credentials being compromised. You should also think if what you actually want to achieve is confidential transport of the content: In this case you will have to instroduce transport layer security like SSL.
I am by know means a hosting guru and I imagine there are ways and means of doing this but my personal opinion is that what you are talking about doing is defiantly an unnecessary security risk. If this site is to be available on the internet i.e. it will have public access then you probably don't want to disable anonymous access in IIS.
Please remember that the idea of being able to configure the anonymous access for a site in IIS is so that you can create a user which has specific permission to read the relevant files for a particular site. What we are talking about here is file access on a physical disc. For one thing a public web server should be in a DMZ and not part of your companies domain so users should not be able to log in with their domain credentials anyway.
The only reason why I could imagine that you would want to switch off anonymous access and force users to input their Windows credentials is for a site which will only be used internally and even then I would probably not choose to restrict access in this manner.
If you want to restrict access to content on a public website then you would probably be better of writing something which handles authentication as part of the site itself or a service which the site can consume. Then if someone were to obtain user credentials then at least all they will be able to do is gain access to the site and there is no potential for a breach of your internal network by any means.
There is a reason why developers spend allot of time writing user management solutions. You will find plenty of advice on how to write something like this and plenty of libraries that will do most of the work for you.