[Tfug] Server Compromise

[Ronald Sutherland]

I've split things into two boxes, one has stuff like svn, cvs, 
file-server and has no open ports at all, although I can switch on ssh 
if needed. The other has http, smtp, vent-server and so on. I try to 
figure out what has risk and if I can put it on the exposed server. A 
cron job runs every hour (for most stuff) and pulls different areas from 
svn/cvs (I'm still moving to svn). Another thing I do is have two 
networks, an inside (192.168.0.x) and outside (my static IP's), and I 
treat the outside as a war zone (which it is). On the inside I am more 
or less open, but not centralized, so no one password can compromise 
more than one system (I hope). I would like cvs and svn to the outside 
but that would have to go over ssh, I would not trust svn or cvs 
methods. I should note that when last I had ssh enabled my log files 
filled fast, the war with ssh was bad at that time about a year ago. 
There are tricks that can be done with ssh to forward most any service, 
and make it take keys and not passwords, thus making it very resistant.

My first experience with getting a rootkit was on BSD so I don't think 
its inherently better (my view anyway). I gained experience with what 
works and what does not with time, and expect thats true of all. I can 
probably use BSD now with much better results. I've also played with 
Winblows, but enough...

Chris Hill wrote:
> The open ports are
>
> jabber (forget)
> sshd (22)
> ftp (21)
> http (80)
> subversion (3690)
>
> Apache/2.0.55 (Ubuntu) mod_python/3.1.4 Python/2.4.3 PHP/5.1.2 Server
>
> That's it.
> Of those ftp and jabber are most def not an issue.
> sshd is a potential risk.
> http is a potential risk.
>
> It is an internal machine with trac and subversion projects. It has a 
> couple other little things happening. Nothing really public facing. 
> There is a mail server, but those ports aren't even open, but it can 
> send mail out (subversion log messages and trac ticket emails).
>
> I can't tell you that i've heard of a kernel security level.
>
> Overall I know that somewhere something bad happened that comes back to 
> bad sysadmin. Very possible its an issue with a compromised user 
> account, potentially from a user's account being hijacked/keylogged 
> (happened in the past). Secondly i think it may be an issue with a 3rd 
> party web app (WordPress, PhpMyAdmin) that was exploited.
>
> We now have only http and subversion publicly accessible. This should 
> tell us if its a web exploit or ssh.
> C
>
> Predrag Punosevac wrote:
>   
>> What kind of server do you run? http, mail server, data base?
>> What kind of firewall do you have? What is the kernel security level (
>> I hope this exist in Linux world) How did they get into your server if
>> all but few ports are closed? The only way to block the BSDs is fake
>> demands from the server that would completely block your ports but
>> still there is no theoretical possibility that properly run BSD box
>> gets hijacked.
>>
>> Note for the future use! I would not run mail server on the http or
>> database server period.
>> If you are running mail server the content must be scanned by clamov
>> or similar software.
>> That is the sole source of security risk.
>>
>> Another thing? What is the partition of your Linux box. Outside users
>> should not have access to anything but the /var part of partition.
>>
>> Why is server running Ubuntu? You might want to switch to OpenBSD if
>> the server content and services are so important.
>>
>> Sounds to me that your troubles are home made.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 9/27/07, Chris Hill <ubergeek at ubergeek.tv> wrote:
>>   
>>     
>>> Hi all,
>>>
>>> I've got a major headache today, looking to see if someone might be able
>>> to help. We've got a server, its been compromised with a phishing scam.
>>> It looks like its very possibly has been rooted. I cannot fully turn off
>>> the box but we are pulling all non-essential services off the public
>>> net. If anyone can help me figure out how bad things are that would be
>>> really cool.
>>>
>>> I am working on the assumption we are rooted, mainly because the user
>>> has copied files as root to the box into /tmp and /var/www. I removed
>>> the /var/www files and he put them back and made it so that i cannot
>>> delete them( even as root ) . I'm also assuming that my ls, lsattr,
>>> chmod, chown, chattr, etc. files are hacked, which is why i cannot
>>> delete the /var/www files.
>>>
>>> If you're able to look at the box and see if you can help me delete
>>> these files and figure out what's going on, that'd be great!
>>>
>>> Thanks
>>> C
>>>       
>