when we create the SP connection / IDP connection. We can export the connection metadata.
How important is this connection metadata. Is it confidential and not be shared with anyone? as the certificate related information is present in it. Do we have to keep control on it?
SAML 2.0 metadata only includes public keys of certificates, not the private ones, so that shouldn't be an issue.
The latest version(s) of PingFederate even allow the usage of a URL for metadata, from where the actual details are pulled, which is also common practice with other solutions, so it's not really that confidential.
Related
All,
I am trying to mount a NAS drive to a Linux VM.
I have a requirement to encrypt the data in transit, i.e. I want data to be encrypted when
its written from the Linux to the NAS dribe
https://www.dellemc.com/hu-hu/collaterals/unauth/technical-guides-support-information/products/storage/docu88304.pdf
As per the above link krb5p provides encryption of data.
krb5p: Kerberos authentication, data integrity, and data privacy by encrypting the data before sending it over the network. Data encryption requires additional
https://www.varonis.com/blog/kerberos-authentication-explained/
I understand how Kerberos mutual-authentication works but once access is granted to the service (in my case the NAS drive) how does the data transferred to the NAS gets encrypted.
Can someone provide additional details or documentation on how "encryption" works with krb5p?
I am unable to find any additional details.
As per:
https://whyistheinternetbroken.wordpress.com/tag/krb5p/
when using krb5p:
NFS packets will be encrypted with the enctype specified in the Kerberos configuration.
But what are the available enctype that can be specified?
I have attached a diagram that tries to explain the flow of messages b/w Server-KDC-Client
Kerberos allows mutual authentication between a client and a KDC, the KDC and a service, and a client and a service. This happens by way of key agreement between each party.
Client and KDC prove knowledge of a shared key, KDC and service prove knowledge of a different shared key, so client and service can generate yet another random key and agree with one another.
In other words when the client sends the ticket to the service it contains a secret key that both parties can use to encrypt data after authentication has succeeded. In this case that key is what is used to protect NFS traffic.
What enctype is selected is somewhat undefined. It's up to all three parties to agree on one, and each has an opportunity to change it. In practice it's up to the service to make the final decision though. It should be whatever it thinks the strongest algorithm the client can handle. This usually means RC4, AES128, or AES256.
Kerberos just provides the encryption key, but it doesn't magically perform the encryption itself – that has to be done by the NFS client and NFS server themselves. They are aware that krb5p was negotiated, and will call the corresponding encryption/decryption functions when needed. (More specifically, it happens in the SunRPC layer, which NFS is built on.)
When the Kerberos KDC issues you a ticket for "nfs/yourserver.example.com", that ticket includes two copies of a randomly generated session key: one copy decryptable by you, and the other copy decryptable by that server.
The KDC will mark this session key with the best enctype that is common between what was indicated in your ticket request, and what long-term keys are held by the server's principal. Usually this will be AES256-CTS, though it can be RC4 (arcfour) if the service key hasn't been changed in a very long time.
For example,
The "nfs/yourserver.example.com" principal has long-term keys for aes256-cts-sha1-96, aes128-cts-sha1-96, arcfour-hmac, des3-cbc.
Your client making the AS_REQ indicates support for aes256-cts-sha384, aes128-cts-sha256, aes256-cts-sha1-96, aes128-cts-sha1-96.
The KDC chooses aes256-cts-sha1-96 as the best enctype for the session key.
This indication is stored in the ticket itself. If the client is using MIT Krb5 software, you can use kvno to manually request a service ticket (if you don't have one yet) and then klist -e to see the enctypes set for that ticket – "skey" indicates the enctype that the session key is meant to be used with.
So after receiving the ticket from the KDC, you send it to the NFS server as part of the RPCSEC_GSS authentication process, and now both you and the server have copies of the session key. (The same session key remains in use for as long as the service ticket is valid – usually 10 hours.)
The set of possible enctypes is:
aes256-cts-hmac-sha384-192, aes128-cts-hmac-sha256-128: New, not supported by most implementations yet (and most services won't have keys of that type yet, either).
aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96: Widely supported by all Kerberos implementations.
camellia256-cts-cmac, camellia128-cts-cmac: Decent alternatives to AES, but rarely used in practice.
arcfour-hmac (RC4): Deprecated, but still occassionally used. Gone from Linux 5.10.
des3-cbc-sha1: Deprecated, but still implemented.
des-cbc-md5, des-cbc-crc: Completely obsolete. Hope you'll never see those.
(Don't believe webpages saying that Linux NFS client only supports DES – that was fixed in 2010 for v2.6.35, and AES is fully supported now.)
I have a Windows Server 2008 R2 machine running IIS7.5. This webserver hosts many websites under different domains and each website contains several asp.net applications.
Support and development access to this machine is quite restricted due to customer requirements. I want to use the Microsoft.Web.Administration library to query the configuration of each of these applications in an asmx web method:
[WebMethod(MessageName = "GetDatabases")]
public List<Connection> GetDatabases()
{
List<Connection> connections = new List<Connection>();
ServerManager sm = new ServerManager();
foreach (Site site in sm.Sites)
{
foreach (Application app in site.Applications)
{
System.Configuration.Configuration config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(app.Path);
foreach (ConnectionStringSettings cs in config.ConnectionStrings.ConnectionStrings)
{
try
{
SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(cs.ConnectionString);
connections.Add(new Connection { Site = site.Name, Path = app.Path, Name = cs.Name, InitialCatalog = builder.InitialCatalog, DataSource = builder.DataSource });
}
catch
{
connections.Add(new Connection { Site = site.Name, Path = app.Path, Name = cs.Name});
}
}
}
}
return connections;
}
This code runs fine in Visual Studio but once deployed to the server an error occurs:
Server was unable to process request. ---> Filename: redirection.config
Error: Cannot read configuration file due to insufficient permissions
I researched how to work around this issue and found this page:
http://www.iis.net/learn/manage/configuring-security/application-pool-identities
So I created a new application pool just for this webservice and configured the Application Pool identity to have read-only access to the folder containing redirection.config (C:\Windows\System32\inetsrv\config) using the ACL of the folder. (I did this for the folder rather than the file as it seems that more than one file in the folder is required.)
My question therefore is: as long as I restrict access to the webservice properly, are there any security implications with doing this? It seems ok to me but the implications of making the configuration of these customer sites public could be career limiting to say the least!
Thanks,
Owen
EDIT: Just wondering if I have worded this question properly? So far no-one has taken a stab at answering it so this edit is mainly to bump it ;)
I'm no security expert (so take my words with a pinch of salt), but I would say that there isn't a hard and fast answer on this. However, most probably lean more towards recommending against this.
If your requirement is to allow support to see the connections your different sites use, then I see no issue creating a service like this in general principle, so long as you are careful.
That said, there are a number of things you should think long and hard about before going ahead with it:
Could the same be achieved by simply creating a secured share on the Server, and granting your support/devs RO access to that location? That may be more secure than writing your own service.
If you are doing this via a webservice, you should add security to the service to prevent unauthorised access (I'd probably use windows authentication myself, but that depends on your requirements)
I would recommend that you ensure that this service is not visible outside your Local network: you don't want someone from the wider web to be able to get onto this
Use an SSL connection for your service, to prevent packet sniffers being able to snoop on your traffic and retrieve this sensitive information.
I would recommend stripping out sensitive information from the Connection string before displaying it. At a minimum, I would remove the password. Anyone who needs the password already knows it, or knows how to get it. Anyone who doesn't need it won't be able to get it via this tool. You may also want to strip out all but the last part of the IP, it's not really secure, but it helps obfuscate information that would make it easier to hack.
Above all, you almost certainly want to communicate this to management/the customer, clearly lay out the potential risks, and detail what (if anything) you will do to mitigate it. If they sign off on it after all that, then the responsibility is really with them.
Security of the web service should be your last concern, primary concern is should you even make such a sensitive/confidential data available through a web service?
And the answer is straight NO.
More than security threats there may be quite a few legal implications on doing such a thing. Even if your customer is the sole owner of all the Apps running on their server they themselves may not be free decide about implementing such a functionality, as it may potentially be a threat to sensitive data belonging to their clients. So if you yourself are planning to make such a decision then you can very well imagine the consequences.
Moreover access to the servers and sensitive data like connection strings is restricted for obvious reasons, and that restriction should not be breached under any circumstances.
I have used MachineKey.Encode to encrypt a ID that is getting passed as a query string to a page but as expected this is making the URL huge.
Is there a option such as HTTP handlers that could customize the url but still load the required page?
Also I am yet to find out if MachineKey.Encode is using the MachineKey that I have defined in my web.config file to encrypt the data, can anybody confirm this for me with web information that backs this up.
Thanks.
Also I am yet to find out if MachineKey.Encode is using the MachineKey that I have defined in my web.config file to encrypt the data, can anybody confirm this for me with web information that backs this up.
It does indeed use the configured keys. MachineKey calls MachineKeySection.EncryptOrDecryptData to perform the encryption, which uses encryption objects configured from the machine key section. If you want to see for yourself, the interesting calls are EncryptOrDecryptData=>EnsureConfig=>ConfigureEncryptionObject=>SetKeyOnSymAlgorithm
i am new to terms used for server farms setup. There is an attribute called partitionResolverType.
Can someone please explain in easy words what is this partition resolver in the SQL server out-of-proc session state setup?
Thanks!
You specify what kind of session state you want to use, as described here.
If you are using either OutOfProcSessionStateStore (another machine) or SqlSessionStateStore, you may want to change the target machine or Sql server connection at runtime. For example, you may have three machines or Sql servers that you use as backing stores in order to reduce the load on session management.
You can write your own class (custom PartitionResolverType) that ASP will call at runtime to ask for either an IP address or Sql connection string. Your class implements the ResolvePartition(object key) method and returns a string, which is the IP address or Sql connection string of your session store.
You can find a good example here.
I wonder which class is the class that I use to encrypt data (first time string data) and the best method of encryption (among those supported by caché). Must generate a strong encryption for data in my project.
Any help is welcome.
If someone can show me some example, I'll be even more grateful.
Please state what exactly do you want to encrypt. To encrypt the whole database, there is a setting in System Management Portal, this encryption is certified in US. To encrypt data transfers, you may use SSH (see %Net.SSH.*), HTTPS (see %Net.HttpRequest with Https property), and Web Services with WS-Security (see documentation). To encrypt just any string internally, see $system.Encryption.Help().
We use ensemble web services to serve up Base64 encrypted XML payloads to web portals and mobile apps in the healthcare field. The code we've implemented looks something like the below snippet, in addition to some other security features related to the web service.
Set sc = ..xmlData.XMLExportToString(.xml)
Set xmlReturn = ##class(%System.Encryption).Base64Encode(xml)
Quit xmlReturn