Securing your Network Infrastructure with 6 Layer Approach (My Approach)

 

 

Untitled

 

1. External Encryption: Encryption provides a way by which you can securely communicate when on internet. SSL (secure socket layer) creates a secure communication channel between the client and the server when communicating using HTTPS. Always keep your external facing web applications on SSL to mitigate risks like data theft. Check http://en.wikipedia.org/wiki/Ssl

2. External Firewalls: External firewalls is an important layer of defense because most of the time they stand between the public network and the private network. The nature of the attacks on the networks has now gone from DoS level attacks to more sophisticated Application level attacks. The external firewall you deploy should be capable of identifying the application level attacks. External firewalls mitigate the risks such as low level DoS (Denial of Service) attacks, unauthorized Intrusions etc. Check http://en.wikipedia.org/wiki/Firewall_(networking)

3. Application Authentication: It worthless to put encryption and firewalls in place if your application is not designed to secure itself. Application security is of upmost importance as it provides the 3rd layer in defense when it comes to overall protection of your infrastructure. Anonymous applications pose more threat than the applications which requires authentication from user in some form. The applications which are externally facing should be designed or integrated with some authentication method which can authenticate the users and the sessions connecting to that application. Check http://en.wikipedia.org/wiki/Application_security

4. System Level Authentication: System level authentication is important for both the servers and the client machines. The servers should be up to date with the latest updates and should incorporate service hardening techniques. Depending on what services are you running on the server, adopt the appropriate level of service security. Check http://technet.microsoft.com/en-us/library/cc163140.aspx for Windows 2003 security compliance toolkit. Also, http://www.microsoft.com/downloads/details.aspx?FamilyID=5534bee1-3cad-4bf0-b92b-a8e545573a3e&displaylang=en for the latest baseline policies. Baseline policies provide you a ground to start using that machine from a point with minimum set of security. You may increase the level of security by customizing the default policies.

5. Virus Scanning: Viruses, Trojan horses and worms are the real threats in today’s environment and can hamper the over working and availability of the machines, services and applications. Install the best Anti-virus solution of your choice and keep it up to date.

6. Authentication to Data: Data accessed by the server/application should be based on user authentication. Anonymous access to data on File shares or in databases poses a bigger threat as compared to when data accessed on authentication.

Each layer provides a certain level of security and when combined provides a security solution. You may add layers in between the above layers like Intrusion detection Systems, Internal Firewalls and Internal Encryptions to provide extra layer of defense.

Few Common steps to Secure IIS 6.0 Web Servers

  1. Disable NetBIOS over TCP in the TCP/IP Properties of the external NIC
  2. Uncheck "Clients for Microsoft networks" and "File and Print sharing" from the external NIC of the Web server
  3. Enable IPSec policies to restrict the traffic only coming to the port 80 or 443
    1. Create a general IPSec policy deny access from Any to Any for Any port
    2. Then create a specific IPSec policy to Allow access from Any IP to My IP on Port 80/443/Specific
  4. Install the Security Configuration Wizard from the control panel and create a new Security policy. Run this wizard on the same web server which you are securing so that it can compare the current security settings with that of recommended. This can be done remotely but we recommend doing it locally. Select the "Web Server" role from the Installed ones. Unselect all others. Make the necessary changes to the services which are required. In the end, check the current startup mode for the services in comparison to the policy based startup mode. Change the startup for specific services before in case they are appearing wrong. This should be run with care and a lot of testing in a lab. Once you are confident that things are working fine in lab, role the same policy onto the production web servers.
  5. Rename the local Administrator Account and Disable Guest account
  6. Rename the IUSR_computername account to something else. Then Go to the IIS Console and right click the local computer and click properties. Then select "Enable Direct Metabase Edit" check box. Apply changes and edit c:windowssystem32inetsrvmetabase.xml. Locate "AnonymousUserName" using the Find feature in the test editor tool and change it to the new user name you changed the IUSR_computername to.
  7. Move the IIS Logs and the virtual directories to the non-system directory to protect against the directory traversal attacks.
  8. Change the NTFS Permissions to allow only specific users on the parent directory in which all files of a website are located.
  9. Use SSL if possible

Migrating Microsoft Enterprise Root CA to An Offline Root CA Hierarchy

Assuming you have an existing Enterprise Root CA installed on DC and you want to split it in an Offline Enterprise Root CA hierarchy
 
Target Hierarchy: Offline Root CA -> Issuing CA
 
1. Back up the CA on the Enterprise Root CA (check http://support.microsoft.com/kb/298138/en-us for what all to backup)
2. Configure the Standalone Root CA on a different server and configured the CAPolicy.Inf at c:windows (Check http://technet2.microsoft.com/WindowsServer/en/library/25127c1f-4880-4764-85e8-226ce41588881033.mspx)
3. Copy the backup files you created in step 1 to the new offline Root CA computer. Note: this new offline Root CA should be part of workgroup
4. Then Install the Standalone Root CA with the Existing Public Key and restore the backed up CA database and Certificates on the Root CA
5. Configure the CRL extensions on the Root CA
6. Uninstall the Enterprise CA from Domain Controller
7. Configure the Offline Root CA using the script at http://technet2.microsoft.com/windowsserver/en/library/62a656d6-8023-4142-bb39-a10a0f7b14681033.mspx?mfr=true
8. Install another Issuing CA as an Enterprise Subordinate CA. Note: This server will be a part of your domain
9. Import the Root certificates for the RootCA to the Issuing CA
10. Generate a certificate request from the Issuing CA. Copy the .req file on your offline Root CA and Issue that certificate using the Certificate Authority MMC
11. Export the certificate generated from the Root CA to Issuing CA
12. Publish the CRLs and CRTs in the Active Directory. Check http://technet2.microsoft.com/windowsserver/en/library/091cda67-79ec-481d-8a96-03e0be7374ed1033.mspx?mfr=true to know the steps
13. From the client machine renew the certificates using “renew with same key” or you may also use Auto-enrollment from group policy
14. The Certification path on client machines should change to RootCA -> SUBCA -> ”Certificate”
15. Also now the issuer shows as SUBCA for the certificate, before this it was showing ROOTCA (enterprise CA installed before)
Cheers !!!
 

Migrating from Enterprise Root CA to Another Server

Here’s the process by which one can migrate an Enterprise Root CA to an another server. Assuming that your current Enterprise CA is installed on the Domain Controller.
 
• On the existing DC, backup certificate services (Follow the Article number http://support.microsoft.com/kb/298138/en-us). Also, backup the registry keys mentioned in the article.
• Remove the certificate services from the existing DC/CA
• Transfer the FSMO roles from Old DC to the ADC (This is the process of making your ADC as your DC)
• DCPROMO the old Domain and rename the server
• DCPROMO the Server to make it an ADC (optional)
• Build a member server with same name as Old DC and join it to the new domain
• Install the certificate services on the new member server
• Restore certificate services to new member server. Also, restore the registry keys you backed up in step 1.
Note: The name of the new CA server should be the same as it was earlier.
 
ADC = Additional Domain Controller
DC = Domain Controller

ISA Server – Back to Back Firewall Scenario

Back to Back firewall model which most of the companies will prefer because of easy design and greater sense of security. Since, this a good design very limited information is available on designing the architecture. So, i thought of writing this blog
 
 Design:
 
    Internet ====>>> ISA Front-End ===>>> DMZ =====>>> ISA Back-End ====> Internal Network
 
Since there two ISA servers involved you have to be very careful in how to configure both with rules and which rules will go where.
 
That being said, in this scenario Front-End ISA server will be used for authenticating the users and presenting with login information for DMZ Servers. Since. DMZ Servers need to contact internal or back-end servers we need to open some specific ports on the Back-End firewalls. Below article is a great resource which discusses about the same http://www.isaserver.org/tutorials/Configuring-Domain-Members-Back-to-Back-ISA-Firewall-DMZ-Part2.html 
 
For giving internet access to internal users you need to open access for HTTP, HTTPS and FTP on Back end Firewalll as well as on front end servers. Since, clients would require DNS servers to resolve the names for internet websites, you need to open access for internet DNS servers to query your ISP DNS servers. So, open port 53 on both Firewalls for smotth DNS resolution.
 
Greater care has to be put configuring Back-end firewalls as they are saving more sensitive servers/information. Any thing which is allowd on the Firewalls for temporary use must be turned off once the work is over.
 
Only Authenticated traffic should be allowed to pass through the Back-end Firewalls.

ISA server Domain Member or Workgroup????

This question is most common when you have Microsoft ISA server to be deployed in your organization. Whether to keep ISA a domain member or in workgroup?
 
Well….there is no specific answer to this question as ISA can be a domain member as well as work fine in workgroup scenarios. I really would like to laugh at people who tells me that putting ISA server in workgroup environment is more secure. It’s not important to know where to put, but it’s important to know why to put.
 
In my opinion, the ISA server should be a part of domain because it provides more flexibility in implementing many features which worksgroup scenario does not provide.
 
If you have ISA server 2006 in workgroup you want to use smart card functionality, you may not be able to use it because the smart card implementation does not work with RADIUS and LDAP (AD)
 
Some people think that if domain connected computer is compromised then its more chances that complete network is exposed. I would say if your workgroup ISA server is compromised then even it is in workgroup it’s still connected to the internal network and anyone can modify the access rules accordingly to gain access. Though, its not a easy task to gain access to ISA server since it hardens the OS as well when installed on Windows 2003.
 
Also, we recommend that you run SCW on the ISA server and choose the specific template for ISA server. It ensures that no un neccesary services are running
 
one of friend said that if some hacks my ISA machine then using the Certificate he/she can read the encrypted content within my network. And i was WOW !!!, i replied saying that on workgroup scenario its a requirement to have certificates installed on ISA server, now if you have certificate on it already then anyone can use it for anything including enrypted file reading 😉
 
If you dont have the ISA server in domain then you cannot use user certification authentication. It may be required when you dont want users to enter their username and password instead you want them to enter passcode and certificate. In workgroup you cannot use client authetication certificates
 

Security Best Practices

Security Best Practices:

Domain Controller (Windows 2003)

1.     Enable Audit policies for logon failures which will help you know when someone tries to do a dictionary attack

2.     Enable Account lockout policies and password policies for defending against dictionary attacks

3.     Run SCW (Security configuration wizard) and select the Domain Controller template

 

DNS Server (Windows 2003)

1.     Zone transfer should be turned off if you have only one DNS server. If you have multiple DNS servers, then point zone transfer to specific servers by mentioning their IP addresses

2.     Disable Recursion

3.     Use Root hints in place of Forwarders

4.     Use IPsec to limit the traffic only on Port TCP 53 and UDP 53

5.     Use SCW to secure the DNS Server

People who say Microsoft products are not secure enough…..think again. MSIT is securing www.microsoft.com from attacks everyday and as per a report out of 365 days Microsoft.com is under attack almost 245 days 🙂 and microsoft.com is the highest and favorite targeted website for attackers / hackers.
 
The biggest problem is that people dont know how to configure Windows products and also, they dont study about the best practices or case studies before their own implementation. There are 100’s of documents available on Microsoft.com which talks about how to secure your Windows Infrastructure. Check the security guides for your products from Microsoft. Also, check your configurations against the checklists from Microsoft which discusses about the configuration thats must for the specific product.
 
Its you who have to secure your Servers :), Microsoft can only tell you "HOW"

Firewall Questions?

Hi Everybody,
 
Since, we all know the best way to protect our computers against hackers or crackers is to have a firewall on our computers. Now, there may be alot of questions you would have regarding the "what firewall is", "what type of firewall to deploy" etc. for answering almost all your questions we in Microsoft have a FAQ on this. Please visit http://www.microsoft.com/protect/computer/firewall/faq.mspx and check what question you wanted the answer for.
 
In case you dont find an answer to your question, please feel free to write me and i will take care of that for you. 🙂
 
Hope to have some questions soon !!! 🙂

RADIUS Proxy in Perimeter Network (ISA server)

Scenario
======
 
You have RADIUS Proxy server in perimeter network and you have RADIUS server on intranet. Internet clients connect to ISA server extranet and ISA passes the credentials to RADIUS proxy. Now RADIUS proxy should contact RADIUS sever in order to have connection established.
 
Solution
======
 
FE = Front End Firewall
BE = Back End Firewall
 
Configure the RADIUS Proxy with the RADIUS Client as the IP address of the FE Firewall facing perimeter network. Also, configure the Default Gateway of the RADIUS proxy as the IP address of BE Firewall facing the perimeter network. Note: You can have the DG as the IP address of FE firewall in that case you have to give the following ciommand on your RADIUS proxy server
 
route add <BE Internal Network> MASK <Subnet Mask> <IP address of the BE firewall perimeter NIC>
 
Now, you need to configure the RADIUS access policy and RADIUS Server group on RADIUS proxy server. Once its done, move to the RADIUS Server and put the RADIUS Proxy IP address as its RADIUS client. Also, make the access policy allowing VPN port and Windows User groups. 
 
Configuring Firewalls:
 
1. Enable the Client VPN on FE firewall. Give the RADIUS Server address as the IP address of the RADIUS Proxy.
2. (Optional) You should have inbound and outbound traffic allow from internet to perimeter network (RADIUS PROXY SERVER) on port 1812 & 1813
3. On the BE firewall create a network rule from RADIUS Proxy in Perimeter to RADIUS Server(s) in Internal Network
4. Allow traffic from perimeter to Intranet (RADIUS SERVER) and Intranet to Perimeter
 
 These steps assume that you have already checked your RADIUS Proxy and RADIUS Server for communication in internal network.

Domain Isolation

Domain isolation is to mitigate the threat posed by unauthorized access to a trusted computer by an untrusted computer. Domain isolation provides better security when it comes to unauthorized access. IPSEC (Internet Protocol Security) protocol is the best one to be used in this scenario, making your Domain and Domain member servers communicate to the computers you trust. Using IPSec we can filter the traffic to our domain controller and thus making it more secure. IPSEC uses the encryption algorithms like DES or 3DES and integrity algorithms like MD5 or SHA-1.

Traffic from servers like RADIUS server to domain server should be IPSEC in order to protect the communication between them. Since, RADIUS server is used to authenticate the DIAL-IN users against the Active Directory making it more prone to Sniffing attacks. IPSEC allows to encrypt the communication between RADIUS server and Domain making it hard for someone to easily understand the packets being traffered.

Few Things to consider:

1. Ensure that inbound network access to a trusted domain member on the internal network requires the use of another trusted domain member.
2. Allow trusted domain members to restrict inbound network access to a specific group of
domain member computers.
3. Focus network attack risks on a smaller number of hosts, which provides a boundary to the trusted domain, where maximum risk mitigation strategies (such as logging,
  monitoring, and intrusion detection) can be applied more effectively.
4. Focus and prioritize proactive monitoring and compliance efforts prior to an attack.
5. Focus and accelerate remediation and recovery efforts before, during, and after an attack.
6. Improve security by adding strong per-packet mutual authentication, integrity, anti-replay and encryption.

IPSEC is one of best options when it comes to securing communication between two computers / servers.