security

Why you should change your default passwords

So you bought that shiny new wireless router or your ISP gave you a new one after signing on to a new contract with them. The very first things many people do is personalize the SSIDs on the device so that they can distinguish their wireless network from their neighbor's wireless but forget to overlook a major security concern. In the article presented by Sophos, over 4.5 million DSL subsribers who got new modems from the dominant ISP in Brazil got duped because they didn't bother to change the default password on the device, however Sophos goes further in-depth in the situation by detailing the process the attackers used to change the DNS servers to malicious DNS servers which then points to malicious sites even though the site is legitimate. In the article it details that the DNS record for google in Brazil is google.com.br which is the legitimate domain name for the Brazilian version of Google. The hackers changed the DNS records by simply gaining access to all of the modems and the website looks legitimate when visiting it, however it asked users to download a file which the real Google never does. Moral of the story is to change your network device passwords as soon as you set them up because if they get modified without your knowledge you can be on the hook for something much more serious than simply changing your DNS to malicious DNS. Story from Sophos: source

Renewing SSL Certificates for Exchange

While there are a number of great guides designed to teach a budding Exchange Administrator how to add a brand new SSL certificate to your Exchange system, there seems to be a severe lack of guides to renew said SSL cert. As most of us administrators will spend more time renewing these pesky annual certificates rather than doing the first install I figured I needed to save this little gem so I can easily refer back to it year after year...

Some items of note before we get started. I've only tested this on my configuration, your systems may vary. This was tested on a fairly standard Exchange 2007 SP1 system running on Windows 2003 R2. Also this is not for the self-signed internal Exchange certificate (that process can be found here), this process is for your external facing SSL certificate (which I would assume is a purchased valid certificate from a 3rd Party root CA such as Verisign, Thwate, or even say GoDaddy if you are seeking a discount wildcard SSL cert).

So without further delay away we go, Administrators familiar with say IIS based renewals will likely be tripped up by the very first step, to begin the renewal process in Exchange 2007 you actually don't do a "renewal" per-se, instead you'll want to issue a new certificate request - there are two options here. Both of which are launched from the Exchange Management Shell:

Option 1:

Issue a SAN (Subject Alternative Names) Certificate - also called a wildcard certificate. These certs are very helpful for exchange environments as it can be used to replace the self-signed Exchange certificate as well as work for the multiple exchange sites such as autodiscover, owa.company.com, mail.company.com, etc.

New-Exchangecertificate -domainname mail.company.com, company.com, company.local, autodiscover.company.com, autodiscover.company.local, servername01.company.local, servername01 -Friendlyname companyExchCrt -generaterequest:$true -keysize 1024 -path c:\cerReq.csr -privatekeyexportable:$true -subjectname "c=US, s=Texas, l=Dallas, o=Company Name, ou=IT, cn=mail.company.com"  

Option 2:

Issue a Standard single domain certificate - useful for OWA only or environments that want to keep the self-signed exchange certificate - also MUCH cheaper.

New-ExchangeCertificate -GenerateRequest:$true -keysize 1024 -path c:\cerReq.csr -privatekeyexportable:$true -SubjectName "c=US, s=Texas, l=Dallas, o=Company Name, ou=IT, cn=mail.company.com"  

Under SubjectName you'll want to fill your values in appropriately.

c= Your 2 digit Country  
s= Your State (I tend to spell it out, though some just use the standard 2 character state code) l= Your Locality (City, Region, it's up to you)  
o= Your company name  
ou= Your Organizational Unit (common here is IT/IS Department or just omit if not required)  
cn= the common name of the certificate.  

This is important as it is the name the certificate will be issued on - if you are using this Certificate for OWA or even secure SMTP/POP access you will want this to match your MX DNS records (such as mail.company.com or owa.company.com - not as critical with a SAN cert).

Now the fun begins, you go to your certificate provider and go though the renewal process, when prompted attach or copy the text from your CSR file (c:\cerReq.csr if you followed the example above) and wait for your new certificate to be emailed back to you (or retrieved from the company's website).

Save this new certificate in a file called exchcert.cer on the root of your c:\

Note: if you get it from a web page you may need to copy everything from

-----BEGIN CERTIFICATE-----
          to   
-----END CERTIFICATE-----

into a text file (using notepad) and save it as c:\exchcert.cer

Open the Exchange Management Shell Issue the following command

cGet-ExchangeCertificate | fl | out-file -filePath c:\CurrentCerts.txt  

This will export all the certificates on the server to a text file, when opened it looks like this:

AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule}  
CertificateDomains : {mail.company.com}  
HasPrivateKey : True  
IsSelfSigned : False  
Issuer : OU=[www.verisign.com/CPS Incorp.by](http://www.verisign.com/CPS%20Incorp.by) Ref. LIABILITY LTD.(c)97 VeriSign, OU=VeriSign International Server CA - Class 3,  
OU="VeriSign, Inc.", O=VeriSign Trust Network  
NotAfter : 4/18/2009 6:59:59 PM  
NotBefore : 3/26/2008 7:00:00 PM  
PublicKeySize : 1024  
RootCAType : ThirdParty  
SerialNumber : 29BBFFD5AAAB541AB9BB2A73139AG335  
Services : IMAP, POP, IIS, SMTP  
Status : Valid  
Subject : CN=mail.company.com, OU=Terms of use at verisign.com/rpa (c)05, OU=IT, o=company name, L=Dallas, S=Texas, C=US  
Thumbprint : C21DE04E3123210AD28E430742C21D0194F46421  

Two things to note here,

Services: - these two are important to the next step - depending on what you use the current certificate for you will want to make sure the renewal cert does the same thing (in the example above this certificate does IMAP, POP, IIS, and SMTP)

Thumbprint: - this is used to delete the old certificate which is our next step.

Remove-ExchangeCertificate -thumbprint [old certificate thumbprint]  

from the example above:

Remove-ExchangeCertificate -thumbprint C21DE04E3123210AD28E430742C21D0194F46421  

You will get a confirmation to remove the old certificate, you'll want to type Y to remove it. Now you are almost done, we just need to add the newly renewed certificate back into the system.

Import-ExchangeCertificate -path c:\exchcert.cer | Enable-ExchangeCertificate -Services [your services from above]  

Using our example you will want to do the following to get the certificate working on all services (except Unified Messaging - UM).

Import-ExchangeCertificate -path c:\exchcert.cer | Enable-ExchangeCertificate -Services IMAP, POP, IIS, SMTP  

Now just to confirm all is working as expected, you will want to issue the following command

Get-ExchangeCertificate  

This will display something similar to this:

Thumbprint Services Subject ---------- -------- ------- C32DE24E1214210AD28E030742C21D0194F060D1 IP.WS CN=mail.company.com