Azure Application Gateway Basics

Azure Application Gateway is a http traffic load balancer that allows me to manage my web traffic.  So based on urls, paths, the traffic can be pushed on accordingly.  It also provides for sticky sessions.  In my head I see Azure Application Gateway as a layer 7 HTTP Load Balancer and a Web Application Firewall (WAF).  There are 3 core concepts: Front-ends, rules and backends that are used to route traffic from the front-end to the back-ends.

Azure Load Balancer works at level 4 where Azure application gateway is for web traffic at layer 7 of the OSI model.

Azure Front Door is basically for world wide Application gateway functionality.

Checklist on the Application Gateway: 

• You should enable the WAF unless you already use another WAF like Imperva enterprise wide, do this under the "Web application firewall" option, setup OWASP rules.  
• Config session affinity, and HTTPS termination using the "HTTP settings".  
• "Listeners"  are what listens for incoming http requests.
• "Rules" bind the listeners to the backend pools.
• "Backend pools" are used to point traffic to the end points.  Also remember to setup "Health Probes", this allows the App pool to verify the backends are working.
•  Ensure you set the diagnostics logging to send logs to "Log Analytics" so you can examine the logs.

Features: 

1. SSL/TLS termination - Terminate SSL using certificate
2. Autoscaling - increase the size or instance count based on traffic requirements
3. Can be setup to be zone redundant
4. Static IP address that doesn't change
5. WAF and DDoS (pretty new 2022, applied using Azure DDoS Sentinel service) capabilities - The WAF allows you to apply OWASP rules and add additional custom rules.  Bot protection is also built in, rules need to be applied to get it to work.  
6. URL-based routing
7. Multiple domains/site hosting
8. Redirection
9. Sticky sessions/session affinity
10. HTTP/2 support
11. Custom error pages (so useful)
12. Rewrite headers and URL

References:

How an application gateway works | Microsoft Docs

WAF options

TLS 1.2 & Wireshark Refresher

Overview:  I have lost count of the number of TLS upgrades I have worked on.  The upgrades are easy as long as you understand the basics.  I always throw a test rig together to check settings, update settings and get the configuration and the ability to check the traffic.  

Understanding Server and Client Registry Settings for TLS: 

• "Client" registry keys govern outbound protocol availability.
• "Server" registry keys govern which protocols are available for inbound connections.

Check TLS 1.2. connections from a client to a SQL Server:

The client machine host a Console/C# Test Rig that is connecting to SQL Server that supports only TLS1.2.  Then on the client Windows registry settings you are interested in the TLS1.2/Client/Enabled setting as shown above.  

• Below is a screen shot of a C# test rig, used to ensure the registry settings are correct (I restart the test rig after I make a change to the client/TLS registry settings.  Running the "Test Connection", tells me outbound traffic is using TLS1.2, the successful connection tells me that SQL Server is accepting TLS1.2 traffic.

If unsuccessful or you want proof: 

Wireshark - replicates the network traffic packets going thru the machines drivers/adapters.

• Wireshark is a great tool, and can be used to verify the underlying traffic, in this scenario I have Wireshark on the client machine to capture and analyze the TLS traffic going to the SQL Server generated by the C# test rig.
• Ensure you have the adapters you want to monitor selected, and I have added a  filter to only show traffic being sent to the SQL Server using the IP address.  "hosts 10.1.x,25"

Capture the traffic, you'll see the connection being setup in the packet transfer.  The protocol will show TLSv1.2 in Wireshark.

TLS1.2 traffic

TLS1.0 Outbound Traffic

Use Netsh or Pktmon to capture local adapter traffic, then load the logs in Wireshark.  c:> netsh trace start capture=yes from the admin run cmd prompt to capture packets.   Packet Monitor (Pktmon) is also an option.

tcpdump is a good tool also. 

More Info:

https://social.technet.microsoft.com/wiki/contents/articles/41703.sql-server-securing-network-communications.aspx

Delphi TLS 1.2 to SQL Server connectivity issue

Thanks to Akshay for  figuring the issue out & working on this with me.

Problem:  C# is connecting to SQL Server using TLS1.2 & TLS 1.0.  But  Delphi application only connects using TLS1.0.

Initial Hypothesis:  

Ensure the client machine can connect using a C# test rig, or check the traffic works from any app using Wireshark.

SQL Server is accepting TLS 1.2 connections using C# but not Delphi.  SQL is good, and the client machine allows outbound TLS 1.2 data.  Issue must be with Delphi.  Delphi is using SDAC 6 to connect to the database.  Issue must be with Delphi connectivity.  Delphi SDAC uses the "SQL native client" for TLS1.2 but TLS 1.0 works without the Native SQL client.  SDAC tries to use the "Native SQL Client", if it is not there it use OLEDB.  The OLEDB version used by SDAC6 does not support TLS1.2 only TLS1.0.  Wireshark showed the Delphi application trying to connect but can't get a TLS1.2 connection.  Installing the "Native SQL Client", the TLS traffic starts connecting on TLS1.2 using SDAC6.

Resolution: Upgrade Delphi/SDAC9 (or later) or install the "SQL Native Client" on all client laptops/machines.

Encryption Options for Azure SQL

Overview:  With all IT storage, we are looking for encryption at rest and making sure the data is encrypted “over the wire” until it is stored storage.  For encryption in transit, Azure SQL supports TLS/SSL versions 1.0, 1.1,and 1.2.  If possible got for TLS 1.2.

Azure SQL Server Transparent Data Encryption (TDE) related to encryption at rest by encrypting the log and data files on the storage; Azure enforces TDE as the default on databases.  TDE can be turned off on your Azure SQL instance.  The disks that the database files and backups are block encrypted automatically by Azure.

Backups should also be encrypted, and if TDS is enabled on Azure, your backups are also automatically encrypted.  Tip: Validate your restore of Azure Backups to another instance.

Column encryption is useful for encrypting a column within a table.  I prefer to use a Key Vault and use a SQL column to point to the database for things like tokens and secrets, but something like credit card numbers column encryption is ideal.

Always Encrypted allows for one or more columns to be encrypted within a database.  Client application shall decrypt and provides for separation where database owners/access cannot validate/view the encrypted column/columns.

Encryption at Rest on Azure SQL Server (PASS) Summary:

1. Disk Encryption - Always can't change
2. TDE - Server-Side - On by default (can be turn off)
3. Column level encryption - Server-Side (Needs configuration, encryption done inside SQL for columns)
4. Always Encrypted - Client-Side.  Columns are encrypted inside the db and only the application can unencrypt the column.

TLS 1.2 and SharePoint on-prem.

Problem:  By default SharePoint 2016 and SP 2013 use TLS1.0 for its communication protocol (think SSL version number).  A lot of companies and partners are now insisting your internal SharePoint farms support TLS 1.2 and not the earlier versions.  For various compliance frameworks (DSS PCI, HIPPA) you need to ensure you no longer use TLS1.0 or 1.1 and only support TLS 1.2 and soon to be TLS 1.3.  The problem is that earlier versions have potential vulnerabilities and can lead to various attach including being susceptible to man in the middle attacks.

TLS/SSL Basics:

Three Areas of Concern:

1. SharePoint Farm (upgrade to SSL across the farm, Supports TLS 1.2 on SP2010 & 2013 since +_Oct 2016) - biggest lift
2. CSOM Client VM (Ensure the client VM can send TLS1.2) - Jump boxes, browser
3. Ensure the Communicating App support TLS1.2 (Either .NET4.6.2 compiled apps default to TLS1.2 or problematically enforce the TLS order/version. 

Our business needs three parts:
1. SharePoint farm upgrade thru DTAP environments and Test
2. Calling application needs to use TLS 1.2 as the default and can potentially call backwards.  This includes IE/Chrome, calling CSOM code (either fix works: .NET 4.6.2 upgrade or pragmatically enforcing TLS), PowerShell
// C# CSOM programmatic fix to TLS inaccuracies
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls | SecurityProtocolType.Ssl3;
3. If your tools are on a Server ensure outbound TLS traffic is allowed.  IIS TLS settings affect both inbound and outbound traffic, overwrite the outbound if you need to in the registry.

Validate SSL SharePoint Web Front End:
Use PowerShell to check the WFE or an external tool like HTBridge.
Here is a great tool to look at your HTTPS web server/endpoint setup externally: https://www.htbridge.com/ssl

Tip: Removing TLS1.0 and 1.1 needs to be thoroughly tested as there are numerous dependencies such as OWA, Workflow, CSOM, Internal Comms, SQL Server.

TLS Issue - The underlying connection was closed

Problem:  I have a console using CSOM that stopped working when the TLS settings were updated firm-wide.  The communication is between the console and a SharePoint farm, using CSOM, and now it no longer works.  The event log generates the following error message on the client machine: A fatal error occurred while creating an SSL client credential. The internal error state is 10013.

Initial Hypothesis: The outbound HTTPS traffic is the issue as the error is telling me that the mistake was creating the SSL client credential.  The console runs on a web server, and the TLS restriction change has caused the issue.  This issue is that the console running can't create an SSL client credential.  The TLS change was made to the console VM and not the SharePoint farm.  Here is the PS script to validate TLS versions written by Vadims Podans.

The post below helped me query the windows web servers to check the TLS settings using PowerShell.  I believe the outbound is controlled by the inbound TLS settings.

Resolution:  Change the console to use a know TLS version e.g., TLS1.2 as shown below:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Alternatively, revert the TLS setting in the registry. Apparently, this means your server is more susceptible to attack.

Alternatively, specify all the portocols you support from the calling client side application ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls | SecurityProtocolType.Ssl3;

Read this section if you are still having issues.
Factors that Influence Settings:
My CSOM console sits on a VM that hosts IIS, so there are three components to ensure connectivity excluding networking:
1.> SharePoint Server needs to support the TLS version
2.> VM hosting my console's outbound SSL is also set by IIS local TLS settings, so if I want to speak on TLS to the SharePoint server, I also need to have SSL enabled (or registry hacked) on TLS1.2 on the IIS VM hosting my console.
3.> My Console needs to support TLS 1.2 or all versions so it can negotiate for itself.  Regedit to check TLS setting is shown below:

More Info:
https://www.sysadmins.lv/blog-en/test-web-server-ssltls-protocol-support-with-powershell.aspx

Also look at this post to enforce TLS1.2

HKEY_LOCAL_MACHINE\SOFTWARE\\Microsoft\.NETFramework\\v4.0.30319

   SchUseStrongCrypto = (DWORD): 00000001

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\\.NETFramework\\v4.0.30319

       SchUseStrongCrypto = (DWORD): 00000001