(ASA5512) No ASDM connection

Thanks for this one Cisco :(

The symptoms of this particular problem threw me a little because ssh worked fine but ASDM just showed "Page not Found" or some such crap. Now I wanted to do some clean up on this box any way so I

erase disk0:/
format disk0:/

re-uploaded the core files.

asa912-smp-k8.bin
asdm-713.bin
csd_3.5.2008-k9.pkg
anyconnect-win-2.5.2014-k9.pkg

When it came back up I entered the license key and it still did not work >:(

So anyway, here is the fix.

Add these two lines in config# mode:
ssl encryption aes128-sha1 
ssl encryption 3des-sha1


The issue is described in the ASDM manual:

(PowerShell) GeoLocation of an IP address from the command line.

Powershell:

(Invoke-WebRequest http://ipinfo.io/<ip address>/json).Content


EX:

(OSX) lsof -i [View PID associated with a socket]

Just a note, I need to putz with this. It looks better than netstat-nao | grep tcp. 

lsof -i 

(OSX) GeoLocation of an IP address from the command line.

So I was trying to figure out an easy way to get a GeoLocation from an IP address. I wanted a one liner that could get the info instead of having to go to a web page.

The info.io web site did the trick. It outputs in json format.


curl ipinfo.io/<ip address>


EX:

Powershell:

(Invoke-WebRequest http://ipinfo.io/<ip address>/json).Content


EX:

(PowerShell) Enumerating Local User Accounts

This was mildly annoying so I thought I would put it here so next time I run into this I know how to do it. I wanted to simply enumerate all of the standard user accounts on the LocalMachine using a one liner PowerShell cmdlet. Most of methods I found online with a google search said to use [ASDI]. This was more convoluted than I wanted to get to do this seemingly simple thing.

After stewing for a bit I started digging through the Get-WmiObject cmdlet and there it was!!!

-Class Win32_UserAccount


So I took a look at the available properties and output the usernames only.

Get-WmiObject -Class Win32_UserAccount | Get-Member

So I just formatted the output to include just the Name property and there it is.

Get-WmiObject -Class Win32_UserAccount | Format-List -Property Name

But we are not going to stop there :)
I went ahead and pulled just the admin account.

Get-WmiObject -Class Win32_UserAccount | Where-Object{$_.Name -eq "Administrator"}

That was only a subset of the properties so I used Format-List -Property * to pull up the rest of them

Get-WmiObject -Class Win32_UserAccount | Where-Object{$_.Name -eq "Administrator"} | Format-List -Property *

Now that I can see all of the properties I can check for certain properties across all of the accounts. For example I can list all of the accounts that are currently disabled.

Get-WmiObject -Class Win32_UserAccount | Where-Object{$_.Disabled -eq $true}

If I break my one line rule I can even modify properties of the user object, for example lets say that I wanted to enable the Administrator account for some reason (Don't do this, I am just figuring out how this works and enabling the Administrator account is a bad idea).

[Note: The .Put() thing, this threw me for a few minutes. Remember when you use any of the Get- commands what you are actually doing is grabbing templates of the objects and then filling them with data PowerShell grabs from the OS. What I changed when I set Disabled = $false is the value in the new object I created. The .Put() command takes my object and saves it back to OS so that the changes take effect. Without the .Put() nothing changes on the OS]

$tempuser = Get-WmiObject -Class Win32_UserAccount | Where-Object{$_.Name -eq "Administrator"}

$tempuser.Disabled = $false

$tempuser.Put()



Now if I run my account disabled test from above I get this.

Get-WmiObject -Class Win32_UserAccount | Where-Object{$_.Disabled -eq $true}

(PowerShell) Filtering netstat output

Update:
This works great :)

netstat -bno


Since standard Windows command line tools can easily interact with PowerShell cmdlets I thought I would try some grep style string filtering.

Lets find all of the ports that are listening on our system:

netstat -nao | Select-String LISTENING

Output:

Or search for a specific port:

netstat -nao | Select-String :139

Output:

Search for all of the UDP ports:

netstat -nao | Select-String UDP

Output:

Now look for all ports that are UDP and on port 1900:

netstat -nao | Select-String UDP | Select-String :1900

:)

(PowerShell) Clock App Runtime

I wanted to figure out if there was a way in PowerShell to do something like the time command does in Linux (Calculates the amount of time in ms that an application takes to execute. It turns out that that it is built right in to PowerShell in the form of a cmdlet (Measure-Command).

I decided to start with something simple that would take a little time to complete.

Note: The {braces} define a statement block and in this case is used to combine the actions that you want to time. 

Measure-Command {Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue}

Output:

So that worked pretty much how I wanted. So I next I wanted to see if it would time something other than PowerShell cmdlets (like a regular Windows App). I wanted to do something that would take a bit of time so I copied a large file. I checked the PowerShell alias table to make sure robocopy was not an alias for a cmdlet  and gave this a try.

First I found a big file (did not care what it was, just that it was between 100-200MB)

Get-ChildItem -Path $PWD | Where-Object {$_.Length -gt 100MB -and $_.Length -lt 200MB}

Output:

Then ran the speed test on robocopy

Measure-Command {robocopy.exe $PWD $HOME MRT.exe}

Output:

So an executable without a GUI can be timed with no problem. What about a .exe that a user interacts with? It seemed to make sense that something like this would work.

Measure-Command {calc.exe}

Output:

Bad luck, it does not work, it only timed the launching of the app and then returned as soon as the window appeared. I need to do more research but I think that GUI apps disconnect themselves from the shell once they are launched and can not be measured this way :(.