Securing Digital Content: Part I

I will post no code for this blog entry so that I can answer the question of a friend of mine :  How does a normal person take reasonable steps to safeguard sensitive digital content in this day of repeated sophisticated instrusions, penetrations, institutionalized hacking and institutionalized snooping? This is a long subject that would require more than just one blog entry. Here are some (random or not) thoughts: 

Part I Strategies
 I would answer the strategy for maintaining content security like this:
(1) Assume data loss or data theft. Develop a strategy not just to defend against data loss/theft but to recover from it.
(2) Understand the "big" picture. Take some time to understand just how insecure digital data now is for all of us, including journalists, businesses, corporations, nation-states. Read James Bamford's "The Shadow Government" or Misha Glennys "McMafia"
(3) Have a reasonable picture of your enemies and how determined they would be to find your content or stop you from owning it.
(4) Remember the famous (and ancient) network adminstrators maxim: "There are only two kinds of computer users: Those who have lost data and those who will." Always back-up your work. Always work with a net.
(5) Lower your "personal attack surface". Two separate strategies come to mind:
 (a) Confuse possible threats through secrecy, security, iconoclastic behavior, obfuscation and misdirection. (e.g. Keep a 'cover' or 'alibi' or 'grey' lifestyle, own many small computers, own multiple phones but don't always carry them, take public transport to busy malls to work, cultivate unpredictable behavior patterns etc. )
 (b) Become involved and well-known in your community and tribe: develop friends, watchers, and confidants. Keep a respected public content profile on a Blog. Attend your block watch, neighborhood meetings, have your neighbors over for dinner etc.
These two strategies may be more compatible than apparent...
(6) If something feels wrong to you, it probably is. If you don't feel like filling out some Facebook survey that asks for the "top twenty things people don't know about you" your life may well be more secure. Hackers often make up password lists of details from peoples personal lives.  Ask your medical professional exactly why he needs your Social Security number on that form. Despite recent HIPPA laws, medical information is notoriously insecure. The list goes on: too personal strangers, tele-funders from not well-known organizations asking for your credit card numbers.  Limit the leakage of critical personal information. Often, no one else needs to know. Resist the urge to converse too personal details to strangers.
(7) Don't underestimate the threats. But don't spend too much time worrying about them either. It is well-known that successful personal security always involves intuition and spontaneity. Both are dimmed by too much concern.
  
Part II Safe Computing Practices
As for generally accepted computing security practices, if I had to protect sensitive content I would:
(1) read any number of sites that give excellent recommendations on "safe computing practices" from the NSA to FBI to CERT to SANS to SLATE and USE THEM.
(2) understand my firewall, anti-virus, security templates and encryption suites well and USE THEM.
(3) understand my Operating System/Application suite really well. Monitor Operating System/Application security flaws and update as prescribed.
(4) review my firewall, syslog, eventviewer, anti-virus, and web logs every week and attempt to profile both my audience and possible threats from collating all log information.
(5) use product vendors I believe in for my OS, Applications, firewall, AV, encryption suites. Consider using "open-source" platforms and applications whose code is well-reviewed.
(6) if possible or practical, I would store a non-digital copy of protected content in multiple safe locations to protect from disaster.
(7) not keep secure information or sensitive content in your e-mail. Most e-mail is exchanged in 'clear text' across the wire. Most e-mail stores are not kept in 'data vaults' although some e-mail software will offer you this option.
(8) try to remember that data-loss is multi-faceted and often physical in nature. More data may be lost from stolen laptops in America than through network intrusions: Buy a vault and USE IT. Buy multiple deadbolts and USE THEM. Be careful with your laptops and portable drives when you are in a crowd or public place. (See Part IV, suggestion (2) below.)

True Story: I once heard a friend of mine discuss how the local PD called upon to help him break the encryption on a drive of an uncommon real-time UNIX OS that belonged to a narcotics trafficker.
The dealer had gone to some lengths to use a rare OS with encryption of which few people would have technical experience. But once the local PD had physical control of the box...game over....

Part III More Computer Security Practices
Some more computer security suggestions for content protection:
(1) Receive e-mail in plain text always. Consider sending digitally signed e-mail. 
(2) Encrypt your laptop and hard drives with third party encryption.
(3) Understand file and logon security for your Operating System and deploy and use them.
(4) Deploy host and network firewalls and a honeypot. Consider firewalling different segment of your network. Lately, I like the concept of these new UTM (Unified Threat Modeling) firewalls from NetGear and other vendors...
(5) Learn to sniff and review traffic everywhere you go. There's something satisfying about actually reviewing network traffic as you work on the network. Something like surveying the crowd on the street you are walking on...
(6) Consider carrying a small portable hardware firewall for your laptop.
(7) Get in the practice of quickly reformatting an up to date version of your OS if you feel the least bit quesy about your OS behavior. [This tip implies an excellent data back-up habit and some patience with OS installation.].
(8) Wireless is still a risk, especially if unencrypted. If you use it, use a VPN or encryption for sensitive communication and the highest strength encryption you can afford. Beware of "rogue" public hot spots that steal information.
(9) Use OpenSSH for your network communication as much as possible, especially across networks you don't control or own.
(10) Get in the habit of using 21 character plus passwords and changing them often. Yes, you can.
(11) Regardless of whether you run Windows or UNIX, don't take unneccesary sharing or open port or remote administration risks. 'Lock down' the most expensive version of Windows you can afford (e.g. Vista Ultimate). 
[Note: Securing Windows or UNIX requires some effort and thought and training. The use of a consultant may be advisable.]

Part IV Offbeat Ideas?
On the "inventive" or "offbeat" side, if I had to protect sensitive content I might:
(1) Store everything on an old, cheap OpenBSD box that never touches the internet. Run only OpenBSD approved packages.
(2) Buy a Nokia 810, and install and configure iptables. Use it to Skype with your friends off some random wireless connection instead using a cell-phone. Carry it in your jacket pocket and use it instead of a laptop.
(3) Use an iconoclastic Linux distro designed for security - 'Back-Trax' comes to mind...
(4) Surf and collect e-mail on a thumb drive from a bootable Linux distro. Then boot back into an OpenBSD, Linux, Debian,Ubuntu laptop that has no networking at all for your "protected content".
(5) Or you could do the converse: Surf on your hard drive box, boot into a Linux DVD distro, mount a "secure" thumb drive or SD drive for storing sensitive content.
(6) Keep two sets of content: One that can be "found" by your enemies (after some work) and one that is "hidden".  For example,thumb-drives are easy to purchase, back up, and/or store on your person. You could leave decoys lying around with "disinformative content" for when the spooks do a "sneak and peek" at your apartment.
(7) Set up a surveillance system around your home.
(8) Teach yourself to hack and spy. Nothing will make you more paranoid and careful than knowing the "arts of the enemy". Actually, nothing will intimidate your enemies more than aggressive "back-tracking" of their hacking and spying attempts. 
(9) Live in the most populous neighborhood you can stand. San Francisco's China Town comes to mind. It's hard to follow one person consistently in a crowd.
(10) Publish some of your most problematic secret content on a blog, similar to what the Electronic Freedom Foundation does every month. Nothing makes sensitive content less so than publicity. Sometimes, nothing makes a holding a secret less dangerous than sharing it. 

AND THE NUMBER ONE WAY TO PROTECT SENSITIVE CONTENT IS...
[Live without any. Wasn't life simpler without computers? :-)] 

Parsing Vista Firewalls: Part V

When combined with cmd.exe you can populate a logparser query file with cmd.exe variables. The datagrid output of log parser allows for "pretty". The chart output requires a licensed copy of MS Chart output dll.  A little knowledge of SQL takes you quite a long way with Log Parser.

:: must delete "#Fields" from pfirewall.log first for correct field parsing.
@echo off
set field=%1
set filename=%2
echo SELECT %field%, COUNT(*) > OrderByFieldGroupByCount.sql
echo FROM 'C:\Windows\System32\LogFiles\Firewall\%filename%' >> OrderByFieldGroupByCount.sql
echo GROUP BY %field% >> OrderByFieldGroupByCount.sql
echo ORDER BY COUNT(*) DESC >> OrderByFieldGroupByCount.sql
"C:\Program Files (x86)\Log Parser 2.2\LogParser.exe" -i:TSV file:OrderByFieldGroupByCount.sql -q:on -iSeparator:spaces -fixedSep:OFF -nSkipLines:3 -o:datagrid

:: must delete "#Fields" from pfirewall.log first for correct field parsing.
@echo off
set field1=%1
set field2=%2
set filename=%3
echo SELECT %field1% , %field2% , COUNT(*) > OrderByFieldGroupByCount.sql
echo FROM 'C:\Windows\System32\LogFiles\Firewall\%filename%' >> OrderByFieldGroupByCount.sql
echo GROUP BY %field1% , %field2% >> OrderByFieldGroupByCount.sql
echo ORDER BY COUNT(*) DESC >> OrderByFieldGroupByCount.sql
"C:\Program Files (x86)\Log Parser 2.2\LogParser.exe" -i:TSV file:OrderByFieldGroupByCount.sql -q:on -iSeparator:spaces -fixedSep:OFF -nSkipLines:3 -o:datagrid

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
....

Parsing Vista Firewall Logs: Part III

For speed, control, and simplicity, gawk is almost impossible to beat in parsing simple text logs like pfirewall.log. The script below will give you a numerically sorted list by count of the references to Src IPs in pfirewall.log for allowed packets. These sorts give a count (first column) of the unique IPs in numerical order. Note that gawk makes quick work of this searches.

gawk '$3 == "ALLOW" {print $5}' pfirewall.log | sort -nr | uniq -c | sort -nr 

  6849 192.168.0.4
  4317 127.0.0.1
  3014 192.168.200.87
  1577 10.10.10.74
  725 192.168.168.246
  680 172.17.5.143
  595 fe80::9536:4516:f99:3705
  557 ::1
  350 fe80::645d:d71d:f845:ac71
  265 192.168.150.10
  261 169.254.172.113
  214 0.0.0.0
  122 10.10.10.82
  107 85.13.200.108
...

Now we add the Src IP ports:

gawk '$3 == "ALLOW" {print $5" "$7}' pfirewall.log | sort -nr | uniq -c | sort -nr 

  1609 127.0.0.1 58915
  1341 127.0.0.1 58912
  214 0.0.0.0 68
  132 fe80::9536:4516:f99:3705 -
  128 192.168.0.4 137
  116 fe80::645d:d71d:f845:ac71 -
  107 85.13.200.108 20
  106 ::1 -
  106 127.0.0.1 -
  96 127.0.0.1 52845
  76 fe80::ffff:ffff:fffe -
  73 127.0.0.1 53249
  72 169.254.172.113 137  
....

Now we add the DestIP and Dest Ports:

gawk '$3 == "ALLOW" {print $5" "$6" "$8}' pfirewall.log | sort -nr | uniq -c | sort -nr

  1609 127.0.0.1 127.0.0.1 58915
  1364 192.168.0.4 192.168.0.1 53
  1341 127.0.0.1 127.0.0.1 58912
  720 192.168.0.4 208.113.141.123 80
  668 127.0.0.1 239.255.255.250 1900
  661 192.168.200.87 192.168.200.1 53
  461 fe80::9536:4516:f99:3705 ff02::1:3 5355
  389 10.10.10.74 10.10.10.1 53
  379 192.168.0.4 192.168.0.245 80
  235 192.168.0.4 69.63.176.175 80
  233 fe80::645d:d71d:f845:ac71 ff02::1:3 5355
  214 0.0.0.0 255.255.255.255 67
  172 192.168.0.4 224.0.0.252 5355
....

Now we sort SrcIP, DestIP, DestPort by uniq IP:

gawk '$3 == "ALLOW" {print $5" "$6" "$8}' pfirewall.log | sort -k 1,3 | uniq -c 

  214 0.0.0.0 255.255.255.255 67
  25 10.0.0.4 10.0.0.255 137
  7 10.0.0.4 224.0.0.22 -
  1 10.0.0.4 224.0.0.252 137
  63 10.0.0.4 224.0.0.252 5355
  1 10.0.0.4 239.255.255.250 3702
  1 10.10.10.10 224.0.0.1 -
  1 10.10.10.74 10.10.10.1 137
  13 10.10.10.74 10.10.10.1 2060
  389 10.10.10.74 10.10.10.1 53
  1 10.10.10.74 10.10.10.1 67
  19 10.10.10.74 10.10.10.255 137
  2 10.10.10.74 12.129.210.71 80
  2 10.10.10.74 12.129.210.76 80
...

As above, but now sorted by count of Uniq IP:

gawk '$3 == "ALLOW" {print $5" "$6" "$8}' pfirewall.log | sort -k 1,3 | uniq -c | sort -nr

  1609 127.0.0.1 127.0.0.1 58915
  1364 192.168.0.4 192.168.0.1 53
  1341 127.0.0.1 127.0.0.1 58912
  720 192.168.0.4 208.113.141.123 80
  664 127.0.0.1 239.255.255.250 1900
  661 192.168.200.87 192.168.200.1 53
  461 fe80::9536:4516:f99:3705 ff02::1:3 5355
  389 10.10.10.74 10.10.10.1 53
  379 192.168.0.4 192.168.0.245 80
  235 192.168.0.4 69.63.176.175 80
  233 fe80::645d:d71d:f845:ac71 ff02::1:3 5355
  214 0.0.0.0 255.255.255.255 67
  172 192.168.0.4 224.0.0.252 5355
  167 169.254.172.113 224.0.0.252 5355
  154 172.17.5.143 172.17.5.1 53
  147 192.168.0.4 207.115.66.86 80
  140 192.168.150.10 192.168.150.1 53
  136 192.168.200.87 206.223.158.41 443
...

Parsing Vista Firewall Logs Part II

Made an interesting attempt today to parse Vista's Firewall log based on some "Scripting Guys" code from Microsoft: http://www.microsoft.com/technet/scriptcenter/resources/qanda/apr09/hey0416.mspx. I have placed the script here: http://www.rmfdevelopment.com/PowerShell_Scripts/Scan-Firewall.ps1

Regexing per line of pfirewall.log with mixed IPv4 and IPv6 address types as well as ICMP and other layer 2 protocols makes identifying network services by port unreliable without tokenizing the position of dst/src ports first. Thus the regex switch "\s80" will catch web browsing by any local user and "http tunnelling" attempts by any hijacker. Whether or not services correspond to port numbers is a matter of configuration.  For example, an alternative web server port is often 8000 as opposed to 80. Regex statistics for [un]cataloged ports may add up to more or less than 100% because of duplicate src/dst ports and/or uncataloged port numbers or alternative network service ports or other pfirewall.log anomalies. Standards based locations for well-known ports exists in the services file of most Operating Systems. On Vista: "C:\Windows\System32\drivers\etc\services". You can use this file to add services to the 'switch -regex' Function and $hash hashtable in the script.

PS C:\PS1> .\Scan-Firewall.ps1

Global SFLGS_Array:

Name Value
---- -----
ssh
ftp
telnet
pop3 3
ntp 4
nbsession 7
microsoftds 43
icmp 643
dhcpc 692.020425632398
ssl 936
ssdp 1223
nbdatagram 3542
llmnr 5440
web 8077
tcp 9222
dns 9417
nbname 12021
PacketAllow 19673
PacketDrop 19999
udp 29576
.
Summary Statistics Layer 2/3 Protocols
.
Total Packets = 39672
Percent Packets Allowed = 0.495891308731599
Percent Packets Dropped = 0.504108691268401
Percent TCP = 0.232456140350877
Percent UDP = 0.745513208308127
Percent ICMP = 0.0162079048195201
Count other Packets = 231
% Other Layer 2/3 Protocols = 0.005822747
.
Summary Statistics IP Application Protocols Per Port
.
Port 67 Percent DHCPC packets = 0.0174435477322141
Port 80 Percent WEB packets = 0.203594474692478
Port 110 Percent POP3 packets = 7.56200846944949E-05
Port 123 Percent NTP packets = 0.00010082677959266
Port 137 Percent NBNAME packets = 0.303009679370841
Port 138 Percent NBDATAGRAM packets = 0.0892821133293003
Port 139 Percent NBSESSION packets = 0.000176446864287155
Port 443 Percent SSL packets = 0.0235934664246824
Port 445 Percent Microsoft DS packets = 0.00108388788062109
Port 1900 Percent SSDP packets = 0.0308277878604557
Port 5355 Percent LLMNR packets = 0.137124420246017
Percent Cataloged Ports = 0.8062366
Percent Uncataloged Ports = 0.1937634

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

....

No tail.exe on Vista HP....

Vista's decision to ship without a native tail.exe makes monitoring logs difficult without GNUWin32 or Cygwin or some other third party utility. This batch (tail.cmd) helps:

@echo off

set file = %1

:top

choice /T 1 /D Y > NUL

for /f "eol=: tokens=3" %%i in ('find ^/C " " %1') do set lastline=%%i

set /a newlastline=%lastline% - 1

set oldlastline=%newlastline%

:top1

choice /T 1 /D Y > NUL

for /f "eol=: tokens=3" %%i in ('find ^/C " " %1') do set lastline=%%i

set /a newlastline=%lastline% - 1

if %oldlastline%==%newlastline% (goto top1) else more +%newlastline% %1 && goto top

[output]:

C:\Windows\System32\LogFiles\Firewall>tail pfirewall.log

2009-07-21 14:53:25 DROP UDP 192.168.0.10 192.168.0.255 138 138 229 - - - - - - - RECEIVE

2009-07-21 14:54:43 ALLOW UDP 10.0.0.2 10.0.0.255 138 138 0 - - - - - - - SEND

2009-07-21 14:57:16 DROP UDP 192.168.0.11 192.168.0.1 54103 53 0 - - - - - - - SEND

2009-07-21 14:57:18 DROP UDP 192.168.0.11 192.168.0.1 54103 53 0 - - - - - - - SEND

2009-07-21 14:57:30 ALLOW ICMP 192.168.0.11 192.168.0.1 - - 0 - - - - 8 0 - SEND

2009-07-21 14:57:31 ALLOW ICMP 192.168.0.11 192.168.0.1 - - 0 - - - - 8 0 - SEND

2009-07-21 14:57:37 ALLOW ICMP 192.168.0.11 192.168.0.245 - - 0 - - - - 8 0 - SEND

2009-07-21 14:57:38 ALLOW ICMP 192.168.0.11 192.168.0.245 - - 0 - - - - 8 0 - SEND

2009-07-21 14:58:17 ALLOW UDP fe80::11f2:abb3:cf0b:58d8 ff02::1:3 63249 5355 0 - - - - - - - SEND

2009-07-21 14:58:17 ALLOW UDP 10.0.0.2 224.0.0.252 59011 5355 0 - - - - - - - SEND

"The Cloud" exists already....

For anyone who runs a Windows PC, the vaunted "cloud computing" environment already exists. Without most of us realizing it, large collections of computer systems - CDNs, botnets, grid-enabled NOCs, hosting centers, etc. already provide the type of computing power environments that connect our PCs to a world of search engines/databases/upgrades/virus signatures from many vendors. When my Vista boots it proceeds immediately to find out who feeds it daily medicine and then proceeds to tell the world what state it is in:

Vista and XP Network Interfaces with Powershell

In preparation for examing the differences between XP and Vista firewalls, I wrote this interesting Powershell CTP2.0 v3 script that exposes info for all physical and virtual network interfaces. More information is available on Vista than XP. This script will work on both. Each paragraph is a separate script.

.\Get-NetworkInterface.ps1

$Global:gwmiw32na = get-wmiobject win32_networkadapter

$gwmiw32na | fl *

$Global:gwmiw32na4 = get-wmiobject win32_networkadapter | Select Name,ServiceName,Speed,PhysicalAdapter

$Global:gwmiw32na6 = get-wmiobject win32_networkadapter | Select Name,PhysicalAdapter,MACAddress,Manufacturer,NetConnectionID

$gwmiw32na4 | ft -auto

$gwmiw32na6 | ft -auto

$gwmiw32na = get-wmiobject win32_networkadapter

$gwmiw32na | ? {$_.PhysicalAdapter} |Select Name,MACAddress,GUID,Description,Manufacturer,NetConnectionID,NetConnectionStatus

$gwmiw32na | ? {$_.PhysicalAdapter}

$adapter = Get-WmiObject win32_networkadapter

$adapter_count = $adapter.count

$adapter_range = ($adapter.count + 1)

write "Adapter Range= $adapter_range; Adapter Count= $adapter_count"

write .

write "Adapter Table:"

$AdapterNameID = $adapter | Select Name,DeviceID

$AdapterNameID

Understanding Svchost Part II

I have published a brief papers on svchost.exe: Svchost:To Whom and Why . It explains how to use a Mark Russinovich (Microsoft: www.Sysinternals.com) tool set to understand svchost.exe behavior. Microsoft uses Limelight Networks (among other 'CDNs') to help them distribute update content. What I do not like about this is that when you enable Microsoft update you do not explicitly give Microsoft permission to use a third party CDN to send and receive data from your PC. But that is exactly what happens in the world of Edge Networks, 'CDNs', 'Software Ecosystems' and 'Cloud computing'. Data from my computer is sent elsewhere without my permission to network locations that are not local to the Pacific Northwest or necessarily controlled by the software vendor of which I have service level agreements.

Understanding Svchost

Some relatively simple code helps us understand svchost processes. You will need a large screen to display the output:

$global:svchost = get-wmiObject win32_process -filter "name='svchost.exe'"

$global:win32_handle = $svchost | foreach { gwmi -query "Select * from win32_service where processID = $($_.handle)" }

$global:Sort_handle = $win32_handle | sort processID, Name

$global:Sort_svchost = $svchost | sort processID

$Sort_handle | format-table processID,name,state, startmode,Started,AcceptStop,Description -AutoSize

$Sort_svchost | format-table ProcessID,ThreadCount,HandleCount,WS,VM,KernelModeTime,ReadOperationCount,ReadTransferCount,OtherTransferCount -Autosize

[Output]:

:.\Get-SvcHost_005.ps1

processID name state startmode Started AcceptStop Description

--------- ---- ----- --------- ------- ---------- -----------

840 SSDPSRV Running Manual True True Enables discovery of UPnP devices on your home network.

1168 stisvc Running Auto True True Provides image acquisition services for scanners and cameras.

1204 DcomLaunch Running Auto True False Provides launch functionality for DCOM services.

1292 RpcSs Running Auto True False Provides the endpoint mapper and other miscellaneous RPC services.

.....

ProcessID ThreadCount HandleCount WS VM KernelModeTime ReadOperationCount ReadTransferCount OtherTransferCount

--------- ----------- ----------- -- -- -------------- ------------------ ----------------- ------------------

840 9 236 6078464 39940096 468750 369 48936 129130

1168 5 210 6574080 41291776 11093750 438 53831 32770

1204 5 209 6381568 43548672 3125000 383 53947 330048

1292 10 457 7004160 45506560 24375000 506 465380 63666

.....

Conflict and Confusion

For years, I didn't run DEP, Anti-Virus or other behavioral blocking software because I believed the hit on machine performance simply wasn't worth it. Additionally, I found most "protective software" bulky and and inelegant. Some noticeable exceptions were BlackICE (now defunct) and a PC host firewall now owned by CheckPoint. To rid myself of Viruses occassionally, I would use TrendMicro's housecall. In any event, after some years struggling to find a decent mail client that protected me from virus ridden junk mail...So recently I have installed two AV softwares and DEP. Sophos was working until I opened my mail box and tried to clean some junk mail. Very soon after, Sophos stopped working. I then installed PC Tools which found me riddled with adware,viruses and Trojans. Now neither is working quite right. I am unsure at this point if the problem is DEP or whether the AV software has become infected intself. The desktop disaster looks something like:

Too Much, Too Fast...Part II

Above and far below might be the type of topology or map you may want to look at if you had a million or so Conficker machines and you were considering where to store your next payload so that it would remain:

(1) well-hidden

(2) ever-present

The first column (also the X axis above) is the count of the number of times this particular memory size is stored on my machine. The second column (in KB and Y axis above) is the memory size itself. The last print column are those Windows modules at that particular size. This is the type of topology that would help lay out the battlefield for the Botnet Generals. It would help answer questions like:

(1) Where should/could our armies live?

(2) How much space or resources will we have for them?

(3) Who will house them? What dll will be called the most frequently with what access?

Any administrative access to Win 7 or Win2008 would have Powershell/WinRM waiting to be configured. Thus this type of surveillance of Windows desktop could be done on a very large scale quickly and dynamically. And the analysis could be granular: per region, per industry, per subnet, etc.

[Powershell]

$Global:ps = ps

$ps_count = $ps.count

write "Process Count = $ps_count"

$Global:all_modules = 0..$ps_count |%{$ps[$_].Modules} | Select Size,ModuleName,FileName,FileVersion

$Global:all_modules_memory = $all_modules | Select -property ModuleName,Size | Sort -property Size

$all_modules_memory | sort -Descending -property Size | group -property Size

[partial dump]:

....

63 712 {@{ModuleName=ntdll.dll; Size=712}, @{ModuleName=ntdll.dll; Size=712}, @{ModuleName=ntdll.dll; Size=712}, @{ModuleName=ntdll.dll; Size=712}

13 704 {@{ModuleName=SXS.DLL; Size=704}, @{ModuleName=SXS.DLL; Size=704}, @{ModuleName=SXS.DLL; Size=704}, @{ModuleName=SXS.DLL; Size=704}...}

1 680 {@{ModuleName=xpsp3res.dll; Size=680}}

1 676 {@{ModuleName=TzShell.dll; Size=676}}

1 672 {@{ModuleName=swg.dll; Size=672}}

2 656 {@{ModuleName=RASDLG.dll; Size=656}, @{ModuleName=localedata_others.dll; Size=656}}

3 652 {@{ModuleName=MSVCR90.dll; Size=652}, @{ModuleName=MSVCR90.dll; Size=652}, @{ModuleName=MSVCR90.dll; Size=652}}

2 644 {@{ModuleName=chartmodelmi.dll; Size=644}, @{ModuleName=Microsoft.PowerShell.ConsoleHost.ni.dll; Size=644}}

1 636 {@{ModuleName=SavNeutralRes.dll; Size=636}}

1 632 {@{ModuleName=localedata_euro.dll; Size=632}}

1 624 {@{ModuleName=System.Transactions.ni.dll; Size=624}}

67 620 {@{ModuleName=ADVAPI32.dll; Size=620}, @{ModuleName=MSVCR80.dll; Size=620}, @{ModuleName=ADVAPI32.dll; Size=620}, @{ModuleName=ADVAPI32.dll

30 616 {@{ModuleName=comctl32.dll; Size=616}, @{ModuleName=comctl32.dll; Size=616}, @{ModuleName=comctl32.dll; Size=616}, @{ModuleName=comctl32.dl

2 604 {@{ModuleName=stlport_vc7145.dll; Size=604}, @{ModuleName=stlport_vc7145.dll; Size=604}}

21 596 {@{ModuleName=CRYPT32.dll; Size=596}, @{ModuleName=CRYPT32.dll; Size=596}, @{ModuleName=CRYPT32.dll; Size=596}, @{ModuleName=CRYPT32.dll; S

63 584 {@{ModuleName=RPCRT4.dll; Size=584}, @{ModuleName=RPCRT4.dll; Size=584}, @{ModuleName=RPCRT4.dll; Size=584}, @{ModuleName=RPCRT4.dll; Size=

63 580 {@{ModuleName=USER32.dll; Size=580}, @{ModuleName=USER32.dll; Size=580}, @{ModuleName=USER32.dll; Size=580}, @{ModuleName=USER32.dll; Size=

1 576 {@{ModuleName=QuickTimeMPEG4Authoring.qtx; Size=576}}

1 572 {@{ModuleName=QuickTimeEffects.qtx; Size=572}}

1 564 {@{ModuleName=diasymreader.dll; Size=564}}

2 560 {@{ModuleName=wzcsvc.dll; Size=560}, @{ModuleName=printui.dll; Size=560}}

46 556 {@{ModuleName=OLEAUT32.dll; Size=556}, @{ModuleName=OLEAUT32.dll; Size=556}, @{ModuleName=OLEAUT32.dll; Size=556}, @{ModuleName=OLEAUT32.dl

3 544 {@{ModuleName=shdoclc.dll; Size=544}, @{ModuleName=libdb42.dll; Size=544}, @{ModuleName=shdoclc.dll; Size=544}}

1 532 {@{ModuleName=wbemcore.dll; Size=532}}

2 528 {@{ModuleName=xcrmi.dll; Size=528}, @{ModuleName=dopdfui5.dll; Size=528}}

1 520 {@{ModuleName=HPQTOA~1.EXE; Size=520}}

2 516 {@{ModuleName=evtsys.exe; Size=516}, @{ModuleName=winlogon.exe; Size=516}}

4 512 {@{ModuleName=tlmi.dll; Size=512}, @{ModuleName=CRYPTUI.dll; Size=512}, @{ModuleName=CRYPTUI.dll; Size=512}, @{ModuleName=CRYPTUI.dll; Size

31 508 {@{ModuleName=CLBCATQ.DLL; Size=508}, @{ModuleName=CLBCATQ.DLL; Size=508}, @{ModuleName=CLBCATQ.DLL; Size=508}, @{ModuleName=CLBCATQ.DLL; S

....

Too Much, Too Fast

At some point, the software industry will have to come to terms with the fact that it grew too fast, created too many rapid application development vehicles and expanded code into Operating Systems that just cannot fundamentally withstand concerted attacks from hackers, organized crime, nation state terrrorists, etc. Ultimately, the best defense against intrusion, worms, buffer overflow attempts, etc will be to 'native sentinel' programs that can 'electric fence' every loaded feed, hook, interface, binary,library against suspicious behavior. Current processor memory/development may allow for such sentries. Indeed 'DEP' (Data Execution Protection) could be termed a 'native sentinel' program. However, in many ways there is just too much going on inside a modern OS to be well-protected.This is some Powershell output from my Windows laptop. Notice:

(1) How may modules are (2701) in use by a limited number of applications (64) and

(2) How many modules (515 unique out of 2701 total) are being shared in multiple applications

$ps = ps

$count = $ps.count

$count

64

$all_modules = 0..$count |%{$ps[$_].Modules} | Select BaseAddress,EntryPointAddress,Size,ModuleName,ModuleMemorySize,GetLifetimeService,FileName,FileVersion,Company,Description

$all_modules.count

2701

$unique_all_modules = $all_modules | Select -property ModuleName | Sort -Unique -property ModuleName

$unique_all_modules.count

515

We have a similar situation with Linux (no XWin running here), although notice the process to module count ratio (86:1583) is a little lower than my windows box(64:2701) [As if the two could be realistically compared ;-)]:

ps awx | wc -l

86

/usr/sbin/lsof | wc -l

1583

...

Now look at my OpenBSD box (no Xwin running here either):

# ps -la | wc -l

20

# fstat | wc -l

183

....

Part of "proactive security" employed by creators of OpenBSD are the careful decisions:

(1) to run as few default services as possible

(2) not to support every application on the planet

There's not too much more to say on this type of logic: "The smaller your garden, the more carefully you can attend to each plant." Albeit, one does have to grow enough to feed your family!

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,

...

Viisualizing SIPs over time,port,IP range

Being able to quickly visualize Source IP Addresses over time and port and IP range is significant. The following utilities help:

• mergecap
  
• ipsumdump
  
• pcregrep
  
• gnuplot
  

Mergecap is part of the Wireshark distribution.  It merges pcap files quickly and with little fanfare. Ipsumdump is a brilliant piece of software by UCLA prof Eddie Kohler. It is based on his "Click" router development which provides functional replacement for pcap code. Gnuplot is indispensable as part of the *Nix toolkit.What I want to do here is:

(1) merge two weeks of tcpdump captures into one pcap file

(2) filter out some common ports (e.g. noise)

(3) meaningfully analyze SIP behavior

The examples below are simple and straightforward. I expect to explore this software more.

[Here I filter out some common 'noisy' internal traffic:]

more no_search.txt

 514

 520

 137

 138

 67

[Now I merge a couple weeks of pcap files and then columnize them with ipsumdump:]

mergecap -w May22-Jun4.cap May*2009 Jun012009

ipsumdump -r --no-headers -qtsSdDpO May22-Jun4.cap | pcregrep -v -f no_search.txt | sort -n -k 2  | more

....

1243564232.633833 110.8.212.14 3232 192.168.0.12 12712 U -

1243819790.146836 113.12.190.38 41300 192.168.0.12 1434 U -

1243962105.530513 113.12.190.38 40074 192.168.0.12 1434 U -

1243948162.113607 114.44.118.145 2522 192.168.0.12 25 T mss1440;sackok

1243948162.891020 114.44.118.145 2522 192.168.0.12 25 T mss1440;sackok

1243948163.661370 114.44.118.145 2522 192.168.0.12 25 T mss1440;sackok

1242915720.575869 114.45.61.61 4121 192.168.0.12 25 T mss1440;sackok

1242915727.208449 114.45.61.61 4121 192.168.0.12 25 T mss1440;sackok

1243948165.160091 115.150.202.176 1358 192.168.0.12 12712 U -

1243580800.176250 115.30.142.186 46453 192.168.0.12 1434 U -

.....

[Now I re-ordered one SIP I want to explore more closely:]

grep 121.15.245.215 out.dat 121.15.245.215.dat

sort -nr 121.15.245.215.dat > 121.15.245.215.graph.dat

1243935815.497855 121.15.245.215 12200 192.168.0.12 8000 T .

1243896403.852720 121.15.245.215 12200 192.168.0.12 3128 T .

1243786852.873342 121.15.245.215 12200 192.168.0.12 8000 T .

1243786749.219621 121.15.245.215 12200 192.168.0.12 3128 T .

1243751923.943017 121.15.245.215 12200 192.168.0.12 8000 T .

1243751811.136522 121.15.245.215 12200 192.168.0.12 3128 T .

1243702801.387269 121.15.245.215 12200 192.168.0.12 8000 T .

1243702687.231474 121.15.245.215 12200 192.168.0.12 3128 T .

1243678638.723457 121.15.245.215 12200 192.168.0.12 7212 T .

....

[Then I plot that SIP's activity over time:]

gnuplot> set terminal dumb

Terminal type set to 'dumb'

Options are 'feed  79 24'

gnuplot> plot "121.15.245.215.graph.dat" using 1 with lines

     1.244e+09 ++-------+-------+--------+--------+--------+-------+-------++

               **       +       + "121.15.245.215.graph.dat" using 1 ****** +

               | *                                                          |

    1.2438e+09 ++ *                                                        ++

               |  *******                                                   |

               |         *******                                            |

               |                *********                                   |

    1.2436e+09 ++                        ****                              ++

               |                             *******                        |

               |                                    *                       |

    1.2434e+09 ++                                   *                      ++

               |                                    *                       |

               |                                    *                       |

    1.2432e+09 ++                                    *                     ++

               |                                     *                      |

               |                                     *                      |

               |                                     **                     |

     1.243e+09 ++                                      *******             ++

               |                                              **            |

               +        +       +        +        +        +    **********  +

    1.2428e+09 ++-------+-------+--------+--------+--------+-------+-------++

               0        5       10       15       20       25      30       35

[Here, the SIPs behaviour makes me more interested in plotting per port...]

grep 218.103.62.150 out.dat > 218.103.62.150.dat

more 218.103.62.150.dat 

1242901282.013137 218.103.62.150 55248 192.168.0.12 19899 T mss1394;sackok

1242901282.670295 218.103.62.150 55248 192.168.0.12 19899 T mss1394;sackok

1242901283.342359 218.103.62.150 55248 192.168.0.12 19899 T mss1394;sackok

1242901284.902925 218.103.62.150 55254 192.168.0.12 17337 T mss1394;sackok

1242901285.542566 218.103.62.150 55254 192.168.0.12 17337 T mss1394;sackok

1242901286.151354 218.103.62.150 55254 192.168.0.12 17337 T mss1394;sackok

1242901287.088508 218.103.62.150 55257 192.168.0.12 17681 T mss1394;sackok

1242901287.664895 218.103.62.150 55257 192.168.0.12 17681 T mss1394;sackok

1242901288.291307 218.103.62.150 55257 192.168.0.12 17681 T mss1394;sackok

...

gnuplot

gnuplot> set terminal dumb

gnuplot> plot "218.103.62.150.dat" using 5:1 with points

    1.2429e+09 ++------+------+-------+-------+------+-------+------+------++

               +       +      +       "218.103.62.150.dat" using 5:1+  A    +

               A                                                            |

    1.2429e+09 ++                                                          ++

               |                                                            |

               |                                                            |

               |                                                            |

    1.2429e+09 ++                                                          ++

               |                                                  A         |

               |                                                  A         |

    1.2429e+09 ++                          AA                              ++

               A          A                 A                               |

               | A                       AA                               A |

    1.2429e+09 ++A                                                        A++

               |       A A        A        A                                |

               |                                                            |

               |    A                                                       |

    1.2429e+09 A+                                                          ++

               |                                                            |

               +       +      +       +  AA  A+      +       +      +       +

    1.2429e+09 ++------+------+-------+------A+------+-------+------+------++

               0      5000  10000   15000   20000  25000   30000  35000   40000

National Cyber Security Review II

So I read as below from the 100 documents submitted for the National 60 day Cyber Security Review:

cat pdf.all.txt | wc

11596  327837 2232007

It took me two days - with copious breaks and diversions. The number of federal agencies that responded to, have something to do with, have developed cyber security standards, or assure compliance of those standards is mind-numbing. I hardly know where to start to discuss all the players and their efforts. And actually, I don't think the federal government does either. It was not untypical to read a line like this:

"There are currently several cyber collaboration centers that interact across the Federal Government space to help disseminate information on security threats, including the U.S. Computer Emergency Readiness Team (US-CERT), National Cybersecurity Center, Joint Task Force- Global Network Operations, the National Cyber Investigative Joint Task Force, the Intelligence Community Incident Response Center, the National Security Agency Threat Operations Center, and the Defense Cyber Crime Center. The exact interactions and roles of each, however, remain unclear."

I sensed confusion (even desperation), an overlap of responsibility, a lack of cohesion in development of cyber strategies and turf wars. In short, with exceptions, the only items not missing are $$$ and ideas. A lot of roadmaps  were proposed and a limited amount of security architecture was described with some interesting exceptions. I suspect that the outcome of this review will serve President Barack Obama's purposes exactly. We have the talent and the resources to become a cyber secure nation. Turf wars, in-fighting, lack of cohesive strategies and lack of prioritization of threat vectors has fragmented the national approach to cyber security.  The 60 day review puts all levels of bureacrats on watch.  What could shake out  of this is the predominance of the most brilliant and most resillient of the national cyber warrior agencies for a cohesive national cyber security strategy.  How this will happen,I do not know. But I would put a bet on NIST, NSA, DOD and CERT re-organization and leadership in this area based on what I read. There may need to be increased standards and federal scrutiny of private critical infrastructures.Occasionally, the documents contained something technically pragmatic and brilliant such as this comment:

Jeff Brown, CISO, Raytheon Company:    

"In today's cyber security environment there is one inescapable truth.  There is no way to  prevent a determined intruder from getting into a network so long as one allows email and  web surfing ­and no business today can long survive without these two bedrocks of the  information age.    The reasons for this are simple.  The vast majority of our Information Assurance  architectures rely on patching and configuration control for protection, the consistent  application of which has thus far proven elusive over large enterprises.  It also relies on  signatures for both protection and detection which, by definition, will not stop the first wave of  the increasing volume of zero day attacks we are seeing today.  Therefore, when you must let  the attack vector (an email or a web address) past your perimeter to the desktop, you are  virtually guaranteed to have successful penetrations. Raytheon believes the best way to address this new reality is to recognize that attackers  will get into your network and expand our defensive actions to detect, disrupt, and deny  attacker's command and control (C2) communications back out to the network.  It is an  acknowledgement of the fact that there are fewer, or perhaps relatively noisier, ways to get out  of a network than to get into it.  Such a strategy focuses on identifying the web sites and IP  addresses that attackers use to communicate with malicious code already infiltrated onto our  computers.  While some of these sites are legitimate sites which have been compromised, the  majority are usually new domains registered by attackers solely for the purposes of command  and control.  There is little danger of unintended consequences from blocking these web sites  and their associated IP addresses for outbound traffic.  Where they are legitimate sites, the  benefit of protecting the enterprise far outweighs any inconvenience there might be if an  employee needs to legitimately go to that site.  Raytheon has had success with this strategy,  but it requires a significant investment, unaffordable to most small and medium size entities  and many larger ones.  One of the corollaries of recognizing that networks can always be penetrated is a shift in  how we measure ourselves.  Measuring ourselves against how many intrusions occur becomes  a far less interesting.  What counts, instead is the intruder's dwell time in our network, or how  long an intruder has had access.  It's more important to recognize how successful the  penetrations were versus how many penetrations occurred."

So Raytheon is practically solving security with a novel approach - one that doesn't sacrifice utility for security. Based on a recent and comprehensive report from Verizon's business unit, Raytheon may be singular in its success. When we switched phone services to Verizon, I had no I idea I would be joining a phone network that boasts an incredibly talented cyber research division.  Verizon's 2009 Data Breach Investigations Report http://www.verizonbusiness.com/products/security/risk/databreach/ is a must read.  The book fits with Misha Glenny's (2008,2009) "McMafia: A Journey Through the Global Criminal Underworld".  Verizon found that "91% of all compromised records were attributed to organized criminal groups". 

Below are some significant quotes from this report (http://www.verizonbusiness.com/products/security/risk/databreach/):

[/STARTQUOTING]

"2008 will likely be remembered as a tumultuous year for corporations and consumers alike. Fear, uncertainty, and doubt seized global financial markets; corporate giants toppled with alarming regularity; and many who previously lived in abundance found providing for just the essentials to be difficult. Among the headlines of economic woes came reports of some of the largest data breaches in history. These events served as a reminder that, in addition to our markets, the safety and security of our information could not be assumed either.

The 2009 Data Breach Investigations Report (DBIR) covers this chaotic period in history from the viewpoint of our forensic investigators. The 90 confirmed breaches within our 2008 caseload encompass an astounding 285 million compromised records. These records have a compelling story to tell, and the pages of this report are dedicated to relaying it. As with last year, our goal is that the data and analysis presented in this report prove helpful to the planning and security efforts of our readers. Below are a few highlights from the report:

....

Some attackers simply repacked existing malware so as to make its signature undetectable by antivirus software (AV) scanners. Others leveraged existing malicious code, but modified it for additional functionality or tailored it to the victim’s environment. Most common in 2008, however, was malware that had (apparently) been created for the attack(s) entirely from scratch. In a rather sobering statistic, 85 percent of the 285 million records breached in the year were harvested by custom-created malware. It is possible that the code preexisted yet went unrecognized by the experts and tools at ICSA Labs, but this matters little to the overall point. More to the point is that, besides being more capable and better adapted, most malware used for the purpose of compromising data is not detectable by modern AV. Unfortunately, many organizations rely on AV as the primary means of malware prevention and detection. AV is certainly a foundational control, but the continuing evolution of malware leaves security programs built solely upon AV for combating malware unstable at best.

....

On the whole, organizations discovered breaches slightly quicker in 2008. However, lest we confuse “quicker” with “quickly,” this statement needs some additional context.Breaches still go undiscovered and uncontained for weeks or months in 75 percent of cases. It is doubtful that any chief security officer anywhere would call this “quick”. "

[/ENDQUOTING]

The report makes clear the general picture of what "cyberwarfare" is today: Organized crime systematically plundering finanicial records for profit without being noticed. A number of current articles confirm this:

http://www.wired.com/threatlevel/2009/04/pins/

http://www.washingtonpost.com/wp-dyn/content/article/2009/04/15/AR2009041501196.html?sid=ST2009041501334

Interesting commentary on Verizons findings can be found at their blog: http://securityblog.verizonbusiness.com/.  

I think I will spend tommorrow and the next day writing code....my capacity for integrating the amount of disparate federal offices concerned with cyber security has reached its limit.