Another great day at Linux Fest! I attended excellent presentations on Digital Forensics by Hal Pomeranz and Brian Pate (2 hours), both of which were very useful and felt very "hands on". I can't say enough good things about LinuxFest. The organizers are doing Whatcom County business development a tremendous favor. In reality, I think the Chamber of Commerce and the City of Bellingham should be helping to fund this volunteer supported event every quarter. Talent comes from all over the Northwest: Seattle, Portland, Tri-Cities, Olympia, Bothell, Mt. Vernon, you name it. I made contacts, met vendors, passed out business cards and had great discussions. Learned a lot as well.
Thank you LinuxFest NorthWest!!!!
Sunday, April 25, 2010
Saturday, April 24, 2010
Brilliant Day 1 at LinuxFest NorthWest
I had a brilliant first day at LinuxFest NorthWest. I sat through five presentations on privacy and computer security in Haskell 115 at Bellingham Technical College. Brian Alseth of ACLU of Washington delivered the usual terrifying description of how data mining is destroying privacy. John Lock talked about Web Commerce Security. Gary Smith of PNL gave and excellent talk on Linux Server Hardening. Hal Pomeranz finished up the day with two hours on SE Linux. Wow! What a beast SE Linux is...
LinuxFest...a great thing.
LinuxFest...a great thing.
Wednesday, April 21, 2010
Joanna Rutkowska and ITL and "Security by Isolation"
A day spent reading the research of Joanna Rutkowska and her Invisible Things Lab is a day spent improving your IQ. Ms. Rutkowska is famous for describing vulnerabilities in SMM, BIOS, and VM hypervisors. In short, rather than attack the Operating System (although she has done some of that as well), she and her team attack the layer between the Operating System and the hardware; specifically rings -1, -2, -3 to use her terminology. Her work has led her to some drastic conclusions about hardware and digital security. In Joanna's universe, it is not that "game is over" but that the digital industry has never really fielded a team that could win yet. To do something about this, she and her team have developed a customized version of Linux (Qubes-OS); partitioning off OS components into VMs to prevent the spread of malware through the access of "universal privilege" (my own term).
What do I mean by "universal privilege"? [Beware, the author's own untutored verbiage is to follow...] Computers are strange but beautiful machines. When the first computational devices were built, we wanted to send in questions and retrieve answers. After computer scientists achieved this breakthrough, they spent the next half century attempting to generate increasing profits by increasing the speed at which answers to their questions would be returned. And they did a damn fine job at this. The increase in computational speed has to count as the single greatest technical advancement of our species by this point in history. Watch any movie about the Hubble or the Mars Rover and ask yourself: How would that happen without digital data? We have designed our computational efforts as if we were children with thirsty minds and ravenous social needs; ready to exercise our "universal privilege" to discuss/communicate/download whatever our minds and souls desire.
Security is mainly the story of protection. Secrecy is mainly the story of compartmentalization. In contrast to the development of computational speed, we've done a poor job at protection and compartmentalization of computers and their networks. In fact, we've been so concerned about the spread of information, we've done everything possible to unleash the flow of digital data across the world. PCs and Servers are now everywhere, in every complex product, in every country. Our computer networks are now the most tangible and real-time evidence of our civilization. Computers still retain all of the "strange and beautiful" architecture designed upon the premise that we want very little between our computers and fast answers to our questions. We are by nature social creatures with unbounded curiosity and potentially unbounded need for "end to end" trust. Unfortunately, the reality of unconstrained digital response has helped created powerful offensive weaponry in the untrustworthy world we live in.
So now back to universal privilege and Joanna Rutkowska and her team at Invisible Things Lab. Eschewing (in part) the drive for secure code and secure micro-kernels, Joanna and her team attempt to do the following:
"Qubes implements Security by Isolation approach. To do this, Qubes utilizes virtualization technology, to be able to isolate various programs from each other, and even sandbox many system-level components, like networking or storage subsystem, so that their compromise don’t affect the integrity of the rest of the system."
They achieve this "security by isolation" by compartmentalizing their OS into secure virtual machines. It is a timely idea. As if to prove this, the NSF gave a $1.5 M dollar grant to an University of Illinois researcher nearly days after ITL's announcement of Qubes to do something similar. "Security by isolation" is an ancient concept thoroughly deployed by computer and software architecture at all levels. There are numerous examples: CPUs break down access to the processor into "Rings" (0-3). Operating Systems break down execution in kernel and userland and then compartmentalize execution further. Some kernels just boot the most basic OS components, (Most desktop OS kernels are monolithic). Software compartmentalizes (perhaps 'componentizes') itself into functions, system calls, objects, and libraries. Some software, like Java and C#, works hard at making code live in a secure 'sandbox'. Part of the developmental reason for object oriented programming (originally) was (marginally) security-based: 'encapsulation'. Networking software has followed the trend of security by compartmentalization from switch fabric to firewalls to NAC. Hosted services, in some very real sense, are a form of "security by isolation".
In reality, we continue to invent "security by isolation" in kernels, software layers, networks, network components, firewalls, and virtual machines. As processor speed grows in an untrustworthy world, the desktop and network will always continue to need the most advanced compartmentalization to protect them from the expanding digitized world. To this end, our "universal privilege" to keep asking questions of each other will always be haunted by the necessity of "security by isolation".
What do I mean by "universal privilege"? [Beware, the author's own untutored verbiage is to follow...] Computers are strange but beautiful machines. When the first computational devices were built, we wanted to send in questions and retrieve answers. After computer scientists achieved this breakthrough, they spent the next half century attempting to generate increasing profits by increasing the speed at which answers to their questions would be returned. And they did a damn fine job at this. The increase in computational speed has to count as the single greatest technical advancement of our species by this point in history. Watch any movie about the Hubble or the Mars Rover and ask yourself: How would that happen without digital data? We have designed our computational efforts as if we were children with thirsty minds and ravenous social needs; ready to exercise our "universal privilege" to discuss/communicate/download whatever our minds and souls desire.
Security is mainly the story of protection. Secrecy is mainly the story of compartmentalization. In contrast to the development of computational speed, we've done a poor job at protection and compartmentalization of computers and their networks. In fact, we've been so concerned about the spread of information, we've done everything possible to unleash the flow of digital data across the world. PCs and Servers are now everywhere, in every complex product, in every country. Our computer networks are now the most tangible and real-time evidence of our civilization. Computers still retain all of the "strange and beautiful" architecture designed upon the premise that we want very little between our computers and fast answers to our questions. We are by nature social creatures with unbounded curiosity and potentially unbounded need for "end to end" trust. Unfortunately, the reality of unconstrained digital response has helped created powerful offensive weaponry in the untrustworthy world we live in.
So now back to universal privilege and Joanna Rutkowska and her team at Invisible Things Lab. Eschewing (in part) the drive for secure code and secure micro-kernels, Joanna and her team attempt to do the following:
"Qubes implements Security by Isolation approach. To do this, Qubes utilizes virtualization technology, to be able to isolate various programs from each other, and even sandbox many system-level components, like networking or storage subsystem, so that their compromise don’t affect the integrity of the rest of the system."
They achieve this "security by isolation" by compartmentalizing their OS into secure virtual machines. It is a timely idea. As if to prove this, the NSF gave a $1.5 M dollar grant to an University of Illinois researcher nearly days after ITL's announcement of Qubes to do something similar. "Security by isolation" is an ancient concept thoroughly deployed by computer and software architecture at all levels. There are numerous examples: CPUs break down access to the processor into "Rings" (0-3). Operating Systems break down execution in kernel and userland and then compartmentalize execution further. Some kernels just boot the most basic OS components, (Most desktop OS kernels are monolithic). Software compartmentalizes (perhaps 'componentizes') itself into functions, system calls, objects, and libraries. Some software, like Java and C#, works hard at making code live in a secure 'sandbox'. Part of the developmental reason for object oriented programming (originally) was (marginally) security-based: 'encapsulation'. Networking software has followed the trend of security by compartmentalization from switch fabric to firewalls to NAC. Hosted services, in some very real sense, are a form of "security by isolation".
In reality, we continue to invent "security by isolation" in kernels, software layers, networks, network components, firewalls, and virtual machines. As processor speed grows in an untrustworthy world, the desktop and network will always continue to need the most advanced compartmentalization to protect them from the expanding digitized world. To this end, our "universal privilege" to keep asking questions of each other will always be haunted by the necessity of "security by isolation".
Sunday, April 18, 2010
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.
Wednesday, April 14, 2010
tcpslice
Tcpslice is a useful tool from LBL network group that allows you to carve up a large pcap file format into time slices.
To look at the start and finish time stamps of the entire pcap file in various time formats:tcpslice -r Marchrferrisx.snort.in Marchrferrisx.snort.in Mon Mar 8 11:08:09 2010 Mon Apr 5 09:09:37 2010tcpslice -t Marchrferrisx.snort.inMarchrferrisx.snort.in 2010y03m08d11h08m09s660222u 2010y04m05d09h09m37s390876utcpslice -R Marchrferrisx.snort.inMarchrferrisx.snort.in 1268075289.660222 1270483777.390876
To return data from a particular time slice to a file with BPF filters use syntax like this: tcpslice 1257347146.060 1257347146.061 inputFile.tcpd | tcpdump -r - -w outputFile.tcpd 'host 192.168.1.175'
(Check out bothunter logs for more examples like this..)
In this example, I want all the packets that are not IPv6 for one date:/usr/sbin/tcpslice 2010y04m05d Marchrferrisx.snort.in | /usr/sbin/tcpdump -r - 'not(ip6)' | lessreading from file -, link-type EN10MB (Ethernet)
01:06:17.290514 IP 125.141.195.190.35460 > 192.168.0.12.ssh: S 1607742099:1607742099(0) win 65535
01:40:16.181816 IP c-98-247-214-152.hsd1.wa.comcast.net.catchpole > 192.168.0.12.telnet: SWE 498716114:498716114(0) win 5840
01:40:19.172942 IP c-98-247-214-152.hsd1.wa.comcast.net.catchpole > 192.168.0.12.telnet: SWE 498716114:498716114(0) win 5840
01:44:01.423708 IP hn.kd.ny.adsl.x11 > 192.168.0.12.ms-sql-s: S 833421312:833421312(0) win 16384
03:37:06.073237 IP 75.125.252.76.http > 192.168.0.12.48532: S 1175613974:1175613974(0) ack 143375003 win 14420
04:07:03.019711 IP 222.45.112.59.12200 > 192.168.0.12.ssm-els: S 363594672:363594672(0) win 8192 ... Now I want all ms-sql-s destination packets from the ingress pcap that are not IPv6 for all of March:/usr/sbin/tcpslice 2010y04m01d 2010y04m31d Marchrferrisx.snort.in | /usr/sbin/tcpdump -r - -n 'dst port(1433)'
reading from file -, link-type EN10MB (Ethernet)
18:33:42.614843 IP 125.46.78.100.x11 > 192.168.0.12.ms-sql-s: S 908984320:908984320(0) win 16384
23:38:50.771853 IP 61.183.172.35.x11 > 192.168.0.12.ms-sql-s: S 47316992:47316992(0) win 16384
03:35:18.351118 IP 121.12.125.7.x11 > 192.168.0.12.ms-sql-s: S 640548864:640548864(0) win 16384
11:09:45.631103 IP 218.61.127.71.x11 > 192.168.0.12.ms-sql-s: S 1613627392:1613627392(0) win 16384
00:47:21.207593 IP 218.90.163.66.x11 > 192.168.0.12.ms-sql-s: S 648937472:648937472(0) win 16384
08:56:05.732622 IP 61.183.172.35.x11 > 192.168.0.12.ms-sql-s: S 47316992:47316992(0) win 16384
18:06:53.798198 IP 59.51.114.39.x11 > 192.168.0.12.ms-sql-s: S 648937472:648937472(0) win 16384 ...
Something similar, but a little cleaner, can be done with ipsumdump:/usr/sbin/tcpslice 2010y04m01d 2010y04m31d Marchrferrisx.snort.in | ipsumdump -tsD | grep -w 14331270172022.614843 125.46.78.100 14331270190330.771853 61.183.172.35 14331270204518.351118 121.12.125.7 14331270231785.631103 218.61.127.71 14331270280841.207593 218.90.163.66 14331270310165.732622 61.183.172.35 14331270343213.798198 59.51.114.39 1433 ...
Saturday, April 10, 2010
One year anniversary
Today is the one year anniversary of this blog. This is my 48th post in that time period. According to Google Analytics, 1,250 “absolute unique visitors” have provided for 1,566 visits from 781 unique cities from 78 unique countries. 72 page titles were viewed a total of 2,241 times. Here are some of the most popular pages:
- /2009/05/i-receive-lots-of-6000-port-scans-on-my.html
- /2009/09/network-monitor-api-part-ii.html
- /2009/05/host-protection-working-with-microsofts.html
Actually, I have no idea what to make of any of these numbers.
Monday, April 5, 2010
More fun with ipsumdump
More fun with ipsumdump. Below, sorting March ingress by COUNT(SIP), COUNT(SPort), Sorted GeoIP location. All very fast.
ipsumdump -s --no-headers Marchrferrisx.snort.in |
sort -nr | uniq -c | sort -nr | less
626 75.125.252.73
384 74.125.19.191
358 125.45.109.196
286 66.165.46.165
242 74.125.127.191
234 74.125.53.191
138 67.214.120.156
138 204.236.155.168
127 67.228.177.148
120 74.125.19.19
107 173.14.243.230
105 221.195.73.86
103 221.192.199.35
....
ipsumdump -S --no-headers Marchrferrisx.snort.in |
sort -nr | uniq -c | sort -nr
6523 80
1669 443
1220 12200
553 63585
468 19150
459 19099
238 6000
198 19135
156 19134
93 21
46 110
34 5242
30 9875
21 52079
21 35356
20 1935
for i in `ipsumdump -s --no-headers Marchrferrisx.snort.in |
sort -nr | uniq |sort -nr`
do
echo $i `geoip.sh $i | awk -F: '{print $2$3}'`
done
222.86.62.237 CN, N/A, N/A, N/A, 35.000000, 105.000000, 0, 0
222.59.176.26 CN, 04, Wuxi, N/A, 31.577200, 120.293900, 0, 0
222.59.176.105 CN, 04, Wuxi, N/A, 31.577200, 120.293900, 0, 0
222.45.112.59 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.45.112.221 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.41.8.67 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.37.37.33 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.34.103.72 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.243.14.144 CN, 11, Xupu, N/A, 27.909401, 110.585800, 0, 0
222.219.236.209 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.215.230.49 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.215.230.170 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.214.218.188 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.211.69.13 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.208.183.218 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.186.25.143 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.186.24.37 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
...
ipsumdump -s --no-headers Marchrferrisx.snort.in |
sort -nr | uniq -c | sort -nr | less
626 75.125.252.73
384 74.125.19.191
358 125.45.109.196
286 66.165.46.165
242 74.125.127.191
234 74.125.53.191
138 67.214.120.156
138 204.236.155.168
127 67.228.177.148
120 74.125.19.19
107 173.14.243.230
105 221.195.73.86
103 221.192.199.35
....
ipsumdump -S --no-headers Marchrferrisx.snort.in |
sort -nr | uniq -c | sort -nr
6523 80
1669 443
1220 12200
553 63585
468 19150
459 19099
238 6000
198 19135
156 19134
93 21
46 110
34 5242
30 9875
21 52079
21 35356
20 1935
for i in `ipsumdump -s --no-headers Marchrferrisx.snort.in |
sort -nr | uniq |sort -nr`
do
echo $i `geoip.sh $i | awk -F: '{print $2$3}'`
done
222.86.62.237 CN, N/A, N/A, N/A, 35.000000, 105.000000, 0, 0
222.59.176.26 CN, 04, Wuxi, N/A, 31.577200, 120.293900, 0, 0
222.59.176.105 CN, 04, Wuxi, N/A, 31.577200, 120.293900, 0, 0
222.45.112.59 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.45.112.221 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.41.8.67 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.37.37.33 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.34.103.72 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.243.14.144 CN, 11, Xupu, N/A, 27.909401, 110.585800, 0, 0
222.219.236.209 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.215.230.49 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.215.230.170 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.214.218.188 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.211.69.13 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.208.183.218 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.186.25.143 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.186.24.37 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
...
Friday, April 2, 2010
"One Page Checklist for Securing and Cleaning a Malware Infected Windows PC"
A "One Page Checklist for Securing and Cleaning a Malware Infected Windows PC" is available. From the paper:
In this process, you are looking for outbound and inbound communication and connection attempts that seem suspicious – data transfers that you can not account for, processes that seem inexplicable, or unsigned files. You may or may not see logon attempts, registry changes, file creation, file access, file permission changes. You may need to correlate Network Monitor logs with network ingress and egress firewall logs. Additional info at:
Subscribe to:
Posts (Atom)