Closed (duplicate)
Project:
PHPIDS
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
28 Jan 2010 at 19:38 UTC
Updated:
17 Aug 2012 at 17:57 UTC
Jump to comment: Most recent file
At the moment, the module sends an email with:
Title: PHPIDS detected an attack with impact 52
Message: Check your logs to see a full detail of the report.
This gives me no reference as to when the attack occured and who did it (IP). Both of these are essential to finding the correct line in your syslog. For anyone who has even a mildly busy site and uses syslog, you'll know the pain of having to locate a needle in a hay-stack.
What the email needs is the time of the attack, the IP of the attack, and even the "details" of the attack.
Also, what is considered "full details"? When I eventually find the correct syslog entry all I see is:
::ffff:93.45.xxx.xxx example.com - [28/Jan/2010:14:11:17 -0500] "GET /?q=admin/reports/dblog&test=%3Cscript%3Ealert(%27hi%27)%3C/script%3E&test2=%3Cscript%3Ealert(%27hi2%27)%3C/script%3E HTTP/1.1" 301 37 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)"
Is that all?
I also checked my /tmp/ dir for more details but it only has one file (default_filter.cache), which also only has one record (from the very first attack).
I installed everything correctly as the status report gives me the green light.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | phpids-custom-pimp-v4.patch | 13.83 KB | eMPee584 |
| #8 | phpids-custom-pimp-v3.patch | 13.83 KB | eMPee584 |
| #7 | phpids-custom-pimp-v2.patch | 13.6 KB | eMPee584 |
| #6 | phpids-custom-pimp.patch | 26.18 KB | eMPee584 |
Comments
Comment #1
andrewsuth commentedComment #2
it-cruHello andrewsuth,
I will add attackers IP and Date/Time and perhaps an option to insert full report into message body in new dev branch.
Logging in 6.x-1.10:
You should find PHPIDS log entries under domain.tld/admin/reports/dblog by filtering for phpids. It's all integrated into drupal itself.
thx for request and greetz from Berlin
Gos77
Comment #3
andrewsuth commentedI don't log to the database, I prefer (for performance reasons) to only log to syslog.
The module should take this into account this case senario as well.
Comment #4
it-cruI created an own issue for the log to syslog feature request.
#698882: Feature Request: Logging to syslog
Comment #5
it-cruI have added attackers IP and attack-time to mail body. Please take a look at new branch dev-snapshot (e.g. 6.x-2.x-dev) and give feedback if it is enough.
On ToDo list:
- Full PHPIDS attack report in mail
Comment #6
eMPee584 commentedSalut..
i pimped my phpids copy a tiny bit and ported the changes to current rev. Works cool for me. What i do not understand is though: i've been collecting these nmap results for some time now - and two times more linux than windows hosts are among the comment spammers????? WTF?? Very strange.. There's even a few BSD, Solaris and Mac hosts where these spams come from ... ?
Comment #7
eMPee584 commentedoops previous patch fubared .. 8)
uuhm and there're a lot of trailing whitespaces removed obfuscating the code changes a bit..sorry *g
Comment #8
eMPee584 commentedD'oH!
put back an accidently removed piece of the new test mode check and made the getHandling() function log anonymous users again ^^
Comment #9
eMPee584 commentedthing worth doing is worth doing right *hust*
Comment #10
it-cruHello eMPee584,
thx for your patch for review. I'll take a look next days.
Constants of course I'll put into new branch. But with nmap and co I see legally problems, because in some countries (germany too!) nmap scans and co aren't allowed or a legally grey zones. Main function of PHPIDS module should be to log and block attacks. Perhaps it could be later realized as a extra activatable submodule of PHPIDS module, but not included in phpids.module file.
I think the high linux OS spammers counter which you have reported comes from infected webservers. I have also sometimes reported infected webservers to their hosting providers.
Greetz from Berlin
Gos77
Comment #11
eMPee584 commentedJo Gos77,
please take a look at http://de.wikipedia.org/wiki/Portscanner#Rechtliche_Aspekte ... nmap is NOT an attack tool itself so it should be legal in most countries. The warning message could be expanded to:
Attention: These tools may cause timeouts, out of memory situations or simply be unavailable on shared hosting environments! Furthermore, It is your own responsibility to check wether port scanning via NMAP is considered legal in your country!
Disabling nmap scanning by default should be very much sufficient, creating a new module just to put those few lines in would really be.. schwachsinn lol
And: NMAP is NOT an attack tool, however it gives very valuable information about the 'attacking' host.
Also consider: only very few hosts actually will have the nmap tool available at all as it is not usually installed on shared hosting environments!
I think the high linux OS spammers counter which you have reported comes from infected webservers.
Please, have a look at this list of systems generated from phpids report emails:
See the obscure ones at the end? Find it very hard to believe ANYONE actually pwn3d these. Mysteryyyyy... ;-)
Comment #12
eMPee584 commentednah this must be something different.. i highly suspect IP spoofing to be used by those spammers?
Comment #13
it-cruWhat do you think about $_SERVER['HTTP_USER_AGENT'] to get informations about the attackers client? I think this is the right way for the PHPIDS module.
NMAP brings too many legal risks and potential performance problems. An NMAP OS fingerprint scan can bring a different system to crash and that would be considered as computer sabotage.
Comment #14
eMPee584 commentedNot useful i believe:
REMOTE_ADDR and REMOTE_HOST point to the same machine. The combination of user agent (browser) string that is being submitted and the Operating system nmap sniffs on these machines does not make sense in many cases (MSIE on FreeBSD? yeah sure ;), which pretty much leaves return address forgery as only credible explanation.
...i just turned on
which should heighten the barrier against IP address spoofing a tiny bit. Now if this stops the spook, we know for sure.
Comment #15
patrickd commentedCustom mail subject and bodies by tokens are planned features for 7.x-2.x.
Have a look at the proper tasks