Koozali.org: home of the SME Server
Legacy Forums => Experienced User Forum => Topic started by: E-smith User on May 23, 2003, 01:27:57 AM
-
Here is the ACID Log:
#0-(1-5296) [snort] ATTACK-RESPONSES id check returned
userid 2003-05-22 15:27:20 192.168.2.8:25 204.92.158.14:40095 TCP
#2-(1-5291) [snort] ATTACK-RESPONSES id check returned userid 2003-05-22 15:15:43 192.168.2.8:4243 206.24.192.154:80 TCP
#3-(1-5290) [snort] ATTACK-RESPONSES id check returned userid 2003-05-22 15:15:40 192.168.2.8:4250 206.24.192.154:80 TCP
#4-(1-5289) [snort] ATTACK-RESPONSES id check returned userid 2003-05-22 15:15:39 192.168.2.8:4249 206.24.192.154:80 TCP
#5-(1-5286) [snort] ATTACK-RESPONSES id check returned userid 2003-05-22 15:15:38 192.168.2.8:4246 206.24.192.154:80 TCP
#6-(1-5287) [snort] ATTACK-RESPONSES id check returned userid 2003-05-22 15:15:38 192.168.2.8:4247 206.24.192.154:80 TCP
#7-(1-5288) [snort] ATTACK-RESPONSES id check returned userid 2003-05-22 15:15:38 192.168.2.8:4248 206.24.192.154:80 TCP
#8-(1-5285) [snort] ATTACK-RESPONSES id check returned userid 2003-05-22 15:15:36 192.168.2.8:4245 206.24.192.154:80 TCP
#9-(1-5283) [snort] ATTACK-RESPONSES id check returned userid 2003-05-22 15:15:35 192.168.2.8:4242 206.24.192.154:80 TCP
#10-(1-5284) [snort] ATTACK-RESPONSES id check returned userid 2003-05-22 15:15:35 192.168.2.8:4244 206.24.192.154:80 TCP
#11-(1-5282) [snort] ATTACK-RESPONSES id check returned userid 2003-05-22 15:15:33 192.168.2.8:4241 206.24.192.154:80 TCP
#12-(1-527
The message "ATTACK-RESPONSES id check returned userid" appears in ACID log every couple minutes.
192.168.2.8 is e-smith external interface.
Is anybody know how to check and clean up my E-smith box?
E-smirh 5.1.2, SNORT, ACID v0.9.6b23
-
Preface: I'm not a security expert. I'm not quite a Lunix newbie but when it comes to security I'm most certainly a newbie. That said if you find anything different than what I found below reply to this message.
This looks like it should be legitimate traffic. I get this same error every time I visit certain web sites. If you notice the note from Snort's web site under the heading of Corrective Action: Ensure that this event was not generated by a legitimate session then investigate the server for signs of compromise Look for other events generated by the same IP addresses. First part says "Ensure that this event was not generated by a legitimate session". To double check the problem I stopped all web activity to the suspected web site (I have a very small network and had all users stop going to certain web sites). When they stopped going to those sites the alert dropped of the chart completely. When I returned the usage it returned. This would appear then to be a legitimate request from a web site one or more of my users visited. Also note that all traffic generated went to port :80.
My guess as to the reason it popped up recently is that it must be a new Snort rule. It started in my logs the day after yours did.
Thanks to Charlie Brady for setting me on the right path to find this...even if he didn't know it.
P.S. If you REALLY do have a security breach. Don't share it in the open forms hackers would just love that kind of intell for free.
-
Here is the note I got back from SNORT:
"Check the latest version from CVS. I added a new version earlier today that will reduce false positives."
I suspect that if you're is set like mine it will auto update with the new settings.