|
|
rob's network & security blog covering windows, networking, firewalls, and anything else interesting that needs securing
-
One of the notable changes in Vista from XP is that Windows Updates can only be accessed using the option in the Start Menu. Trying to access http://windowsupdate.microsoft.com merely prompts you to use this 'local' option. Initially I did not see what difference this could cause to updates, given that both should result in the system accessing the Microsoft Windows Update site, checking for new updates and carrying on as normal. However, anyone deploying an internal WSUS server using Group Policy to force machines to use this server in particular may experience issues with mobile laptops. By using group policy to specify settings for Windows Updates (found in Computer Configuration, Administrative Templates, Windows Components, Windows Update - "Specify intranet Microsoft update service location"), only a single URL can be entered for the Intranet WSUS server: 
A Vista machine using this group policy will immediately go to the Intranet URL specified during scheduled updates or if manually using the Start menu option. If the Vista machine is out of the corporate network, and not connected using a remote access VPN of sorts, then an update ends with the Error Code 80072EFD. Failure to contact the URL specified in the Group Policy does not precede a connection attempt to the Windows Update site directly. This is presumably the case to ensure that the internal policy relating to security updates is not overruled by downloading patches directly from Microsoft, something which was possible under XP. A possible resolution is to make the Intranet WSUS URL publicly available over the Internet for those roaming hosts. This feature may be interesting to troubleshoot when Group Policy-enabled Vista clients are subjected to another corporation's NAC posture assessment, whereby access granted to the Microsoft site will not result in remediation (because the machine will be looking for its internal URL).
|
-
A colleague and I had some fun recently troubleshooting an issue regarding digital certificates and a Cisco ASA. I thought it would be useful to document the steps taken to resolve the issue as they can be applied to other circumstances when dealing with Windows 2003 PKI and non-Windows devices. In order to set up WebVPN (essentially SSL VPN connectivity) we needed to associate a trustpoint (Certificate Authority) with the ASA, and then get this trustpoint to issue a certificate for Server Authentication. The ASA does generate its own certificate for each interface (in the name of the IP address), but these of course are not issued by any known trusted CA and thus lead to browser errors when attempting access. The ASA does facilitate the use of SCEP which is a windows add-on allowing Cisco devices to enrol against a valid "IPSEC (Offline Request)" template (published when Microsoft-SCEP is installed on the CA) - this seemed the logical route to go down! After a few attempts we managed to get all the relevant certificates installed on the ASA using SCEP, but when associating the trustpoint with the external interface we could not bring up the login web page over HTTPS. This was a little strange as there wasn’t even a certificate error, but rather an HTTP 404 error. After quite a bit of messing about it transpired that the problem was the certificate request generated by the ASA does not include the "Server Authentication" key usage, and as such the cert cannot be used for web server authentication. We should have perhaps spotted this error sooner, but unwittingly assumed the ASA cert generation process would be suitable for our requirements. To resolve the problem we used a manual process of generating the certificate request, submitting this to the CA and importing the cert into the ASA. Along the way we had to convert certificates from PKCS#7 format to text and back. These were the stages required, which involved using OpenSSL: (Create manual trustpoint on ASA) 1. Pull off PKCS#7 CA certificates from Issuing CA (use the 'Copy to File' option in certificate to create a .p7b file) 2. Use OpenSSL to convert this .p7b file to a text file (readable by non-Windows systems): C:\OpenSSL\bin>openssl pkcs7 -inform DER -in "C:\certificateauthoritycert.p7b" -print_certs -text -out "C:\certificateauthoritycert.txt" 3. Generate a manual request for a certificate for the ASA and save to .txt file (using ADSM GUI) 4. Copy this .txt file to the Issuing CA, and use certenroll to manually request certificate with the correct attributes (by default a manual request from the ASA does not specify the Template name required) C:\>certreq -attrib "CertificateTemplate:CiscodeviceManual" -submit CiscoASAmanualrequest.txt [note: the CiscodeviceManual template was duplicated from the IPSEC (Offline request) template and added Server Authentication as a Certificate usage] 5. Once this certificate has been issued, pull off a .p7b format (using step 1) 6. Use OpenSSL to convert this .p7b file to a text file to import into the ASA: C:\OpenSSL\bin>openssl pkcs7 -inform DER -in "C:\CiscoASAmanualrequest.p7b" -print_certs -text -out "C:\CiscoASAmanualrequest.txt" 7. Manually import the certificate into the ASA and associate the Trustpoint with the relevant interface (which forces use of the associated issued certificate).
Thats it! You can download OpenSSL from http://www.openssl.org/
disclaimer: "The postings on this site are my own and don’t necessarily represent Conchango’s positions, strategies or opinions.”
|
-
It's been a little while since my last post. This is thanks (in no small part) to time spent researching Network Access Control and all its nuances in order to settle on a viable solution. By the way I am still yet to see a single offering that addresses all the issues I feel are necessary and relevant to provide a high level of security. This is not the subject of this post however. Rather, I would like to discuss the omnipresent Information Security Policy. One would be hard pressed to find an information security manual, text book or presentation that does not emphasise the importance of a security policy. The market has become so obsessed with this concept that the results of a Google search for "security policy" mostly relate to information technology rather than more quintessential areas (not to mention the Sponsored links as well). And rightly so - information security is a rapidly expanding science that is gaining in responsibility as our digital environments facilitate more communications, transactions and business. Criminals take advantage of technology as much as the rest of us, which necessitates the need for proper control and auditing of computer systems. The Security Policy is a document that explains the stance of the owner (usually a corporation) with regards to all aspects of IT security. We commonly encounter sections of this policy when beginning a new job. New starters are required to read and accept the terms outlined in some of the following areas: Acceptable Use Computer Systems Anti-virus Installed/licensed software Connected devices (MP3 players, USB drives…) Mobile Phones Email Internet Incident Response Data loss Virus outbreak Computer/laptop loss The security policy can either be a single (lengthy) document, or be broken down into smaller more readable papers. Regardless, a comprehensive policy covers all aspects of an organisation's computer-related infrastructure, and represents rules or requirements relating to this technology. Other similar documents include guidelines (best practices or how-to guides). Ok, so the development and management of a security policy certainly looks to be a good idea. It formalises the stance of the company in a clear and concise manner, so those interacting with any part of the company's computer infrastructure are aware of their limitations/restrictions, and also the consequences of overstepping these bounds. The question is, should Acceptable Use be governed by a security policy? It is laid out in black and white what can and cannot be done with computer systems, but does anyone actually adhere to this? Chances are that if staff believe they won’t get caught or aren't being monitored, then they will go ahead and check an Ebay bid or access their Hotmail account to see photos from last weekend's go-kart racing. In this sense what does the policy actually do? Well, it may provide a legal-binding document that allows the company to take action against the perpetrator, but by then the damage has already been done. IT staff, CTOs and managers are all well aware that adherence to a UAP is sort of best-endeavour - "I will adhere when my manager is around, but when I'm at home no-one will know if I use my company laptop to download some music from Gnutella". So do we sit back and hope for the best? Of course not! We actively investigate, test and implement technological solutions to govern the security policy in order to remove the human factor from the equation. By preventing users from having local admin privileges on their laptops, they are unable to install unwanted software, or alter proxy settings to bypass company URL filters. Software agents are ubiquitously used to monitor and manage software installations, licensing, anti-virus, personal firewalls and all sorts of applications that protect end-points. My question is this: At what point does the technology stop enforcing the policy and actually begin dictating the 'policy' (which in the latter sense is not a policy but a level of control)? Do we really need to bother users with UAPs? If we have the technology in place and are comfortable with it then couldn’t we rather just say "here is your laptop, you are allowed to do what you can do with it"? Before I completely discredit myself (and my views on company security - devils advocate anyone? ;), I should mention that I do believe there are certain aspects of information security that cannot be controlled using technical mechanisms alone, and so governance by a policy is the only form of protection (albeit not a foolproof one). These include human error, political/business requirements within an organisation and unmanaged services (with partners/customers). To summarise, the written security policy is a vital weapon in a company's information security armoury, but it shouldn’t stifle innovation on the technological front. The latter is often more effective.
disclaimer: "The postings on this site are my own and don’t necessarily represent Conchango’s positions, strategies or opinions.”
|
-
This is not entirely related to Conchango, but more to the role that I fulfil within the company as a Network and Security Engineer. I wrote an article about computer forensics for the ISSA Journal Magazine which was published in the September issue. The ISSA (Information Systems Security Association) is a global not-for-profit organisation dedicated to raising awareness of security management and best practices in order to attain a higher international standard of information systems security. The article is titled "Digital Forensics and the Role of the Sysadmin". It is only available to members of the ISSA, and is owned by the organisation (so I am unable to reproduce the document here). However, I did want to create a blog post for the article in case anyone reads the ISSA Journal and has any comments or feedback. The content of the article is directed at network, security or system engineers that are new to the concept of digital forensics. This is a term that will become increasingly more popular, and indeed more important as our scope of responsibility grows within our organisation. By this I mean that as more services and information move to digital format (document management, databases, web services, SOA, mobile connectivity, etc), so too does the propensity for attacks against these assets, not to mention the importance of these assets. Because of this it is vital that someone in the organisation takes responsibility for the systems and networks that facilitate the digital information. Not only do proactive security measures (to prevent attack, misuse or accidental loss) need to be enforced, but one should also consider the eventuality of one of these 'malicious' actions, and ensure that the infrastructure is suitably equipped (as are the people in charge of the infrastructure) to facilitate a forensic investigation. This investigation may be initiated to bring criminals to justice, or merely to realise the extent of damage and find the root cause/source (such as analysing a compromised system, checking Event Viewer logs, firewall logs, etc). The article provides an introduction to the subject and also recommends some steps that a sysadmin can take in order to be better prepared for post-incident investigations. If anyone does have comments I would be very happy to hear them.
http://www.issa.org/aboutissa.html http://www.issa.org/current-ij-toc.html
|
-
Network Access Control or NAC is already a well-worn buzzword/term amongst the network security community. There are a few variations of the term, depending on which vendor you are talking to. Cisco calls their offering Network Admission Control (NAC), while Microsoft are developing Network Access Protection (NAP). The Trusted Computing Group (a not-for-profit organisation bringing vendors together to develop industry standards) have a workgroup dedicated to the same field, referred to as Trusted Network Connect (TNC). All three major players, along with many other start-up technology companies, are looking to address the issue of the evolving threat landscape in our networks. The breakdown of conventional access-point barriers to our networks with the advent of WiFi and mobile devices has necessitated a rethink of our access control mechanisms. Other requirements, such as easily containing unmanaged (partner) systems and resources as well as centralised control over remote networks are all very real requirements that can be addressed by some sort of NAC implementation. After some initial research it appears to me as though players are approaching the issue from different angles. Cisco are happy to push a solution that is tightly integrated with their primary source of revenue – networking equipment (and why not!?). Microsoft are bleeding the technology into their Operating Systems, making use of current widely-adopted infrastructure services such as DHCP. On the other hand the TNC is more concerned with interoperability with multiple vendors, and as such is looking to create a framework that can be used in conjunction with participating vendors to create a viable solution based on the needs and current resources available to an organisation. There does seem to be some level of cooperation, although I think time will tell as to the exact extent. My initial findings have shown that the primary aims for a NAC solution are (very briefly) as follows: - Interrogation of hosts connected to network to reduce the threat of malicious or unwanted activity – this includes posture assessment, quarantining and ‘remediation’
- Control over network resources based on user authentication and authorisation
- Central control of a network infrastructure with regards to access from L2 (OSI model) upwards
What I have not seen too much of is the requirement to restrict access based on host only. In other words, hosts are authenticated (once their level of security regarding patches, anti-virus, etc has been accepted) based on username and password – it is these credentials that then determine the level of access on the network. While there obviously will be a distinction between managed and unmanaged hosts (the former having some form of agent) – it may be pertinent to control access based on host authentication. This then would extend the capabilities of NAC to include ‘unmanned’ devices such as other network gear, printers, fridges, vending machines, etc. I think a plausible solution is to integrate NAC with a PKI or identity management solution to further control how access is granted to who and what. Host + User credentials could even be construed as a two-factor authentication method. This is the line of thinking that I have been following when exploring an upcoming NAC installation. I recently read that Cisco have purchased a company that specialises in host-based authentication1. Perhaps this is the reason why. In any event, NAC appears to have a lot to offer, and a long way to go. 1 http://newsroom.cisco.com/dlls/2006/corp_081606.html disclaimer: "The postings on this site are my own and don’t necessarily represent Conchango’s positions, strategies or opinions.”
|
-
I came across a post on Bruce Schneier’s blog about the current security model and the 4-step pre-access approach (courtesy of the “Updating the Traditional Security Model” blog post) 1:
Authentication (who are you)
Authorization (what are you allowed to do)
Availability (is the data accessible)
Authenticity (is the data intact)
This was quoted in a previous firewall Wizards mailing list. The subsequent response from Dave Piscitello suggested that these days it is necessary to ensure the integrity (trustworthiness) of the endpoints is being validated prior to data transmission. I agree that this is an advisable additional step, and one that is gaining weight in various forms of connectivity. I also understand the need to be able to define such a model from a sufficiently high level. Realistically it would be better if we could devise a security model at such a level of abstraction that these new developments in technology were already catered for, albeit requiring a shift in low-level mechanisms and processes. Admittedly, the danger of too much abstraction is that it could result in a distinct lack of structure and meaning. My concern is that the technology landscape alters at a fairly rapid rate. Changing security policies to accommodate the latest developments on paper is ‘easy’, far less so in practice!
Nonetheless, let me continue…
Rather than the addition of the ‘Admissibility’ step as phrased by Dave Piscitello, I would suggest that perhaps the current 4-legged approach is sufficient from at least one point of view. However, the advent of more automated and business-oriented connections such as SOA and web services, not to mention the proliferation in connectable devices and locations, require a more thorough interrogation at each step.
Asking ‘what’ is a simple transmission of data associated with each host (name, IP address, service digital certificate, etc). The trick of course is to ensure the integrity of data shared between source and destination. Bi-directional authentication, an improvement perhaps on challenge-response, goes some way to accomplishing this. Other technologies such as NAC (network access control) attempt to guarantee the ‘cleanliness’ of the involved hosts to reduce the risk of malicious or incorrect information transfer.
What I think could be needed is a more intelligent approach to these security steps. The questions ‘what’ and ‘who’ (who is essentially a ‘what’ question – “what are you, what is your identifying data?”) don’t allow for more complex and relevant questions that involve ‘why’ and ‘how’. The nature of these questions requires the sharing or presence of knowledge.
Simply suggesting that some form of AI is the solution to current security concerns is not really satisfactory. The security world is aware of this issue, and certain products or initiatives such as the ‘Self Defending Network’2 imply an increased level of data and information analysis in order to produce a more dynamic and ‘intelligent’ system. I am sure we are still yet to see the most exciting offerings in this market area.
Without getting bogged down with the details, the point I am trying to make is that a security policy needs to be flexible and accommodating for both present and future technologies, developments and threats. In order to achieve this many factors need to be considered at the top level from the technology perspective. Traditional ACL or RBAC implementations need to be beefed up with service-based or ‘intelligent’ approaches to cater for the business and mobile services already in use today. The paper by Rattapoom Tuchinda3 discusses a similar suggestion.
1 http://www.schneier.com/blog/archives/2006/08/updating_the_tr.html
2 http://www.self-defending-network.co.uk/literature.php?id=1145
3 http://www.ai.mit.edu/research/abstracts/abstracts2001/intelligent-working-spaces/18tuchinda.pdf
disclaimer:
"The postings on this site are my own and don’t necessarily represent Conchango’s positions, strategies or opinions.”
|
-
When liaising with a business partner to create a site-to-site VPN it is often not the case that both parties are using the same firewall or concentrator hardware/software combination. There are a number of recognised firewall vendors offering products suitable for varying business environments and requirements (such as security, cost and performance).
Careful attention must be taken when configuring each end of the VPN. Failure to do so will result in the tunnel not being created and no packets being encrypted/decrypted. Furthermore it is often difficult to arrange a suitable time for both parties to troubleshoot the issue. Getting things right the first time is important.
Having used Checkpoint (currently NG AI) for a few years one of the primary advantages I have come to enjoy is the simple GUI for administration. Policies (including VPN policies) are defined and implemented using objects which depict IP addresses, networks, services, etc. One would think that creating a b2b VPN using a Checkpoint firewall is straightforward. This however is not always the case. There are a few pitfalls to be wary of, most of all in realising the difference in configuration between firewalls that implement security policies differently. Thankfully the amount of information relating the ‘best practices’ for setting up these hybrid VPNs is on the increase. When setting up an IPSec VPN between my Checkpoint and a SonicWall recently I was given the link to a very useful PDF:
http://www.sonicwall.com/Support/pdfs/technotes/VPN_Interoperability_Between_SonicWALL_TZ_170_SP_SonicOS_E….pdf
If memory serves me correctly the most important point here was that 1st and 2nd phase negotiations are set to 60 minutes (3600 seconds) rather than using the Checkpoint defaults. Obviously all settings relating to encryption algorithms, hashing algorithms, VPN domains and timeouts need to be identical in order for successful IKE and IPSec negotiations to take place. Any discrepancies run the risk of returning the dreaded entry in SmartView Tracker:
“encryption fail reason: Packet is dropped because there is no valid SA – please refer to solution sk19423 in SecureKnowledge Database for more information”.
The same applies for Checkpoint <-> Cisco VPNs. Both companies have published documents detailing the necessary steps for VPN creation, although they could do with some updating in my opinion (many still circa 4.1!). These can be a little tricky the first time round as each vendor has different naming conventions for particular attributes.
One of the more subtle issues relating to VPN connectivity is a Checkpoint’s propensity to automatically supernet adjacent networks during IPSec negotiation.
I have seen this issue a couple of times recently on VPNs with different hardware. If you have defined two sequential address ranges as a remote encryption domain on the Checkpoint (such as 10.1.1.0/24 and 10.1.2.0/24), when Phase 2 IPSec negotiations take place the Checkpoint will automatically supernet these into a single range (10.1.1.0/23). This of course does not match the remote firewall’s config, and will results in a message along the lines of:
IKE Responder: IPSec proposal does not match (Phase 2) (on the remote firewall) AND
IKE: Quick Mode Received Notification from Peer: no proposal chosen (on the Checkpoint)
In other instances the negotiation does succeed, which is evident when the subnet mask is highlighted as (mask= 255.255.254.0) on the Checkpoint. To me this does seem a little flakey, and may have been the cause of some intermittent issues I have had with VPN connections that fall into this trap. The resolution involves forcing the Checkpoint not to supernet by default. This can be done by editing the user.def file. For further details refer to sk26336 in the Checkpoint SecureKnowledge Database (this information is only available to registered users of the SecureKnowledge site).
There is another consideration which is the “Support key exchange for subnets” in the properties of the remote Firewall object (VPN Advanced settings). This option tells the firewall to find the subnet mask that encompasses the largest amount of objects in the encryption domain during key exchange. While this sounds similar to the problem mentioned above, the two do seem to operate differently. Enabling support for the key exchange results in a different subnet mask chosen by the checkpoint (depending on the VPN domain objects), but does allow connectivity. Disabling this before applying the fix described above does not seem to allow a successful key exchange. Once the fix has been applied my negotiations looked better (I did not see any sign of the supernetted mask), although I still get the odd “no proposal chosen”…
disclaimer:
"The postings on this site are my own and don’t necessarily represent Conchango’s positions, strategies or opinions.”
|
|
|
|