CloudFlare (or others) and Corporate IP Issue - security

I just wonder whether CloudFlare (or others) manages this or not and if it manages how. The situation can be explained with a simple example. Think of a corporation in which there are 1000s of users. These users have the same IP (different internal IPs of course but external IP will be the same since it's a corporation..) and these users try to access the same site which is protected by CloudFlare. Will CloudFlare treat these users as the same users or not? How does DDos prevention tools manage this situation?
I would manage it as writing unique cookies for different users (kind of session_id) and look for this cookie value. Since it will be different for all of the users behind company network, there would be no problem..
Edit: That cookie solution is the way I'll go as a solution for my problem (if security vendors don't manage it..) and I didn't write it as the ideal solution for security vendors (that would be so arrogant:) )

Related

fallback for limitting web application access to certain ip addresses

We develop a web application.
There is a user login and a user area for the customers of a certain company.
And there is an agent/office login and area for some employees of the company who manage user account handling and so on.
The office agent has to login with his username and password.
But additionally, for security reasons, we will limit the agent/office login and area for specific IP addresses (as seen in other applications).
But we would like to have a "fallback" for certain situations where, for example, a web developer of the application needs access to the office area and has not one of the special IP addresses.
Until now we had not many ideas.
We thought of providing access when there is a very special user-agent string with a hash value.
Has anybody implemented such security mechanisms and can inform me about it?
Thanks alot in advance

Can I restrict website access to specific computers?

I realize that mac addresses or machine ids aren't transferred over the internet, however, I would like to lock down our subscription-based website security so that only specific computers can register and have access to its resources.
Large organizations will subscribe to our service and will undoubtedly have more than one ip for their organization. As well, we'd like to give the ability for their qualified employees to access the website on devices outside of their physical organization (for road-trip presentations, etc.).
Is there a sure-fire way to achieve this end (beyond the username/password assigned to each account)? If not, what would be the most effective approach?
Instead of restricting access via IP, you want to use something that's actually secure.
Username and password over an HTTPS connection should at least be unsniffable, but you might want to look in to client SSL certificates. They can be configured in Apache or other web server software. If username/password authentication is not enough, this is the next (and perhaps final) step up.
UPDATE:
That said, what many application providers will do is provide a method for subscribers to implement an ACL for their accounts. You can even force people to consider their ACL before allowing them to access your services. Think of it this way:
An account is set up in your system allowing login from anywhere. Upon creation, the ACL is UNSET.
User logs in and is immediately directed to an ACL setup page, where they must provide either an IP address or range or subnet associated with their account. You can be clever and pre-populate things with their existing IP address or subnet, perhaps even looking things up at ARIN to see if their IP is in a network assigned to the company name on their account.
Once the ACL is set (or they have, despite your warnings, confirmed that they want to keep their ACL open), they can access your services.
If they try log in from elsewhere, they (and you) are notified via email (or SMS or whatever) of an attempted breach.
If they no longer have access to their ACL-listed IPs (i.e. IP renumbering due to a new upstream Internet provider and bad planning), they can call your phone support who will validate them by other means. FAX confirmation perhaps, because that's SO secure...
A user-managed ACL is not a "sure-fire" way, but it may be sufficiently effective for your needs, and it will certainly instill a sense in your customers that you have their best interests at heart.
There is no sure-fire way. That's in the nature of networks. You accept data from a remote machine and you have to trust it at least to some extend.
Take the simple username/password approach. If the usename and the passwords match, you have to trust, that they where entered by the person that the username and password was intended for. This does not fundamentally change if you require more data to be send by the client.

Should I limit redemption of coupon by ip address only or is this not reliable?

My site allows all users to redeem a coupon. However membership is free to the site. How I structure my redemption system to best discourage people from creating many free accounts to redeem many coupons?
I was thinking of only allowing one redemption per ip per week. Is this reliable? What is the most reliable way?
Using IP is generally not great as, depending in the customer ISP, it might not be unique to the individual customer. You might be better off looking at cookies for tracking (and expire them after a week).
Terrible idea. Give it up.
Here's just a few reasons:
Everyone who works in the same office probably shares an IP.
Everyone who lives in the same house probably shares an IP.
Everyone who comes online through the wifi in that starbucks down the road, probably shares an IP.
Home networks where the router is set to use DHCP will get a different IP address every time it is bounced.
Users on cellphone networks will most likely be routed via a pool of proxy servers and can have different IPs even during the same session.

Default logon-Domain for Sharepoint

When running Sharepoint (WSS 3.0) with Windows Authentication (NTLM), external users must supply their usernames in the form of DOMAIN\username. This makes sense, because you could have multiple domains, trusts between them, etc. However in my case, I only have one domain, and I want my users to be able to logon with their pure username only. Is there any way to configure Sharepoint with a default logon-Domain to get this to work?
Changing the authentication to basic or forms is not an option for me.
That's a windows/IIS issue rather than something specific to sharepoint.
You can find a more detailed explanation at http://forums.iis.net/t/1151401.aspx but basically it's impossible due to the the design of integrated authentication - the client has to know the domain before the server is contacted.
The closest you get to a default domain is local logins on the server - potentially a solution if users are truly external.
Realize that some browsers can be configured to automatically provide NTLM credentials. For example, IE can do this. I believe by default it will for sites in the Local Intranet and maybe even for Trusted sites (if not, you can change it so it will).
There is software out there for pushing these settings (policies) out to users if their computer is a part of your domain.

Does it make sense to set up a trusted relationship between Active Directory instances at partner companies?

If a company often requires users to be created in a partner's active directory, and vice versa, does it make sense to set up a federated / trusted relationship between the AD instances? If so, what should be considered? Does the ACL for users in the partner AD still work the same way? What security risks does this expose?
Thanks!
KA
Update:
I've learned that there's a better way to do this by having the application itself check user stores. The best way to do this is by moving the application into a domain trusted by both user stores. I've provided more detail in my answer below.
I've been researching this a bit more, and I've found a good solution. Since both companies both need to use the same system, the system itself just needs to verify if a user exists in either of the user stores(authentication), and then to the authorization at the system level.
The idea behind giving both companies access is solid - If we are working together and didn't have a way to do this, we'd need to re-create all the users from the company without access in the connected user store. Obviously, this would be a total mess and a maintenance nightmare.
I found out that in my case, even though both ADs are on the same WAN, it's necessary to have a formal federation or trust. Thankfully, we already have a domain that's trusted between both companies, so I just have to move the applications used by the partners into this domain. After that, it's simply a matter of fully-qualifying the DNS suffix to indicate the AD being used. Application-specific ACLs then reference the desired user store.
Yeah, it makes sense if you want both to be able to authenticate people across mulitple domains. You have to put the server that has the application you're targeting in a domain trusted by every AD instance you want to use for authentication.

Resources