Intrusion monitoring - sugarcrm (and how to secure it)

[TakeMarket]

Let's face it: There is a lot of junk out there - in cyberspace - a lot of noise - and everything is not dumb teens with a hack bot/script that they found somewhere or even worse.... there is also a lot of just junk - junk traffic..

The point is since we ran the first test install of sugarcrm on our servers the message " FATAL SugarCRM - If you see a whole string of these, there is a chance someone is attacking your system." has appeared in the sugar crm log even before the "beast" was set free on the Internet. Some of it is probably pure junk traffic - and some of it we know is badder things (not logged by sugarcrm,but by our own systems) What we have seen so far sugarcrm have no real functionality to log/monitor/filter the traffic (and in report in detail for example reverse...)

So the message is not very reliable in our minds, because you cannot tell what is what... (useless?)

So how/what is the best way of implementing/monitoring the real intrusion attempts on the server systems running sugar in your minds?

What are you people using to monitoring sugarcrm security and preventing intrusion? Using SNORT or.....?

What implementation/method/intrusion monitoring do you/your organization consider is the best "hackersmacker method" for sugarcrm servers and letting the bad guy's stay out in the cold?

We would be happy if people in the community joined in on this thread as it is very interesting and never out-of-date subject as this thread could turn out to be be great resource for every body using sugarcrm - especially for all newbies joining sugarcrm and for smaller organizations that doesn't have a million dollar budget for security.

So grab your keyboard folks and share your experience and knowledge!


--------------
Update:

We are bit surprised that only a very few companies has joined in on thread when more than 200 companies has read the thread, come on folks!
We cannot be the only company in the very large sugar community that has great security concerns about todays Internet weather and how to secure a crucial business tool as your crm system is - in this case sugarcrm from criminal activities, so arm your selves with your keyboards and start writing.

[susiewilliams]

Hi there,


Rob Lackey, our Security Guru here at SugarCRM, presented a great lecture on this topic at our recent Global Developer Conference. He's going to reprise his talk on July 11th in a free webinar to the Sugar Dev User's group. I would encourage you to sign up for this event...it's going to be very informative.

If you can't wait until July, let me see if I can coax Rob into posting a few of his thoughts here on this forum thread.

-Susie

[TakeMarket]

Hi Susie,

Yes, that would be excellent if you could get Rob to share his wisdom - it would be a great start on this thread!

We would also be happy to attend to the web cast of course.

[alevesque]

I would like to read this too.

Sugar has become a valuable tool to our organisation.
July may bring version 5 who's going to make us look at our setup.
This topic is of interest to a lot of us, as we are in the planning process for this transition.

Thank.

[RLackey]

Thanks for the plug Susie! Always happy to have a jam session about security and Sugar.

TakeMarket's concern is spot on - the Internet is a very scary place right now. More than just "junk" traffic that is benign beyond the system resources that it wastes, increasingly production environments that are publicly exposed can anticipate more and more deliberately harmful traffic. On any given day, our public machines can see 10-20% of their total web requests be linked in some way to malicious intent. With an Internet this rife with trouble, TakeMarket is well served to look into some form of Intrusion Detection / Prevention for their Sugar implementation.

Fortunately for us, some of the best tools out there for IDS / IPS also happen to be Free or Open Source software. In this thread I'll attempt to explore in installments applying these popular software packages to a Sugar implementation. Hopefully this will give way to a good dialogue about the security concerns around a Sugar implementation and the counter-measures we can put in place to protect our data and our uptime.

The single easiest software package that can be implemented on a machine hosting Sugar is Mod Security. At the Global Developer's Conference it figured heavily in our discussion about security; it is an easy-to-install application firewall that works as a DSO for Apache. In this thread we'll go through what it does and how to install it.

mod_sec is an application firewall that sits between the client and your Apache server. Before the request hits Apache or PHP, mod_sec can inspect the request and apply a ruleset that you specify. Extremely fast (written in C), this can be deployed with a sizable ruleset without significant impact on performance. Some drawbacks are 1) yet another DSO to patch and 2) it is available for Apache users only.

Installing mod_sec has become very simple. It is available in the main Ubuntu repository in the form of two packages "mod-security-common" and "libapache2-mod-security." It is also available with yum under "mod_security." For RHEL or Windows users, you'll need to compile it yourself with gcc. For compiling for source, this is a good procedure:

***WARNING: Always test before putting in production. Do not follow this procedure unless you have successfully performed it on a non-production machine with similiar configuration.***

Install Prerequisites

1. Install Apache2.




Download Software

wget http://www.modsecurity.org/download/...e_2.x.x.tar.gz
tar -xzvf modsecurity-apache_2.x.x.tar.gz
cd modsecurity-apache_2.x.x/apache2


Compile

/usr/local/apache2/bin/apxs -cia mod_security.c



Add DSO to Apache

1. Add or uncomment the following lines to httpd.conf.

LoadModule security_module modules/mod_security.so


Restart Apache

Note: This is a DOWNTIME procedure

/usr/local/apache2/bin/apachectl -t
pkill -HUP httpd

Next installment, we'll talk about what you can do with it to detect and prevent web-based intrusions.

Best,

Rob

[TakeMarket]

Hi Rob!
Thank you for joining in on this thread!

It's a very interesting information you are writing, however for corporate organizations like us who are "stuck" for good and bad to the "Microsoft way" and running their platform including IIS - what options do we have to secure specifically the SugarCrm implantations on ours servers from malicious traffic?


The mod security looks like a great tool, but 1) it's only built for the Apache web server and 2) we are already running application firewalls with IDS (which obviously is not enough..) on both clients and servers which in return are of course protected by other hardware on the network/s.
So for us the interesting part is to find out on how to monitor, capture and block bad and "hazardous" traffic before it gets to late on the Sugar instance/s on servers which normally runs on port 80/443.
Port 80 as most of us know is one of the hardest ports to secure, for one of the many reasons is of course that it's always "on" and open to all traffic on the net making it very hard to cloak/monitor/secure. There are many way's of doing this and what we of course are seeking is what is the best way of doing this for for Sugar.

Because applications are different just like cars differs from each other (Models,manufacture/brands, the way they are built etc.) even though they got 4 wheels, doors,trunks and a motor and may look very similar in some ways, but they ain't and therefore; one security solution that fits for a specific application platform, may not really be a good solution/idea for another.
Just like you cannot use exactly the same type of brakes on all cars - one size does not fit all..............

Thinking of others than our selves also, many smaller organizations running the ms platform do not use AD as a tool in their implementation for administration and security, thus dividing the question in 2:

1) What are the best way for securing their Sugar Crm when running AD? *


2) What are the best way for securing their Sugar Crm when not running AD, but a "standalone platform"?

*For those who don't know what AD is=Microsoft Active Directory. Explanation can be found here -->Windows Server 2003 Active Directory

[cgstevens]

There has also been some community discussion regarding the separation of the internal and external pieces of Sugar. Those discussions indicated that some of the campaign handlers (click-through lookups, removeme, etc..) could remain on a public server and the core of the application could reside safely (or more safely) behind the firewall. It's also possible to dig down and find out just what database tables these external parts would require and create a new database user with just the right permissions and nothing more.

I looked into this briefly a few weeks ago and by the time you track back all the included files, you have to copy a large portion of the application to the external world. I still think it's a good approach as part of a layered approach if it works for your users.

I haven't heard much more on it from the community since those original discussions. Maybe we could pick Rob's brain about it when he's done with his excellent mod_security discussion.

Regards,
Chris

[TakeMarket]

There has also been some community discussion regarding the separation of the internal and external pieces of Sugar.
Those discussions indicated that some of the campaign handlers (click-through lookups, removeme, etc..) could remain on a public server and the core of the application could reside safely (or more safely) behind the firewall. It's also possible to dig down and find out just what database tables these external parts would require and create a new database user with just the right permissions and nothing more.

I looked into this briefly a few weeks ago and by the time you track back all the included files, you have to copy a large portion of the application to the external world. I still think it's a good approach as part of a layered approach if it works for your users.

I haven't heard much more on it from the community since those original discussions. Maybe we could pick Rob's brain about it when he's done with his excellent mod_security discussion.

Regards,
Chris

That's a very interesting concept!



Actually it would be very nice if SugarCRM possible could repack the manual installing package for this kind of installation / eg. "install folder back end"/"install folder front end" with the correct necessary files together with a installation manual for this specific more advanced configuration/installation.

Yes!
That would be VERY interesting to hear from Rob on how to proceed with an installation n configuration like you mention.
It's very interesting because you can the run a pretty secure (?) back end system setup which of course not will be exposed in the same way to hackers and other "lamers" out there in the cyberspace, as directly connected servers are .

[RLackey]

The sorts of counter-measures you would put in mod_sec are certainly applicable to any application firewall, open source or otherwise. Based on your input, TakeMarket, I'll try to highlight some filters you should consider adding to better protect your Sugar installation.

1) URL encoding validation

Especially applicable for folks with customizations, a filter excluding bad URL requests is a helpful layer to add to your application. Many attacks hinge on the introduction of backspaces, etc in order to find a spot to inject something malicious. Restricting what metacharacters are allowing in a URL to only genuinely used strings can provide a blanket defense against a number of different types of attacks.

mod sec example:

SecFilterCheckURLEncoding On
SecFilterForceByteRange 0 255

2) SQL injection

Scan the payloads of all POSTs for blatant injection attempts. Prohibiting payloads that contain SELECT, INSERT, or DROP TABLE / DATABASE statements can additionally secure against an unknown threat.

mod sec example:

SecFilterSelective POST_PAYLOAD ".*select.+from[^<]*"

3) Known offenders

For your particular application firewall solution, find someone who is maintaining a blacklist of known exploited IP addresses. Deploying a good blacklist of zombie machines can go a long way to reducing the amount of bad traffic you receive.

For mod sec users, Got Root (http://www.gotroot.com) actively maintains some of the best lists for web admins.

4) Fully formed requests

Require that every request is fully formed. Since the userbase for a Sugar implementation is always a (relatively) known quantity, take steps to make sure only those types of users can access your Sugar implementation. For most implementations, restricting access by IP is not possible. However, requiring every request to be fully formed (as it would be from any modern browser) can also cut a bulk of the malacious noise down.

[RLackey]

For Active Directory, I don't recommend ever having a domain controller publicly accessible. Directory services should primarily be an intranet service, and I don't think there is ever a circumstance when a DC should be accessible to the world. Hence, Sugar should never be on the domain controller.

For securing a Sugar implementation on Windows, the intrusion counter-measures you would deploy are applicable equally to machines that are and are not part of an Active Directory domain. AD, though, can make the deployment of those counter-measures much easier.

1) Make sure only web requests can reach the Sugar server (80 and 443). On a Windows machine, one must be very careful not to expose any other ports like Remote Desktop, NetBIOS, etc. If SQL server is running on the machine, make sure it is not available to the public as well.

2) Implement some application layer filtration of what goes to IIS. This can be local or network based, but make sure that every POST at least gets screened by something before hitting IIS.

3) Patch frequently. Painful, but necessary.

Best,

Rob