| 1 |
Hello, |
| 2 |
|
| 3 |
I'm not completely sure that I am hearing you right, so please bear with me if |
| 4 |
I miss the mark on this one. |
| 5 |
|
| 6 |
Is it just a web server? If so, it might be worth looking into mod_security. |
| 7 |
As well, I would make sure that it has a firewall setup (maybe iptables or |
| 8 |
ipchains). These two should provide some sound mechanisms for recording |
| 9 |
connections to the site as well as denying some known attacks. You should be |
| 10 |
able to find pre-built configurations for these as well. |
| 11 |
|
| 12 |
Something else you might want to do is head on over to: |
| 13 |
http://www.securityfocus.com/vulnerabilities |
| 14 |
|
| 15 |
With that site, you can look for software that is on your server that may be |
| 16 |
vulnerable. |
| 17 |
|
| 18 |
With post-intrusion analysis, something to look for may be files owned by the |
| 19 |
user that the web server is running as (or whatever other services are |
| 20 |
running). A lot of times /tmp is a default place to go for script kiddies, |
| 21 |
simply because it is a world writeable directory. If you do find executables |
| 22 |
in there, you can usually run the command "strings" on them and then search |
| 23 |
google for the miscellanious strings you find. This will often identify the |
| 24 |
exploit they used in the form of source code. I have used this approach to |
| 25 |
identify many things about an intruder in the past, it actually works pretty |
| 26 |
well. |
| 27 |
|
| 28 |
I'm not sure that rkhunter or chkrootkit will help much considering they |
| 29 |
function best if they were installed before the intrusion, but they may still |
| 30 |
be able to provide you with info. On redhat, I seem to remember there being |
| 31 |
a way to check file integrity using the rpm tools. Unfortunately, I don't |
| 32 |
remember since I haven't touched redhat since I landed on gentoo. ;-) |
| 33 |
|
| 34 |
If they haven't been able to cover their tracks, you may find an IP address |
| 35 |
somewhere that connected to your box. You may want to do lookups using dig, |
| 36 |
nslookup, whois, or whatever tools you have available. You should be able to |
| 37 |
identify the ISP, if not the exact company with the offending box. As well, |
| 38 |
you may use grep on /var/log and usually find other ways they tried to get in |
| 39 |
(this is usually a sign of a targeted attack as opposed to just an automated |
| 40 |
attack that discovered your redhat box). |
| 41 |
|
| 42 |
Another fun place to use an IP you have discovered is on this site: |
| 43 |
http://www.dshield.org |
| 44 |
|
| 45 |
I hope this helps, I wanted to provide more rather than less as incidents can |
| 46 |
get pretty sticky with politics and pointy fingers. |
| 47 |
|
| 48 |
Good luck, and happy hunting! |
| 49 |
|
| 50 |
Robert Larson |
| 51 |
|
| 52 |
|
| 53 |
On Friday 20 January 2006 08:30 am, Jean Blignaut wrote: |
| 54 |
> Got feedback from the firewall guy: |
| 55 |
> According to his snort logs the ip I was told did the portscan was not |
| 56 |
> infatc the culprit, the reverse lookup domain name for that ip is |
| 57 |
> responsible but at this stage it still has an old ip pointing to an old |
| 58 |
> redhat 7 box that's over due for retirement but still has a few |
| 59 |
> straggling websites (old big and buggy - one in particular is written in |
| 60 |
> old perl cgi scripts) It seems my problem might just be bigger than I |
| 61 |
> thought any ideas on how I might secure a red hat 7 box (muhahahaha) |
| 62 |
> |
| 63 |
-- |
| 64 |
gentoo-server@g.o mailing list |
Archives