Google Desktop Has New Features
We have gotten alot of questions and concerns over the new functionality implemented with Google Desktop.
Here is a short blurb on Google's site about the functionality:"Search Across Computers enables you to search your documents and viewed web pages across all your computers. For example, you could find files you edited on your desktop from your laptop. To activate this feature, you will need a Google Account (the same login you use for Gmail, Orkut, or other Google services). Remember, to search your other computers you must also install Google Desktop on them as well as enable the Search Across Computers preference using the same Google Account on each one."
More information about it can be found at: http://desktop.google.com/features.html
The Google Desktop is a tool which users can choose to use or choose not to use it. They simply offer a service. By default, the functionality is not turned on. To search other computers they have to be running Google desktop and have the "Search Across Computers" preference turned on each one of them as well as you have to have the same Google account to access them.
To download the tool, you have to agree to their "terms and conditions" and their "privacy" policy. If you have questions, Google has a webpage for questions.
I think fellow handler Lenny Zeltser sums it up best in this statement:"It's google's job to provide useful tools and clearly state their privacy policy and data abuse issues. I'll leave it up to the users to decide whether they want to take advantage of the tool's new capabilities or not."
Keywords:
0 comment(s)
Check Point Outbound Traffic Mystery
One of our readers, Jeff Peterson, submitted to us a packet capture that was coming from a newly built Checkpoint Firewall, Build 244 . Here is what he observed in his own words:
I did ask about the base OS being a fresh install and here are his comments as well:
Here is a short synopsis of the traffic being observed:
There are 4 UDP packets being sent to one IP address then switching to the other and sending 4 more. This repeats itself over and over. The one IP 48.28.223.239 doesn't appear to have anything assigned to it but belongs to Prudential Securities Inc. The other IP 152.96.109.99 belongs to:
descr: HSR Hochschule fuer Technik Rapperswil
descr: Rapperswil, Switzerland
Dst Port is 57327/UDP
Src port is 32768
If you would like to see two example packets, you can view them here:
http://isc.sans.org/diaryimages/packets for checkpoint.txt
The issue went away with new CDs being obtained from the vendor.
This is the only report we received about this so far. If you have observed similar traffic or have any ideas, please let us know.
"This file is from a freshly installed Checkpoint Firewall 1 VPN gateway. This machine was off-line until installation was completed and policy pushed.
Once the service starts and the first login attempt is completed the interface of the machine starts blasting the captured information to two targeted destination IP's.....Installation is from a Checkpoint supplied CD."
Once the service starts and the first login attempt is completed the interface of the machine starts blasting the captured information to two targeted destination IP's.....Installation is from a Checkpoint supplied CD."
I did ask about the base OS being a fresh install and here are his comments as well:
"Yes. In fact I've built the server twice from scratch using only the checkpoint supplied CD which includes the OS and Firewall. Ie: SecurePlatform. The outcome was the same both times"
Here is a short synopsis of the traffic being observed:
There are 4 UDP packets being sent to one IP address then switching to the other and sending 4 more. This repeats itself over and over. The one IP 48.28.223.239 doesn't appear to have anything assigned to it but belongs to Prudential Securities Inc. The other IP 152.96.109.99 belongs to:
descr: HSR Hochschule fuer Technik Rapperswil
descr: Rapperswil, Switzerland
Dst Port is 57327/UDP
Src port is 32768
If you would like to see two example packets, you can view them here:
http://isc.sans.org/diaryimages/packets for checkpoint.txt
The issue went away with new CDs being obtained from the vendor.
This is the only report we received about this so far. If you have observed similar traffic or have any ideas, please let us know.
Keywords:
0 comment(s)
Spam, Recon or ??: You make the call!!
One of my favorite things to see come in to the handlers list are packets. You gotta love packets! Doing packet analysis is like trying to solve a puzzle, but without all the pieces and not knowing what you are supposed to build. One of the things that you do have to be careful of is thinking that you've seen it all before. What do I mean by that? Well, what I mean is looking at traffic and you immediately tend to classify it into a category based on protocol and/or ports etc. For instance maybe its UDP traffic on port 53, just DNS right? Well, are you sure that's all that it is? I know it's not feasible to look at everything, but when alerts/flags are raised I think we have a tendency to go "oh that just......we see it all the time". But, did you actually look at it to be sure?
It has often been said that if you want to hide something, hide it in plain sight. It makes perfect sense. If you want traffic to get through, make it look close enough to something else that no one bothers to take a second look at it.
Today we got some logs submitted to us with some questions on the ICMP traffic. Even though it's not a packet capture, there was enough data to do some analysis. Here are the links to the files for your viewing pleasure:
http://isc.sans.org/diaryimages/icmpType3.log
http://isc.sans.org/diaryimages/icmpType11.log
It is interesting to note that several handlers looked at the traffic and many conclusions were reached. I won't share with you our conclusions at this time, but I would like to see what the rest of you come up with. Maybe you don't have an answer as to what it is (something you have to learn to accept when you analyze network traffic), but maybe you notice something unique about the traffic. Here is a short summary. ICMP error messages arrived at a host. However, that host did not have any outbound traffic that would have generated the ICMP error messages. Each of the error messages does contain the rough headers of the packet that caused the ICMP error messages. I'll post later the analysis done by some of the handlers and the results that everyone else came up with.
So, get ready to have fun and do some analysis!
It has often been said that if you want to hide something, hide it in plain sight. It makes perfect sense. If you want traffic to get through, make it look close enough to something else that no one bothers to take a second look at it.
Today we got some logs submitted to us with some questions on the ICMP traffic. Even though it's not a packet capture, there was enough data to do some analysis. Here are the links to the files for your viewing pleasure:
http://isc.sans.org/diaryimages/icmpType3.log
http://isc.sans.org/diaryimages/icmpType11.log
It is interesting to note that several handlers looked at the traffic and many conclusions were reached. I won't share with you our conclusions at this time, but I would like to see what the rest of you come up with. Maybe you don't have an answer as to what it is (something you have to learn to accept when you analyze network traffic), but maybe you notice something unique about the traffic. Here is a short summary. ICMP error messages arrived at a host. However, that host did not have any outbound traffic that would have generated the ICMP error messages. Each of the error messages does contain the rough headers of the packet that caused the ICMP error messages. I'll post later the analysis done by some of the handlers and the results that everyone else came up with.
So, get ready to have fun and do some analysis!
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments