Avoiding XPath: Part VI

Updated some 1/11/2020 -RMF

So this piece will begin a discussion about grokking Windows Security Event Logs inside rdata.table and Postgres. Use auditpol to set up kernel logging. We recall that to convert your EVTX archived security logs to CSV we need a Powershell function as below:

# Powershell Memory and CPU intensive
Function Convert-Logs3 {
[cmdletbinding()]
Param(
$filelist=$NULL
)
$filelist | foreach-object {
#Note that I am only getting four columns of data
Get-WinEvent -Path "$PSItem"| Select RecordID,ID,TimeCreated, Message | export-csv -notypeinformation -path $(write "$PSItem.csv");
[System.gc]::collect();
}
}

Convert-Logs3 "Archive-Security-2019-12-23-04-25-01-062.evtx"

#R
library(data.table)
d <- fread("Archive-Security-2019-12-23-04-25-01-062.evtx.csv")
h <- gsub('\n\t',' ',d$Message,fixed=TRUE)
h <- gsub('\n\n',' ',h,fixed=TRUE)
h <- gsub('\t\t',' ',h,fixed=TRUE)
h <- gsub('\n',' ',h,fixed=TRUE)
h <- gsub('\t',' ',h,fixed=TRUE)
h <- gsub('%%','',h,fixed=TRUE)
h <- gsub('\r','',h,fixed=TRUE)
h <- gsub('\r \r','',h,fixed=TRUE)
d$Message <- h

This produces row headings with data types:

names(d)
[1] "RecordId"    "Id"          "TimeCreated" "Message"
 
d[,sapply(.SD,class)]
   RecordId          Id TimeCreated     Message
  "integer"   "integer" "character" "character" 


# where you can use sample rdata.table queries like this:

d[,.N,.(Id,Message=substr(Message,0,100))][order(-N)]
d[Id == 4688,.(Id,TimeCreated,Message=substr(Message,275,375))]
d[Id == 4672 & !duplicated(substr(TimeCreated,0,11)),
.(Id,TimeCreated,Date=substr(TimeCreated,0,11),Message=substr(Message,400,500))]
d[Id == 4624 & grepl("S-1-0-0",Message),.(Id,Message=substr(Message,200,400))]
d[Id ==  4907,.(Id,TimeCreated,paste0(substr(Message,0,50),substr(Message,250,375)))]

There is probably much more you can do with Security.evtx files with mlr3 or rdata.table

# and then...I write out the file to be imported into Postgres:
write-csv(d, "Archive-Security-2019-12-23-04-25-01-062.csv")

tcpslice II

More uses for tcpslice, ipsumdump, BASH 4.1 :

[This gives you today's top source IP and source IP Port combination: 


/usr/sbin/tcpslice `date +%Y"y"%m"m"%d"d"` $BASH_ARGV | ipsumdump --no-headers -sD - 

./todays_dump.sh MarApr.snort.in.tcpd | sort -nr | uniq -c | sort -nr
     13 85.144.201.237 7959
      3 95.179.99.147 5900
      3 64.206.157.2 23
      3 222.45.112.59 8085
      3 109.187.8.70 5900
      2 98.247.214.152 23 ...

This gives you today's top source IP and source IP location:


/usr/sbin/tcpslice `date +%Y"y"%m"m"%d"d"` $BASH_ARGV |
for i in `ipsumdump --no-headers -s -`
     do echo $i : $(printf "%s" `./geoip.sh $i | awk -F":" '{print $2}' | awk -F"," '{print $1","$2","$3}' ` ) 
done 

./tgeodump.sh MarApr.snort.in.tcpd | sort -nr | uniq -c | sort -nr
     13 85.144.201.237 : NL,07,Amsterdam
     12 222.45.112.59 : CN,22,Beijing
      4 222.215.230.49 : CN,32,Chengdu
      3 95.179.99.147 : RU,43,Lipetsk
      3 64.206.157.2 : US,NH,Nashua
      3 109.187.8.70 : IPAddressnotfound,,
      2 98.247.214.152 : US,WA,Bothell ...

where 'geoip.sh' is:
geoiplookup -f /usr/local/share/GeoIP/GeoLiteCity.dat $1


I note that file names like this '08Mar1142PST2010.in.1268074842' don't process through tcpslice.

time stamping windows directory and file names

This is something I have blogged about before, but I thought it worth posting again.  Special characters need to be eliminated to create a time stamp that can be used as a Windows file name. The `date` program in Unix has a number of very useful options for this.  Windows cmd shell is more limited. This is what I use:

:: rtime.cmd
@echo off

set realdate=%date:/=.%
set realdate=%realdate:* =%
set realtime=%time::=.%
set realtime=%realtime:* =%
set timestamp=%realdate%.%realtime%
echo %timestamp%

This command script uses 'variable substitution' from the set command to remove special characters (e.g. :  / ) unacceptable as Windows file or directory names . This line:
set timestamp=%realdate%.%realtime%


can be changed as needed for more CSV compatible logging:
set timestamp="%realdate%","%realtime%"


Once cached, it runs pretty fast and is suitable for lightweight logging:

$ time /cygdrive/C/Security/rtime.cmd
06.02.2010.11.04.05.99

real    0m0.202s
user    0m0.015s
sys     0m0.031s

$ time /cygdrive/C/Security/rtime.cmd
06.02.2010.11.04.12.65

real    0m0.062s
user    0m0.000s
sys     0m0.015s

$ time /cygdrive/C/Security/rtime.cmd
06.02.2010.11.04.14.68

real    0m0.062s
user    0m0.000s
sys     0m0.015s

piping tcpdump output to lsof

This simple Bash script will output the lsof end of any foreign network connection:
[Set to the interface of your choice]
while [ 1 ]
        do
                for i in `tcpdump -i rl0 -c 1 -l dst $(hostname) | awk '{print $2}' | awk -F"." '{print $1"."$2"."$3"."$4}'`
                         do lsof -i@$i
                done
done
with time/date stamp added and headers removed:
while [ 1 ]

        do
                for i in `tcpdump -i rl0 -c 1 -l dst $(hostname) | awk '{print $2}' | awk -F"." '{print $1"."$2"."$3"."$4}'`
                         do echo `date -u` `lsof -i@$i | grep -v PID`
                done
done

Run like this:
./tcp_lsof.sh >> tcp.lsof.log &

the script produces output like this:

COMMAND   PID     USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
sshd    18392 rferrisx    5u  IPv4 0xd699ac80      0t0  TCP rmflaptop.rmfdevelopment.com:ssh->192.168.0.3:13974 (ESTABLISHED)
sshd    29850     root    5u  IPv4 0xd699ac80      0t0  TCP rmflaptop.rmfdevelopment.com:ssh->192.168.0.3:13974 (ESTABLISHED)
or
Wed May 26 15:22:06 UTC 2010 sshd 9448 root 5u IPv4 0xd699ac80 0t0 TCP rmflaptop.rmfdevelopment.com:ssh->192.168.0.3:15729 (ESTABLISHED) 
sshd 29734 rferrisx 5u IPv4 0xd699ac80 0t0 TCP rmflaptop.rmfdevelopment.com:ssh->192.168.0.3:15729 (ESTABLISHED)
Wed May 26 15:22:07 UTC 2010 sshd 9448 root 5u IPv4 0xd699ac80 0t0 TCP rmflaptop.rmfdevelopment.com:ssh->192.168.0.3:15729 (ESTABLISHED) 
sshd 29734 rferrisx 5u IPv4 0xd699ac80

Avoiding XPath: Part IV

 Full source  of my unpolished cruft is far below.  If you are going to pull fields out of the Message in Windows Event log without Xpath or XML, how are you going to do it in Powershell 4.0? I will remind you of what the Message field looks like:


Message              : The Windows Filtering Platform has permitted a connection.

                       Application Information:
                           Process ID:        3116
                           Application Name:    \device\harddiskvolume3\users\rferrisx\appdata\local\chromium\application\chrome.exe

                       Network Information:
                           Direction:        Outbound
                           Source Address:        192.168.0.11
                           Source Port:        2094
                           Destination Address:    8.247.65.200
                           Destination Port:        80
                           Protocol:        6

                       Filter Information:
                           Filter Run-Time ID:    211332
                           Layer Name:        Connect
                           Layer Run-Time ID:    48

So I can get to these fields with 'properties':

Get-WinEvent, EventLogs, ETL, Providers on Win7 Part III

Microsoft has exposed substantial providers since XP. With Windows 7, Microsoft has increased the number of providers substantially over previous versions of Windows and added 'netsh trace' functionality to enable tracing, conversion, batching of these kernel level counters. In the commands below, I have mixed cmd shell, powershell, cygwin cmds to parse ETL files. In  general, parsing etl files with 'get-winevent' and powershell takes a while...  You can understand 'netsh' filtering best with 'netsh trace show CaptureFilterHelp', however I recommend setting your 'netsh trace start maxSize=' parameter at 150 MB or less. (The default is an almost unworkable 250MB.)

Get-Winevent Part III: Querying the Event Log for Logons (Part D)

In Part A of this series ('Get-Winevent Part III Querying the Event Log for logons'), I worked with the 'where-object' cmdlet to filter through properties of specific logon event types. In Part B, I used '-filterhashtable' and 'findstr' to more quickly dig into the message field of logon events, utlimately producing a spreadsheet or database format of those events. In Part C, I presented code that enumerates all provider types for these events.  Then I used '-filterhashtable' with an array of multiple security EventIDs whose select 'Message' fields I searched with 'findstr' for specific properties relating to logons.  In this post (Part D),  I pull this all together, creating a timeline of multiple security EventIDs whose select 'Message' fields I pump into a spreadsheet for further analysis.

Get-WinEvent, EventLogs, ETL, Providers on Win7

'Get-WinEvent' in Powerhsell 2 when combined with ETL on Windows 7 allows exceptional event log queries. This function allows the administrator to create an array of all Event Logs and sort by 'time created' all those records created in the last (1) day:



function global:LatestLogEntries
{
   [CmdletBinding()]
   Param(
       [Parameter(Mandatory=$true,ValueFromPipeline=$true)]
       [int32] $param1,
       [string] $ErrorActionPreference="silentlycontinue"
            )


$LogNames=(Get-Winevent -listlog  * )
$goback = (get-date) - (new-timespan -days $param1 )
$LogNames | % {get-winevent -FilterHashTable  @{LogName=$_.LogName;StartTime=$goback}}
}

Parsing Vista Firewall Logs: Part I

These are the fields Vista HP logs for C:\Windows\System32\LogFiles\Firewall\pfirewall.log:

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

The Log meanders along like as below. Note the IPv6 broadcasts:

...

2009-07-22 08:15:00 ALLOW TCP 192.168.0.11 74.125.95.139 53218 80 0 - 0 0 0 - - - SEND

2009-07-22 08:25:21 ALLOW UDP 192.168.0.8 192.168.0.255 137 137 0 - - - - - - - RECEIVE

2009-07-22 08:25:21 ALLOW UDP 192.168.0.8 192.168.0.255 137 137 0 - - - - - - - RECEIVE

2009-07-22 08:25:31 ALLOW UDP 192.168.0.8 192.168.0.255 138 138 0 - - - - - - - RECEIVE

2009-07-22 08:26:20 ALLOW UDP ::1 ::1 62537 62537 0 - - - - - - - SEND

2009-07-22 08:26:20 DROP UDP 192.168.0.11 192.168.0.1 65300 53 0 - - - - - - - SEND

2009-07-22 08:28:15 ALLOW UDP ::1 ff02::c 54218 3702 0 - - - - - - - SEND

2009-07-22 08:28:15 ALLOW UDP ::1 ff02::c 54218 3702 0 - - - - - - - RECEIVE

2009-07-22 08:28:15 ALLOW UDP ::1 ff02::c 54218 3702 0 - - - - - - - RECEIVE

2009-07-22 08:28:15 ALLOW UDP fe80::2c20:349c:3f57:fff4 ff02::c 54218 3702 0 - - - - - - - SEND

2009-07-22 08:28:47 DROP UDP 192.168.0.11 192.168.0.1 52197 53 0 - - - - - - - SEND

...

Without pcregrep, grep, gawk, awk, uniq, [unix] sort, gnuplot, etc...parsing is problematic from the native windows cmd shell. The batch below works some magic, but we will need logparser.exe and/or powershell (or GNUWin32 or Cygwin) to do better faster parsing magic:

[ParseIPAllowSort.cmd]

findstr ALLOW pfirewall.log > Allowed.txt

for /f "tokens=1-8" %%a in (Allowed.txt) do @echo %%f %%h ^<^- %%e %%g %%a %%b >> AllowIP.txt

sort /r AllowIP.txt > SortAllowIP.txt

[output]

...

99.31.167.59 57604 <- 192.168.0.11 28656 2009-07-20 17:41:09

99.247.53.140 53591 <- 192.168.0.11 28656 2009-07-21 20:10:00

99.245.94.5 23791 <- 192.168.0.11 28656 2009-07-21 20:10:00

99.239.214.107 39950 <- 192.168.0.11 28656 2009-07-21 20:10:00

99.235.142.40 50446 <- 192.168.0.11 28656 2009-07-21 20:10:00

99.233.190.117 443 <- 192.168.0.11 28656 2009-07-21 20:10:00

99.172.37.127 38445 <- 192.168.0.11 28656 2009-07-20 18:21:45

98.28.36.109 36940 <- 192.168.0.11 28656 2009-07-21 20:10:00

98.28.36.109 36940 <- 192.168.0.11 28656 2009-07-20 20:44:03

98.28.36.109 36940 <- 192.168.0.11 28656 2009-07-20 19:23:52

98.28.36.109 36940 <- 192.168.0.11 28656 2009-07-20 18:21:27

98.28.188.233 25431 <- 192.168.0.11 28656 2009-07-20 17:48:08

98.249.81.221 10969 <- 192.168.0.11 28656 2009-07-21 08:46:43

98.249.81.221 10969 <- 192.168.0.11 28656 2009-07-20 21:39:58

.....

If we launch a scan against my host:

nmap -p 1-65535 -PN ScanTarget

Windump.exe with the latest Winpcap driver is very busy trying to log evey attempt:

C:\Users\admin\Documents\Downloads>windump -vvveXX -s 0 -i 1

windump: listening on \Device\NPF_{0F82FB9D-391A-4293-9D7A-215F53E05FAE}

21:59:20.361046 00:0f:b0:fd:44:2d (oui Unknown) > 00:1d:ba:8a:dc:28 (oui Unknown), ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 41, id 3782, off

set 0, flags [none], proto: TCP (6), length: 44) ScanHost.36950 > ScanTarget.11165: S, cksum 0x2072 (correct), 4211909807:4211909807(0) win 2048

0>

0x0000: 001d ba8a dc28 000f b0fd 442d 0800 4500 .....(....D-..E.

0x0010: 002c 0ec6 0000 2906 6f02 0a00 0003 0a00 .,....).o.......

0x0020: 0002 9056 2b9d fb0c a4af 0000 0000 6002 ...V+.........`.

0x0030: 0800 2072 0000 0204 05b4 0000 ...r........

.....

Vista Firewall apparently logs some attempts (perhaps enough to show a scanning pattern) and then drops the rest from the log. The packets kept look like this:

...

2009-07-21 21:48:12 DROP TCP 10.0.0.3 10.0.0.2 36950 445 44 S 4211909807 0 2048 - - - RECEIVE

2009-07-21 21:48:12 DROP TCP 10.0.0.3 10.0.0.2 36950 139 44 S 4211909807 0 3072 - - - RECEIVE

2009-07-21 21:48:13 DROP TCP 10.0.0.3 10.0.0.2 36951 139 44 S 4211975342 0 4096 - - - RECEIVE

2009-07-21 21:48:13 DROP TCP 10.0.0.3 10.0.0.2 36951 445 44 S 4211975342 0 4096 - - - RECEIVE

2009-07-21 21:48:13 DROP TCP 10.0.0.3 10.0.0.2 36950 135 44 S 4211909807 0 3072 - - - RECEIVE

2009-07-21 21:48:13 DROP TCP 10.0.0.3 10.0.0.2 36951 135 44 S 4211975342 0 4096 - - - RECEIVE

....

Get-Winevent Part IV: Querying the Event Log for 'Filtering Platform Connection' Information (Part A)

The command:

'auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable'

enables the "Filtering Platform Connection" security counter on Windows 7. The "Filtering Platform Connection" gives your event logs access to the following counters:

Filtering Platform Connection           Success and Failure

• Object Access Filtering Platform Connection 5150 The Windows Filtering Platform has blocked a packet. Windows 7, Windows Server 2008 R2
• Object Access Filtering Platform Connection 5151 A more restrictive Windows Filtering Platform filter has blocked a packet. Windows 7, Windows Server 2008 R2
• Object Access Filtering Platform Packet Drop 5152 The Windows Filtering Platform blocked a packet. Windows Vista, Windows Server 2008
• Object Access Filtering Platform Packet Drop 5153 A more restrictive Windows Filtering Platform filter has blocked a packet. Windows Vista, Windows Server 2008
• Object Access Filtering Platform Connection 5154 The Windows Filtering Platform has permitted an application or service to listen on a port for incoming connections. Windows Vista, Windows Server 2008
• Object Access Filtering Platform Connection 5155 The Windows Filtering Platform has blocked an application or service from listening on a port for incoming connections. Windows Vista, Windows Server 2008
• Object Access Filtering Platform Connection 5156 The Windows Filtering Platform has allowed a connection. Windows Vista, Windows Server 2008
• Object Access Filtering Platform Connection 5157 The Windows Filtering Platform has blocked a connection. Windows Vista, Windows Server 2008
• Object Access Filtering Platform Connection 5158 The Windows Filtering Platform has permitted a bind to a local port. Windows Vista, Windows Server 2008
• Object Access Filtering Platform Connection 5159 The Windows Filtering Platform has blocked a bind to a local port. Windows Vista, Windows Server 2008

This script, which uses some Powershell 3.0 features, produces the output far below (abbreviated) by parsing the output from EventID 5156 ("allowed connection"). The loops are structured to allow 'findstr' to dig out 'subfield' information. 'Select -unique' functions to find unique addresses (or ports):

[array]$a=Get-WinEvent -FilterHashTable @{LogName='Security';ID=5156;StartTime=$StartTime}
$UDA_count=$a.count
[array[]]$b=$a.Message | findstr 'Destination' | findstr 'Address'
$Global:UDestAddress=($b | Select -unique) | sort

The script takes an extremely long time to run on my five core laptop. These scripts (1,2) are optimized a bit more to search for only 5156 Events. The global variables in the script would be suitable for parsing against lists of allowed ports, allowed or blocked IPs. The Script can be used as a format for other counters as well. Several features from Powershell 3.0 are used in this script including the ability of Powershell 3.0 to 'automatically unroll' an entire array for a certain property (e.g. '[array[]]$b=$a.Message'). I could dearly use a much faster Powershell method to dig 'subfield' information out of the Message field than double piping that information to 'findstr'. The issue is that a single day of network activity generates ten of thousands of kernel security counters.  An alternative to limit the amount of information returned might be to use the '-max' [number of events] parameter:

Understanding an attack

Snort can be run in daemon mode, with a configuration file that logs on certain alerts only. For demonstration, we can run Snort in 'packet dump' mode (-dev) for a day or so while using BPF filters for our own needs:

/usr/local/bin/snort -devX -i xl0 -L $(date "+%b%e%H%M%S%Z%Y") 'port not(domain or whois or http or https or syslog or ntp or smtp or 137 or 139)' and 'not(broadcast or icmp or igmp or arp)'

After some awkward awk statements and some ditzy KSH work, we have a list of ports others who are seeking our network seem interested in:

snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | awk -F"->" '{print $1 ":" $2 ":" $3}' | awk -F":" '{print $4}' | awk -F" " '{print $1}' | sort -nr | uniq -c | sort -nr

14 2967
6 8000
6 5900
6 3128
6 22
5 23
5 1434
5 12712
4 7212
4 4899
4 1433
1 8080
1 7209
1 65535
1 56017
1 3306
1 23803
1 21
1 19756
1 19696
1 1024

snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | awk -F"->" '{print $1 ":" $2 ":" $3}' | awk -F":" '{print $4}' | awk -F" " '{print $1}' | sort | uniq | sort -nr >> ports.txt

for i in `cat ports.txt`; do grep -w $i /usr/local/share/nmap/nmap-services;done

http-proxy 8080/tcp # Common HTTP proxy/second web server port
http-alt 8000/tcp # A common alternative http port
vnc 5900/tcp # Virtual Network Computer display
radmin 4899/tcp # Radmin (www.radmin.com) remote PC control software
mysql 3306/tcp # mySQL
squid-http 3128/tcp #
symantec-av 2967/udp # Symantec AntiVirus (rtvscan.exe)
ms-sql-m 1434/tcp # Microsoft-SQL-Monitor
ms-sql-m 1434/udp # Microsoft-SQL-Monitor
ms-sql-s 1433/tcp # Microsoft-SQL-Server
ms-sql-s 1433/udp # Microsoft-SQL-Server
kdm 1024/tcp # K Display Manager (KDE version of xdm)
telnet 23/tcp #
telnet 23/udp #
ssh 22/tcp # Secure Shell Login
ssh 22/udp # Secure Shell Login
ftp 21/tcp # File Transfer [Control]
ftp 21/udp # File Transfer [Control]

Nmap services file helps explain much here, but why the large interest in a Symantec AntiVirus port? It turns out others have noticed this recently as well and are asking for input:

http://isc.sans.org/diary.html?storyid=6319.
http://msmvps.com/blogs/harrywaldron/archive/2006/11/27/new-botnet-impacts-symantec-client-port-2967-on-unpatched-pcs.aspx
http://www.offensivecomputing.net/?q=node/403

Is this a new or mutated trojan? worm? remote exploit? Multiple addresses are interested in connecting to us on this port:

# snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | grep 2967 | sort -nr | uniq -c | sort -nr

3 218.75.95.242:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:256 IpLen:20 DgmLen:40
2 119.161.130.75:6000 -> 192.168.0.12:2967 TCP TTL:99 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 61.191.63.8:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 61.145.62.75:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 60.173.12.60:6000 -> 192.168.0.12:2967 TCP TTL:106 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 60.172.229.11:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:65419 IpLen:20 DgmLen:40
1 60.172.229.11:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:42349 IpLen:20 DgmLen:40
1 222.186.26.93:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.140.174.105:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.14.156.149:6000 -> 192.168.0.12:2967 TCP TTL:102 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.14.156.148:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40

But the packet looks like a simple connection attempt to a remote port. A buffer overflow in Symantec AntiVirus port?

218.75.95.242:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:256 IpLen:20 DgmLen:40
******S* Seq: 0x60B40000 Ack: 0x0 Win: 0x4000 TcpLen: 20
0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E
0x0010: 00 28 01 00 00 00 69 06 55 BE DA 4B 5F F2 C0 A8 .(....i.U..K_...
0x0020: 00 0C 17 70 0B 97 60 B4 00 00 00 00 00 00 50 02 ...p..`.......P.
0x0030: 40 00 F1 34 00 00 00 00 00 00 00 00 @..4........

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

05/13-12:59:50.507559 0:9:5B:0:F3:DA -> 0:60:97:30:6B:C4 type:0x800 len:0x3C
121.140.174.105:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
******S* Seq: 0x4260000 Ack: 0x0 Win: 0x4000 TcpLen: 20
0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E
0x0010: 00 28 01 00 00 00 6B 06 66 06 79 8C AE 69 C0 A8 .(....k.f.y..i..
0x0020: 00 0C 17 70 0B 97 04 26 00 00 00 00 00 00 50 02 ...p...&......P.
0x0030: 40 00 60 0B 00 00 00 00 00 00 00 00 @.`.........

The National Cyber Security Effort

Inside the last three months, I have restarted my network security business: RMF Network Security (www.rmfnetworksecurity.com). I have been in research mode and I am still in some type of stealth mode, as I think about the implications of restarting a consulting business in the ever dangerous and now crime-ridden world of network security. The last time I did this, I didn't do enough "product development" and research in advance of my marketing efforts.  

However, the last year of network security 'awareness' may change my need to do extensive marketing. Our President has just announced the results of the sixty day Cyber Security Review. More than 100 source papers were consulted. See my initial analysis below. I started this obscure blog with the idea that I could use the motivation of internet publishing to gauge my re-education and business progress. Inside the first month, I have had the same extensive (web interest) in my blog from American military, military-industrial complex, telecom, educational institutions that I had with my Powershell Blog (also network centric),  but this time with lots of added hits now from Russia, China, ex-Eastern bloc and Brazil IP addresses. Interestingly, 'researchers' are mostly finding their way to my blog by googling IP addresses from my script dumps!

Apparently, my visitors are either expressing interest in the same Source Internet Protocol Addresses I am logging (SIPs) simultaneously or (worse case), those SIPs are looking at me while I discuss them.   The network security business has changed since I last participated in developing IDS systems with NAI and Hiverworld. Things are bigger, badder and scarier - more criminal and nation-state oriented simultaneously. Firewalls and IPS software are being pushed beyond their intended capacities and organized crime and nation-state terrorists have become systemized at IPS evasion, spamming, botnets, bot herding,  inserting key stroke loggers, malware, etc. "Cyberwarfare" has a new and significant government interest. Here are some reads I have found lately to prepare myself for changes in the field:

    * "The Shadow Government" (James Bamford)  This book documents the build-out in the cyber capacities of the National Security Agency in the last 8 years. Among other discussions it documents  how the NSA has purchased industrial strengthcontext searching software from select software companies to analyze traffic from top network access points across all U.S. telecoms.  This apparently is the book that broke the "warrantless wiretapping" scandal a year or so back.

    * "McMafia" Misha Glenny discusses in detail recruitment the young and poor as cyber hackers for nation state terrorists and criminal organizations in Russia, Brazil, China, ex-Eastern Bloc nations and elsewhere.  He also discusses world crime and world crime sophistication to date. A downright terrifying read. Apparently, the average computer in the U.S. is seen as a potential botnet member by most of the world's criminal syndicates/hackers.

    * FOIA from Wired Magazine on the FBI's CIPAV spyware : http://www.wired.com/threatlevel/2009/04/get-your-fbi-sp Also a very inetersting read...Criminals use spyware and so does our government...Surprise!

I had some difficultly searching all the 100 assorted papers on line at http://www.whitehouse.gov/cyberreview/documents/ and resorted to mixing Cygwin and cmd.exe shells to do so. I did an initial context search, which admittedly lost papers and data at each command line.  In any event, the papers may prove interesting reading yet, although they appear at first glance more policy oriented than technical.

[from cmd.exe or Cygwin]

lynx -source http://www.whitehouse.gov/cyberreview/documents/ | grep pdf | gawk -F\" '{print $4}' > source.txt

[from cmd.exe]

for /f "delims==" %i in (source.txt) do wget "%i"

[from cmd.exe or Cygwin]

ls -1 *.pdf > source2.txt

[from cmd.exe]

@(for /f "delims==" %i in (source2.txt) do pdftotext -f 1 -l 1500 "%i" pdf.txt && cat pdf.txt >> pdf.all.txt)

[from Cygwin]

for i in `cat file`; do echo `pcregrep -w -i -c $i pdf.all.txt` `echo $i` >> context1.txt;done

[from Cygwin]

$ cat context1.txt | sort -nr

499 Infrastructure

215 Services

194 Financial

53 criminal

52 crime

45 organized

45 loss

41 spam

39 malware

27 losses

24 Firewalls

20 botnets

16 Firewall

15 tax

14 organize

14 crimes

14 China

12 botnet

9 Russia

7 Linux

6 Windows

5 IDS

4 trojans

4 bot

4 IPS

3 bots

2 trojan

2 Israel

2 India

1 IE

1 France

1 Firefox

1 Apple

0 tcpdump

0 syslogd

0 sysklogd

0 spamming

0 keyloggers

0 keylogger

0 key-strokes

0 key-stroke

0 evasion

0 Snort

0 QNX

0 Opera

0 OpenBSD

0 Chrome

0 Bulgaria

0 Brazil

0 BRIC

If you are interested and have the time, let me know if you find my blog approachable, and what interests you think would most drive your businesses and professions to read and think about network security.  I think I am gearing up to producing some white papers tailored to many audience types: business, personal, home user, etc.  The goal is to generate interest for consulting contracts. 

Muxing AccessControl and FileInfo objects

Most of us know the members (partially printed at bottom) of System.Security.AccessControl and System.IO.FileInfo. And most of us know they both share the PS* NoteProperty items:

• PSChildName                     NoteProperty   System.String PSChildName=test.txt
• PSDrive                         NoteProperty   System.Management.Automation.PSDriveInfo PSDrive=C
• PSParentPath                    NoteProperty   System.String PSParentPath=Microsoft.PowerShell.Core\FileSystem::C:\
• PSPath                          NoteProperty   System.String PSPath=Microsoft.PowerShell.Core\FileSystem::C:\test.txt
• PSProvider                      NoteProperty  

PolyMorphic Multifunctional Spyware/Malware/Distribution Ware...

I have been writing scripts like those (far) below to parse my Firewall's syslogd output and wondering if there is some other, better way to understand the significance of my logs. Ultimately, I would like a little more information like: What causes the Firewall to behave as it does? Perhaps I am requesting a Firewall application log. For example, unidirectional SIPs are obviously blocked, but how does it know to continue bi-directional conversations across the WAN initiated from the LAN?  Sometimes I see an immediate block, other times I see a one packet delay.  Watching my firewall work drives home the point that the classic "firewall as perimeter defense" relinquishes control over what data escapes my network, especially if I do not employ host firewalls with bidirectional blocking capacity. 

And maybe even not then. The persistence of the current breed of spyware/malware/distribution ware (e.g. Conficker) is such that it can initiate web conversations on hidden, broken or validated channels (e.g register new domains) and then plunder host information from 'command and control' nodes once an internal node has established a validated external connection. Later the spyware/malware/distribution ware engages in 'polymorphic mutation' and updates itself to protect against updates in security products designed to detect it. The most notorious of such spyware/malware/distribution ware to date would be Conficker C. This is from http://mtc.sri.com/Conficker/addendumC/index.html:

"We present an analysis of Conficker Variant C, which emerged on the Internet at roughly 6 p.m. (PST) on 4 March 2009.  This variant incorporates significant new functionality, including a new domain generation algorithm and a new peer-to-peer file sharing service.   Absent from our discussion has been any reference to the well-known attack propagation vectors (RCP buffer overflow, USB, and NetBios Scans) that have allowed C's predecessors to saturate so much of the Internet.  Although not present in C, these attack propagation services are but one peer upload away from any C infected host, and may appear at any time. C is, in fact, a robust and secure distribution utility for distributing malicious content and binaries to millions of computers across the Internet.   This utility incorporates a potent arsenal of methods to defend itself from security products, updates, and diagnosis tools.  It further demonstrates the rapid development pace at which Conficker's authors are maintaining their current foothold on a large number of Internet-connected hosts.  Further, if organized into a coordinated offensive weapon, this multimillion-node botnet poses a serious and dire threat to the Internet."

I really don't think anyone has a clue of what to do about polymorphic, multifunctional spyware/malware/distribution-ware like this in terms of either prevention, detection, and perhaps removal. In fact, Conficker and other malware present a unique set of conundrums: Not just how do we detect this type of malware or how do we secure what we have already lost but how do we keep a multimillion node botnet from destroying the rest of the internet?  While the spyware/malware/distribution ware designers have propagated their creation throughout the universe, the rest of us are twiddling our fingers writing ditzy shell scripts in hopes they will tell us something about our Firewall's behaviour:

# more NotBlockedUniqLocation.sh                                                                                   

grep Dest message* | awk -F":" '{print $2$3$4 ":" "DIP:"$7":"}' | grep -v -f not_search.txt | grep -v [localhost] | awk -F":" '{print $3}' > NotBlocked.txt

for i in `cat NotBlocked.txt | sort -nr | uniq`; do echo $i `geoiplookup -f /usr/local/share/GeoIP/GeoLiteCity.dat $i | awk -F" " '{print $6 $7 $8 $9 }'`;done

# more BlockedUniqLocation.sh     

grep Blocked message* | awk -F":" '{print $2$3$4 ":" $6":"}' | grep -v -f not_search.txt | awk -F":" '{print $2}' > Blocked.txt

for i in `cat Blocked.txt | sort -nr | uniq`; do echo $i `geoiplookup -f /usr/local/share/GeoIP/GeoLiteCity.dat $i | awk -F" " '{print $6 $7 $8 $9}'`;done

# ./NotBlockedUniqLocation.sh 

222.172.105.109 CN,07,Zhongshan,(null),

217.109.17.57 FR,A8,Paris,(null),

216.73.87.115 US,NY,NewYork,

216.34.207.74 US,CA,WestlakeVillage,

216.34.181.91 US,CA,MountainView,

216.34.181.71 US,CA,MountainView,

216.34.181.60 US,CA,MountainView,

216.34.181.59 US,CA,MountainView,

216.34.181.40 US,CA,MountainView,

216.168.46.76 US,WA,Seattle,98168,

216.168.46.72 US,WA,Seattle,98168,

212.58.226.143 GB,P9,Maidenhead,(null),

212.58.226.142 GB,P9,Maidenhead,(null),

212.58.226.139 GB,P9,Maidenhead,(null),

209.66.102.82 US,CA,Berkeley,94709,

209.66.102.50 US,CA,Berkeley,94709,

...

# ./BlockedUniqLocation.sh                                                                                         

222.172.105.109 CN,07,Zhongshan,(null),

217.109.17.57 FR,A8,Paris,(null),

216.34.181.71 US,CA,MountainView,

216.34.181.60 US,CA,MountainView,

216.168.46.76 US,WA,Seattle,98168,

209.66.102.82 US,CA,Berkeley,94709,

209.66.102.50 US,CA,Berkeley,94709,

206.51.224.187 US,FL,Tampa,33602,

204.121.6.51 US,NM,LosAlamos,

203.146.189.74 TH,40,Bangkok,(null),

202.99.11.99 CN,22,Beijing,(null),

202.12.29.13 AU,04,Brisbane,(null),

199.93.55.126 US,(null),(null),(null),

199.43.0.144 US,(null),(null),(null),

199.212.0.43 CA,ON,Toronto,(null),

195.97.20.4 GR,35,Athens,(null),

192.149.252.44 US,(null),(null),(null),

168.75.68.60 US,MA,Andover,01810,

...

LinuxFest Northwest 2009

In honor of LinuxFest Northwest 2009, which I attended at Bellingham Technical College today, I submit a BASH script to parse my Firewall Log. There were great speakers today. I really appreciated PNNL's Gary Smith excellent presentation on his archictecture of sensors that feed PreludeIDS. Seth Schoen delivered an excellent talk on physical security, side-channel attacks , and cold-boot attack vectors. Local consultant Derek Simkowiak delivered a comprehensive presentation on Open Source Virtual Machines.

# Checks NetGear Firewall syslog output or tcpdump -vvveX of syslog port thereof
# This Bash shell script needs full path to log file as its only args
# Apr24213621PDT2009 rferrisx

newdir=`date "+%b%e%H%M%S%Z%Y"`
mkdir $newdir
cd $newdir

echo City: > whois.search
echo descr: >> whois.search
echo NET >> whois.search
echo owner: >> whois.search
echo NetName >> whois.search
echo Copyright >> whois.search

logfile=$BASH_ARGV
grep -A 1 "Severity alert" $logfile | grep "Msg:" > ./attackers.txt
awk -F":" '{ print $4 "," $6 $7 }' ./attackers.txt > ./SipDipPortDesc.txt

SIP=`awk -F"," '{ print $1 }' ./SipDipPortDesc.txt`
DIP=`awk -F"," '{ print $2 }' ./SipDipPortDesc.txt`
PORT=`awk -F" " '{ print $2 }' ./SipDipPortDesc.txt`
DESC=`awk -F" " '{ print $3 "," $4 }' ./SipDipPortDesc.txt`
WHOIS=`for i in $SIP; do whois $i | grep -m 1 -f whois.search;done;`

echo "$SIP" > SIP
echo "$DIP" > DIP
echo "$PORT" > PORT
echo "$DESC" > DESC
echo "$WHOIS" > WHOIS
for i in $SIP;do traceroute -I -d $i;done > ICMPtraceroute.txt

Monitoring home networks with bare bones

Network monitoring and intrusion detection are done at many different levels now: individual computer, home networks, small networks, larger networks, ISP backbones. There are literally network taps, network prefilters, firewalls, contextual search engines and intrusion detection systems, analyzers for every budget and bandwidth. But still, ghostnets happen , even in supposedly secure locations.  Simply put, current attack vectors outfox existing security installations! But without hashing over all the existing technologies, checking out your network at a raw level looks something like this:

Your primitive tools are Cygwin, tcpdump4.0 , Snort, NM 3.3, syslogd, bash shell, pcregrep, a hub, an updated router/firewall, XWindows running on one or more of Linux, OpenBSD, or Windows XP. Your assignment is to redirect the traffic coming to your external router to a "tap" (or in this cheapest case a hub) and monitor it for unwarranted traffic and attempted intrusions.  If you have a reliable hardware firewall, it will output messages of your choosing to a correctly configured syslogd that accepts remote connections:

grep rferris syslog

May  5 01:49:04 192.168.0.1 rferris [61282]:TCP(19590)                 Dest IP :98.247.182.78,         Src IP  :85.13.200.108

May  5 01:49:04 192.168.0.1 rferris [61283]:HTTP(80)                 Dest IP :74.125.127.191,         Src IP  :192.168.0.8

May  5 01:49:04 192.168.0.1 rferris [61284]:TCP(19591)                 Dest IP :98.247.182.78,         Src IP  :74.125.127.191

May  5 01:50:21 192.168.0.1 rferris [61285]:TCP(19591)                 Dest IP :98.247.182.78,         Src IP  :74.125.127.191

May  5 01:50:29 192.168.0.1 rferris [61286]:HTTP(80)                 Dest IP :74.125.127.191,         Src IP  :192.168.0.8

May  5 01:50:29 192.168.0.1 rferris [61287]:TCP(19609)                 Dest IP :98.247.182.78,         Src IP  :74.125.127.191

May  5 01:51:29 192.168.0.1 rferris [61288]:TCP(19609)                 Dest IP :98.247.182.78,         Src IP  :74.125.127.191

May  5 01:52:06 192.168.0.1 rferris [61289]:POP3(110)                 Dest IP :76.96.30.119,         Src IP  :192.168.0.9

May  5 01:52:06 192.168.0.1 rferris [61290]:TCP(20129)                 Dest IP :98.247.182.78,         Src IP  :76.96.30.119

May  5 01:53:06 192.168.0.1 rferris [61291]:TCP(20129)                 Dest IP :98.247.182.78,         Src IP  :76.96.30.119

 grep -i hacker syslog 

May  4 08:22:13 192.168.0.1 rferris Hacker Log[58760]:PROTO_TCP, SIP:61.164.116.52: 6000, DIP:98.247.182.78: 2967, Suspicious TCP Data

May  4 09:08:00 192.168.0.1 rferris Hacker Log[59132]:PROTO_UDP, SIP:84.237.112.4: 1046, DIP:98.247.182.78: 38507, Suspicious UDP Data

May  4 10:23:27 192.168.0.1 rferris Hacker Log[59292]:PROTO_TCP, SIP:123.10.44.80: 2205, DIP:98.247.182.78: 18448, Suspicious TCP Data

May  4 10:32:33 192.168.0.1 rferris Hacker Log[59294]:PROTO_TCP, SIP:121.14.152.130: 6000, DIP:98.247.182.78: 1433, Suspicious TCP Data

May  4 10:44:45 192.168.0.1 rferris Hacker Log[59298]:PROTO_UDP, SIP:173.8.113.195: 3193, DIP:98.247.182.78: 1434, Suspicious UDP Data

May  4 10:47:32 192.168.0.1 rferris Hacker Log[59300]:PROTO_UDP, SIP:93.5.92.78: 1137, DIP:98.247.182.78: 12712, Suspicious UDP Data

But firewalls don't catch and catalog all the packets, So you will need to filter and trap them, perhaps with  tcpdump  set of filters like so:

/usr/local/sbin/tcpdump -ntttvvveXX -i xl0 -s 65535 host [your leased IP] and not arp or icmp or igmp and 'port not (bootpc or domain or pop3 or whois or http or https)' and  'host not (wf-in-f125.google.com or cns.beaverton.or.bverton.comcast.net or 73.98.100.1)' >> `date "+%b%e%H%M%S%Z%Y"`

And after you have captured your filtered traffic, you may need more filtering to extract a list of IPs:

grep seq May\ 3115119PDT2009 | grep -v -f file | awk -F ">" '{print $1}' | more

$ more file

DHCP

ICMP

POP3

DIP

Thus we have a literal boom in the network security business to make this type of data collection easier, more intuitive, more suitable for today's level of traffic: taps, filters, IDS/IPS devices, filtering Firewalls with IDS functionality, protocol analyzers, etc.  But at some point first before you deploy any of this, you are going to want to break ground and sit and watch traffic, so you viscerally understand the threats, attack vectors, sniffers and firewalls

Parsing Vista Firewall: Part IV

Microsoft's logparser.exe use sql query syntax to parse many different log formats.  Vista's firewall most reasonably resembles at TSV log file format. However, it takes some work with logparser.exe to get the correct parameters as below.  The third or 'header' line row needs  the words "#Fields" removed from the file for accurate field recognition.

LogParser "SELECT * FROM 'pfirewall.log' WHERE ( action = 'ALLOW' AND protocol = 'UDP' AND path = 'RECEIVE' AND src-ip <> '127.0.0.1' ) " -i:TSV -iSeparator:spaces -fixedSep:OFF -nSkipLines:3

Filename RowNumber date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
--------------------------------------------------- --------- ---------- -------- ------ -------- --------------- --------------- -------- -------- ---- -------- ------ ------ ------ -------- -------- ---- -------
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 7105 2009-07-11 19:56:59 ALLOW UDP 192.168.0.4 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 7107 2009-07-11 19:56:59 ALLOW UDP 169.254.172.113 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 8046 2009-07-11 21:56:36 ALLOW UDP 192.168.0.4 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 8047 2009-07-11 21:56:36 ALLOW UDP 169.254.172.113 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 8316 2009-07-11 22:03:29 ALLOW UDP 169.254.172.113 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 8353 2009-07-11 22:06:18 ALLOW UDP 192.168.0.4 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 8355 2009-07-11 22:06:18 ALLOW UDP 169.254.172.113 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
....

Advanced Persistent Threat

The news on  "Advanced Persistent Threat" has been broken in a big way by Google and the recent Mandiant report.  More comments will follow at a later date.  But some occur to me now:

(1) Our current desktop and server Operating Systems are not secure.
(2) Computer networks are insecure for most organizations and at many levels.
(3) Digital data can no longer be protected against a determined foe.
(4) Security researchers and visionaries should receive more funding. Lots.

Order and read the Mandiant Report. Then imagine what a resourced foe could do if they believed the security of their nation-state depended upon seemless corporate intrusions.  Now imagine those techniques automated and in the wild.  In order for the world to have safe computing systems, our government and industry needs to sponsor more research and decriminalize vulnerability research. Otherwise, no data will ever be secret or protected again.

Host Protection: Working with Microsoft's Firewall

Both network and host protection are recommended. Each OS has native firewall host protection:

OpenBSD: pf

FreeBSD: pfsense

Fedora Cora: iptables with SELinux

Windows XP,2003,2008,Vista,7 : Windows Firewall (ICF)

Microsoft's native firewall on XP SP3 can be told to log all incoming and outgoing packets up to a maximum log size of 32676 bytes(2^15). It will turn over twice before rewriting the old log file name.  A full examination of the Firewall's configuration is beyond the scope of this post.  A regedt32 query of StandardProfiles and DomainProfiles for all Control Sets for all globally open ports and authorized applications is recommended as is a manual exploration of the appropriate regedt32 keys. (Netsh commands are available for all Firewalled Windows. Please see http://support.microsoft.com/kb/947709 . Powershell can also be used to configure Microsoft's Firewall. ):   

regquery HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List | findstr Enabled

A sample partial result would be: 

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

    139:TCP     REG_SZ  139:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22004

    445:TCP     REG_SZ  445:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22005

    137:UDP     REG_SZ  137:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22001

    138:UDP     REG_SZ  138:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22002

    53:UDP      REG_SZ  53:UDP:LocalSubNet:Enabled:DNS-UDP

    53:TCP      REG_SZ  53:TCP:LocalSubNet:Enabled:DNS

    500:UDP     REG_SZ  500:UDP:*:Enabled:@xpsp2res.dll,-22017

The pfirewall.log gives a considerable amount of information as such:

more pfirewall.log

#Version: 1.5

#Software: Microsoft Windows Firewall

#Time Format: Local

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2009-04-23 10:24:55 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:56 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 138 138 202 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 78 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

....

Using Cygwin's Bash client and gawk, a list of src and dst ports can be obtained: 

cat /cygdrive/D/pfirewall.log | awk -F" " '{print $7}' | sort -nr | uniq -c | sort -nr | more

cat /cygdrive/D/pfirewall.log | awk -F" " '{print $8}' | sort -nr | uniq -c | sort -nr | more

Gawk's conditional logic coupled with pcregrep quick searching helps us print the frequency of a destination IP and accompanying port(s) for a specified source IP:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | sort -nr | more

  16138 192.168.0.1:53

    902 192.168.0.1:80

    446 74.125.242.24:80

    359 65.214.57.165:80

    304 216.73.87.115:80

    272 85.13.200.108:110

    247 70.32.92.85:80

    240 216.73.87.152:80

    215 75.101.163.8:80

    208 68.142.93.133:80

    203 74.125.127.191:80

    201 128.111.41.37:80

....

Now we choose to sort by the frequency of one specific dst port for each dst IP from the specified (local) source IP:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | pcregrep ':443' | sort -nr

    113 74.125.53.147:443

     92 74.125.53.83:443

     78 208.235.248.150:443

     50 208.75.76.32:443

     46 74.125.127.103:443

     30 74.125.53.97:443

     24 74.125.127.120:443

     23 65.55.157.60:443

     22 96.6.248.124:443

     21 74.125.53.99:443

...

For example, I was surprised to find all the foreign addresses that my local computer asked NBNS queries of: 

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | pcregrep ':137' | sort -nr

  42 192.168.0.4:137

  39 192.168.0.6:137

  36 192.168.0.2:137

  16 192.168.0.9:137

  15 206.51.224.187:137

  14 208.117.252.85:137

  14 192.168.0.1:137

  13 206.72.124.93:137

  11 74.125.103.33:137

  10 64.94.107.20:137

  10 64.236.79.54:137

  10 206.191.161.8:137

...

The dates and times of those queries could be found with: 

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $1 ":" $4 ":" $6 ":" $8}' | pcregrep ':137' | sort -nr | more

2009-05-14:UDP:192.168.0.4:137

2009-05-14:UDP:192.168.0.4:137

2009-05-06:UDP:75.52.124.131:137

2009-05-06:UDP:74.125.103.28:137

2009-05-06:UDP:69.64.6.21:137

2009-05-06:UDP:66.35.45.202:137

2009-05-06:UDP:66.35.45.202:137

2009-05-06:UDP:66.35.45.202:137

2009-05-06:UDP:66.35.45.201:137

2009-05-06:UDP:66.35.45.201:137

2009-05-06:UDP:66.35.45.201:137

2009-05-06:UDP:65.55.52.84:137

2009-05-06:UDP:65.55.52.148:137

2009-05-06:UDP:65.55.185.61:137

2009-05-06:UDP:65.55.185.29:137

2009-05-06:UDP:65.55.184.189:137

2009-05-06:UDP:65.173.218.69:137

2009-05-06:UDP:65.173.218.69:137

2009-05-06:UDP:64.94.107.16:137

2009-05-06:UDP:64.236.115.52:137

2009-05-06:UDP:4.71.104.187:137

....

These two commands are also recommended:

C:\WINDOWS\system32\drivers\etc>net config server

C:\WINDOWS\system32\drivers\etc>net config workstation