Tuesday, March 9, 2010
Monday, August 25, 2008
update
Just a quick update, it's been a while since my last post but there has not been too much going on either.
I've been working so much lately that I have not been able to follow up my project as much as I would like.
However, I decided to drop my current honeynet and set up a new one - I'm having some issues with honeywall registering every device on my switch as a honeypot which is kind of frustrating - also there was the issue with timestamping in the snort logs which I would love to work out.
I have gotten several tips on how to solve this through the honeywall mailing list and I will try these methods when installing a new honeywall later on this weekk.
Hopefully I will have the new virtual honeynet up&running by the weekend and this one will be a little more professional in the set up.
I've been working so much lately that I have not been able to follow up my project as much as I would like.
However, I decided to drop my current honeynet and set up a new one - I'm having some issues with honeywall registering every device on my switch as a honeypot which is kind of frustrating - also there was the issue with timestamping in the snort logs which I would love to work out.
I have gotten several tips on how to solve this through the honeywall mailing list and I will try these methods when installing a new honeywall later on this weekk.
Hopefully I will have the new virtual honeynet up&running by the weekend and this one will be a little more professional in the set up.
Tuesday, August 12, 2008
My honeypot part of a Fast-Flux net?
OK, so with a little data analyzing help from users at the Remote Exploit forums it seems these snort alerts can either mean that:
1. One of the SQL slammer attempts have been successful and that the honeypot is included in a Fast-Flux network to help spread malware, hence the snort alerts regarding DNS spoofing. (If unfamiliar with fast-flux, check out the article on wikipedia and the references used there - that should provide you with more than enough information).
2. There is something wrong with my honeywall setup which causes snort to generate all the SQL alerts, see here for a thread on the Snort IDS forum for a thread regarding this matter.
Also, the DNS no authority messages can have a natural explanation as you can see from this excerpt from the Snort-users mailing list.
Either way, I'm considering moving on from a virtual to a physical honeynet due to a lot of issues with the time stamping in honeywall which is giving me somewhat of a headache when it comes to analyzing the what/when/where of the IDS alerts.
1. One of the SQL slammer attempts have been successful and that the honeypot is included in a Fast-Flux network to help spread malware, hence the snort alerts regarding DNS spoofing. (If unfamiliar with fast-flux, check out the article on wikipedia and the references used there - that should provide you with more than enough information).
2. There is something wrong with my honeywall setup which causes snort to generate all the SQL alerts, see here for a thread on the Snort IDS forum for a thread regarding this matter.
Also, the DNS no authority messages can have a natural explanation as you can see from this excerpt from the Snort-users mailing list.
Either way, I'm considering moving on from a virtual to a physical honeynet due to a lot of issues with the time stamping in honeywall which is giving me somewhat of a headache when it comes to analyzing the what/when/where of the IDS alerts.
Monday, August 11, 2008
OK, I've been away for the weekend and came back to discover that my honeynet lost its Internet connection Friday night :/
This means that I don't have too much exiting stuff to report yet, most of the things I've registered in the IDS logs are a bunch of SQL worm attempts like this:
Except for a couple of things which I haven't been able too figure out what is yet:
Some of the things in the above output is kinda self explanatory, but there are a couple of things that have confused me a bit.
For instance; the DOUBLE DECODING attack which came from the 209.225.XX.101 to begin with, also came from 209.225.XX.102 and 209.225.XX.103 after a little while.
Does anyone know what this means? I was thinking bot net traffic but that is just speculation from my part, I still have a lot to learn when it comes to the analyzing IDS logs etc
Finally, the DNS Spoof Query response alerts, I'm not sure why they appear since they come from a legit DNS server I use. Might this just be a misconfiguration somewhere which makes Snort log these events as a possible incident?
As you probably understand, the honeypot is placed on the 81.191.XX.XX net, I've also chosen to censor the addresses of the machines which have initiated this traffic.
I haven't decided how to handle this part yet so for the moment I will censor these addresses too ensure that no-one will target these machines for any attacks etc.
Thats it for the moment, If anyone could help me to analyze the last output and tell me what they can red from it, that would be great!
This means that I don't have too much exiting stuff to report yet, most of the things I've registered in the IDS logs are a bunch of SQL worm attempts like this:
[**] [1:2004:7] MS-SQL Worm propagation attempt OUTBOUND [**]
[Classification: Misc Attack] [Priority: 2]
08/11-01:58:53.294081 61.132.XX.XX:1211 -> 81.191.XX.XX:1434
UDP TTL:117 TOS:0x28 ID:56527 IpLen:20 DgmLen:404
Len: 376
[Xref => http://vil.nai.com/vil/content/v_99992.htm][Xref => http://cgi.nessus.org/plugins/dump.php3?id=11214][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0649][Xref => http://www.securityfocus.com/bid/5311][Xref => http://www.securityfocus.com/bid/5310]
[**] [1:2050:9] MS-SQL version overflow attempt [**]
[Classification: Misc activity] [Priority: 3]
08/11-01:58:53.294081 61.132.XX.XX:1211 -> 81.191.XX.XX:1434
UDP TTL:117 TOS:0x28 ID:56527 IpLen:20 DgmLen:404
Except for a couple of things which I haven't been able too figure out what is yet:
[**] [1:853:9] WEB-CGI wrap access [**]
[Classification: Attempted Information Leak] [Priority: 2]
08/08-01:58:36.825855 81.191.XX.XX:1078 -> 194.19.40.XX.XX
TCP TTL:128 TOS:0x0 ID:1234 IpLen:20 DgmLen:435 DF
***AP*** Seq: 0x69A84218 Ack: 0xC6CC65E3 Win: 0xFAF0 TcpLen: 20
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=10317][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0149][Xref => http://www.securityfocus.com/bid/373][Xref => http://www.whitehats.com/info/IDS234]
[**] [119:2:1] (http_inspect) DOUBLE DECODING ATTACK [**]
08/08-01:58:37.005811 81.191.XX.XX:1079 -> 209.225.XX.101:80
TCP TTL:128 TOS:0x0 ID:1350 IpLen:20 DgmLen:626 DF
***AP*** Seq: 0x743BD687 Ack: 0xD43850A1 Win: 0xFAF0 TcpLen: 20
[**] [119:2:1] (http_inspect) DOUBLE DECODING ATTACK [**]
08/08-01:58:37.331863 81.191.XX.XX:1085 -> 209.225.XX.103:80
TCP TTL:128 TOS:0x0 ID:1581 IpLen:20 DgmLen:755 DF
***AP*** Seq: 0x3B1EA19 Ack: 0xCBE50FEA Win: 0xFAF0 TcpLen: 20
[**] [1:254:4] DNS SPOOF query response with TTL of 1 min. and no authority [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
08/08-01:58:40.626619 193.75.XX.XX:53 -> 81.191.XX.XX:63481
UDP TTL:62 TOS:0x0 ID:31932 IpLen:20 DgmLen:77
Len: 49
[**] [1:254:4] DNS SPOOF query response with TTL of 1 min. and no authority [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
08/08-01:58:40.638668 193.75.XX.XX:53 -> 81.191.XX.XX:64588
UDP TTL:62 TOS:0x0 ID:31998 IpLen:20 DgmLen:77
Len: 49
[**] [1:2201:5] WEB-CGI download.cgi access [**]
[Classification: access to a potentially vulnerable web application] [Priority: 2]
08/08-01:58:42.831535 81.191.XX.XX:1109 -> 192.150.XX.XX:80
TCP TTL:128 TOS:0x0 ID:2126 IpLen:20 DgmLen:459 DF
***AP*** Seq: 0x2952FB1C Ack: 0x753F6338 Win: 0xF9D1 TcpLen: 20
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=11748][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-1377][Xref => http://www.securityfocus.com/bid/4579]
Some of the things in the above output is kinda self explanatory, but there are a couple of things that have confused me a bit.
For instance; the DOUBLE DECODING attack which came from the 209.225.XX.101 to begin with, also came from 209.225.XX.102 and 209.225.XX.103 after a little while.
Does anyone know what this means? I was thinking bot net traffic but that is just speculation from my part, I still have a lot to learn when it comes to the analyzing IDS logs etc
Finally, the DNS Spoof Query response alerts, I'm not sure why they appear since they come from a legit DNS server I use. Might this just be a misconfiguration somewhere which makes Snort log these events as a possible incident?
As you probably understand, the honeypot is placed on the 81.191.XX.XX net, I've also chosen to censor the addresses of the machines which have initiated this traffic.
I haven't decided how to handle this part yet so for the moment I will censor these addresses too ensure that no-one will target these machines for any attacks etc.
Thats it for the moment, If anyone could help me to analyze the last output and tell me what they can red from it, that would be great!
Friday, August 8, 2008
quick update
OK, just to give you an impression of what a snort incident looks like when you review it from the Honeywall Walleye GUI.
What you see here is nothing special, just an automated SQL Worm attempt, logged by snort, which is implemented in Honeywall.
There are several sub features from this menu, you can download the flow in .pcap format to analyze in Wireshark or get more details from the snort data.
So far this is the only traffic I have seen as well, and it will probably remain like this for a little while.
I will keep updating regularly as I learn more about the usage of Honeywall, Snort and Walleye - Hopefully I will, in the end, be able to release a complete guide showing how to setting up a virtual honeynet and analyzing data.
But that little project will probably take its time as I want to learn as much as possible on my own before I start writing any guides :p
Thursday, August 7, 2008
Fresh start
Sweet! I got the WEB GUI running after getting some more help from the honeynet.org mailing list.
I submitted my question and 20 minutes later it was up and running and I could easily configure my Honeywall through a nice Web Interface which is way more intuitive than the old school one.
BUT after only about 20 minutes, the W2K box was flooded with worms, spyware and other pretty uninteresting stuff so I decided to ditch the whole project as it were and start again - this time at a little higher level to avoid that whole worm/spyware crap.
For starters, a Windows 2000 Pro box will get compromised by worm and other automated traffic in about 3 minutes whether you surf online or not, and this is NOT what I am looking for at all. So because of this I decided to kick it up a notch and install a Win 2003 x64 enterprise edition as my honeypot. I will patch it with the latest available Microsoft updates and install some services like IIS and perhaps SQL.
In addition to this, I want to add some sort of Linux box to the mix with some vulnerable services (I'm hoping that the Linux boxes won't attract so much automated worm traffic).
I have now learned how to configure the Honeywall under VMWare, set it up as a bridge for other VMWare machines and get the Web GUI running.
Therefore I'm guessing this set-up will be complete within a day or two and when it is done I will finally have a honeypot which has a level of security that will exclude the risk of getting flooded with worm traffic but still will look appealing to anyone who might be interested in doing some damage.
I'm sorry that I don't have any screens of the Honeywall and how the GUI looked when it was monitoring the W2K box, but if you give me some time now I will give you everything you desire and more :) plus, it will be much more interesting to analyze the actions performed by an actual person as opposed to the automated traffic from worms etc...
I submitted my question and 20 minutes later it was up and running and I could easily configure my Honeywall through a nice Web Interface which is way more intuitive than the old school one.
BUT after only about 20 minutes, the W2K box was flooded with worms, spyware and other pretty uninteresting stuff so I decided to ditch the whole project as it were and start again - this time at a little higher level to avoid that whole worm/spyware crap.
For starters, a Windows 2000 Pro box will get compromised by worm and other automated traffic in about 3 minutes whether you surf online or not, and this is NOT what I am looking for at all. So because of this I decided to kick it up a notch and install a Win 2003 x64 enterprise edition as my honeypot. I will patch it with the latest available Microsoft updates and install some services like IIS and perhaps SQL.
In addition to this, I want to add some sort of Linux box to the mix with some vulnerable services (I'm hoping that the Linux boxes won't attract so much automated worm traffic).
I have now learned how to configure the Honeywall under VMWare, set it up as a bridge for other VMWare machines and get the Web GUI running.
Therefore I'm guessing this set-up will be complete within a day or two and when it is done I will finally have a honeypot which has a level of security that will exclude the risk of getting flooded with worm traffic but still will look appealing to anyone who might be interested in doing some damage.
I'm sorry that I don't have any screens of the Honeywall and how the GUI looked when it was monitoring the W2K box, but if you give me some time now I will give you everything you desire and more :) plus, it will be much more interesting to analyze the actions performed by an actual person as opposed to the automated traffic from worms etc...
Wednesday, August 6, 2008
up & running !! :D
Ahhh, I finally got a virtual honeypot working fine using a host machine with VMWARE and one Windows 2000 Proffesional guest machine and one Honeywall guest machine.
With Sebek installed on my W2K machine I will be able to silently log any activity (keystrokes, file uploads etc) performed by persons who have illegaly gained access to my virtual honeypot.
Setting up a W2K machine in VMWare is pretty simple if you have used a computer for more than a week, just get VMWare and a W2K cd and you'll have a highly vulnerable honeypot in minutes :)
The honeywall on VMWare part, however, turned out to be a bit more tricky. The initial set-up after install was a bit too confusing for me and I messed it up quite a few times before I finally managed to get it right.
The mailing list for The Honeywall project ended up saving me and there are plenty of intelligent and experienced users there so that is a good tool to use if you are planning to deploy a honeywall of your own.
As we speak my W2k box is out in the wild waiting to get taken over and I will keep posting status info here as things evolve :)
The only annoying thing I still haven't got working quite yet is the Walleye feature of the Honeywall which is a HTTP GUI interface for the data output you will gain from your honeypot but I'm guessing I'll be able to sort that out in a few days.
With Sebek installed on my W2K machine I will be able to silently log any activity (keystrokes, file uploads etc) performed by persons who have illegaly gained access to my virtual honeypot.
Setting up a W2K machine in VMWare is pretty simple if you have used a computer for more than a week, just get VMWare and a W2K cd and you'll have a highly vulnerable honeypot in minutes :)
The honeywall on VMWare part, however, turned out to be a bit more tricky. The initial set-up after install was a bit too confusing for me and I messed it up quite a few times before I finally managed to get it right.
The mailing list for The Honeywall project ended up saving me and there are plenty of intelligent and experienced users there so that is a good tool to use if you are planning to deploy a honeywall of your own.
As we speak my W2k box is out in the wild waiting to get taken over and I will keep posting status info here as things evolve :)
The only annoying thing I still haven't got working quite yet is the Walleye feature of the Honeywall which is a HTTP GUI interface for the data output you will gain from your honeypot but I'm guessing I'll be able to sort that out in a few days.
Subscribe to:
Posts (Atom)