Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
A) A _really_ dumb script-kiddie is checking you, thinking he's got a IIS webserver. Since it seems to combine several known exploits together, this may be a scanner of some sort, which would normally be used on one's OWN site to test it- instead someone use it on you.
B) The slightly newer x-site scripting exploit mixxed in with A.) (because of the vti_ crap) I had someone browsing my site, looking around, cool..... just before he left he fired off one of those.
C) Yet another version of the IIS unicode exploit is making it's rounds. I posted it to usenet because people kept asking about it there. This doesn't appear to be a worm, since the worm that follows similar parterns only exibits a very limited amount of code.
I moved my server up to 443, SSL'ed it just because I got tired of seeing that kinda stuff. If you're gonna attack me, _at least_ ID my system correctly. All the point -n- click scripts I've seen to do this kind of stuff don't bother with the https port, just straight http, and most people don't rewrite it to either. Take note of the IP address they're coming from. If you want to get fancy, make a custom error doc for anyone hitting on the /scripts/ directory (since an Apache server shouldn't have one by default) telling them just what you think of them. Just make sure the direcory is never linked so that legit clients can't click to it. Then you'll know anyone landing in it is looking specially for it, most likely indicating an attempt to be naughty.
That's what I did.
I checked, those are COMCAST addresses, people I've had trouble with before (if you didn't change the address, which it doesn't look like) so I don't think complaining to them will do any good. You can do this:
#Or whatever your webroot dir is
<Directory /var/www >
Order allow, deny
Allow from all
Deny from comcast.net
</Directory>
# And maybe one of these for the directories they like to play in
# Put something colorful in go-to-hell.html
<Location /scripts/*>
Deny from all
ErrorDocument 403 http://yer.site.net/go-to-hell.html
</Location>
If you've got PHP going, you should be able to use it in your error document too, and really be ready when they come, like log their IP's, insert their IP in a iptables black-list or a .htaccess list, or even lauch nmap against them, etc.
I already know that they're from comcast's IP block, however, if I block comcast.net then even I couldn't access my own site (not what I want). How do I do the iptables black-list?
jayjwa: part of my server is on ssl. however, I cannot move my server completely to https://servername.com because people who legitimately access my server have a hard enough time not typing in the www. prefix.
Although this is a fine though, it is by no means an option. For one, each and every time you get a visitor apache is going to have to check DNS and verify the IP. Thats going to slow things down.
I suggest you focus your time on securing your system rather than worrying who is scanning your box. They can scan all they want, and you can never stop that. What else do you have running on the maching?
#Or whatever your webroot dir is
<Directory /var/www >
Order allow, deny
Allow from all
Deny from comcast.net
</Directory>
Okay... I found something where iptables can block by string matching at linuxsecurity.com. I downloaded the kernel source (version 2.4.21), iptables 1.2.7a, patch-o-matic-20030107, and FWSnort (contains the patch for string capability). I followed the guide exactly however, when I tried to run "make KERNEL_DIR=../kernel_src", I get the following error:
[raj@chopin iptables-1.2.7a]$ make KERNEL_DIR=../linux-2.4.21
Extensions found: IPv6:ah IPv6:esp IPv6:frag IPv6:ipv6header IPv6:hbh IPv6:dst IPv6:rt
cc -O2 -Wall -Wunused -I../linux-2.4.21/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o extensions/libipt_ah_sh.o -c extensions/libipt_ah.c
In file included from ../linux-2.4.21/include/linux/config.h:4,
from ../linux-2.4.21/include/linux/netfilter_ipv4.h:8,
from ../linux-2.4.21/include/linux/netfilter_ipv4/ip_tables.h:25,
from include/libiptc/libiptc.h:6,
from include/iptables.h:5,
from extensions/libipt_ah.c:8:
/usr/include/linux/autoconf.h:1:2: #error Invalid kernel header included in userspace
make: *** [extensions/libipt_ah_sh.o] Error 1
[raj@chopin iptables-1.2.7a]$
I thought I was pretty linux savvy but kernel stuff just boggles my mind and I was hoping someone ran into this error, or can figure out what the hell is wrong.
It would probably be easier and less of a load on the server to use mod_rewrite to do that instead. Checking every packet for certain strings is a serious chore. Just turn on the rewrite engine, and add a rewrite rule that matches anything that has cmd.exe in it. That should handle most of the IIS exploits that try to fire back a command shell.
Btw, just briefly glancing at the exploit, that looks like several Nimda scans to me. While annoying, you will likely end up wasting a significant amount of resources in trying to stop harmless scans like that.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
