In this blog post we will cover the following topics
- Tanzu Mission Control
- - Workspaces
- - - Creating a workspace
- - - Creating a managed Namespace
- - - Viewing a managed Namespace
- - Policy Driven Cluster Management
- - - Creating a Image Registry Policy
- - - Creating a Network Policy
The follow up blog posts are;
Tanzu Mission Control
- Getting Started Tanzu Mission Control
- Cluster Inspections
- Workspaces and Policies
- Data Protection
- Deploying TKG clusters to AWS
- Upgrading a provisioned cluster
- Delete a provisioned cluster
- TKG Management support and provisioning new clusters
- TMC REST API - Postman Collection
- Using custom policies to ensure Kasten protects a deployed application
Workspaces provide an application view, where you logically group Kubernetes Namespaces together, regardless of the cluster to which they are attached.
This is in contrast to Cluster Groups, which are focused on the infrastructure view.
These Workspaces can be created to align to your projects or applications, from a hierarchy point of view, you would then authorize your users to these Workspaces, so that they can monitor and manage the namespaces related to their function.
Creating a Workspace
Click the Workspace navigation view on the left-hand side, and then New Workspace.
Specify your Workspace name, and provide the optional description and labels, these can be added after creation if needed.
Now you have a Workspace, it’s no good without any associated Namespaces, so let’s continue.
Creating a managed Namespace
All Namespaces attached to a Workspace will be managed Namespaces under TMC.
To create a managed Namespace, you can do this in one of four places;
- Within the Workspace Navigation view
- Inside the Workspace Object itself
- On the Namespace Navigation view
- On the Cluster Object > Navigation Tab
Continue reading VMware Tanzu Mission Control – Workspaces and Policies
This blog post is by no means a comprehensive guide from an expert in the cyber security area. However my previous role meant I had the pleasure of reviewing a number of customer penetration tests and from this, pretty much all of them were all exploited in the same way. So I put together some basic information for any of my customers to review and think about before they had a penetration booked.
After all, might as well make it a challenge for the people you are hiring to hack your network 😉
Ok, so I’m only going to cover the basics, as there are far better articles out there on this.
- Information gathering before attending the targets site
- IP addresses of websites and MX record details
- Details of email addresses (shared mailboxes, employees direct)
- Social networks (details shared on LinkedIn by Employees, the companies twitter posts etc)
- Consider the below twitter post by a company, what information can you glean from seeing a picture of their racks and other equipment.
- If we know the company name, we can enumerate the various domain names they own to public IP addresses, and just plug that into a website like http://shodan.io and maybe look for that Sonicwall and find out if its running the latest firmware.
- Below when zooming in on the image, we can find details of an ADSL line
- Job websites; are they hiring, especially in IT, what skills do they want? Looking for an engineer that knows a particular accountancy package?
- Assessment of devices found and the search for vulnerabilities
- Tools in use such as, but not limited to; nmap, Nessus, Metasploit, unicornscan, nikto, dotdotpwn, gobuster.
- Create a plan of action/attack based on the information gathered.
- Perform the attack/exploitation itself to achieve the end goal, usually access to systems from zero, escalation with the end goal being access to private/sensitive/restricted systems and data.
- Tools in use such as, but not limited to; Kali Linux (OS and contains a lot of tooling), Nmap, Metasploit, BurpSuite, SQLMap, padbuster, custom exploit scripts
Common exploits to gain access
Ok so first, lets review how multiple networks were exploited or hacked.
Below is the common summary of issues found at many sites I reviewed, and this is what I will cover in this blog post ;
- Null session authentication on Domain Controllers
- Devices configured to use NBT-NS / LLMNR
- SMB Signing
- NTLMv1 in use for network authentication
- Domain Users have Local Admin permissions to their machines
- Poor password policy
- No split accounts for Domain Admins
- Poor patching on systems
Null Session Authentication
By default null sessions (unauthenticated) are enabled on Windows 2000 & 2003 servers. Therefore anyone can use these NULL connections to enumerate potentially sensitive information from the servers, read this as information from your Active Directory.
Therefore anyone with a legacy domain which has been upgraded through the years, will find that Null Session Authentication is enabled on their environments.
Seeing it in action Continue reading Notes from the field – Penetration tests
With my background in Networking and Virtualisation, VMware’s NSX is something which interests me deeply, as such I’ve attended a handful of sessions online, and also at the UK VMUG where Chris Whal presented on the subject.
Here’s my own interpretation of this new technology.
What is NSX?
Its software-defined networking, you don’t need to buy any hardware to implement it, although you do need a running VMware environment.
Continue reading VMware NSX – Just an introduction