1

So I'm setting up a small e-commerce app, and am thinking what happens if the server is compromised. We are selling software so potentially an intruder could generate themselves some free serial numbers (not a great worry), grab the customer database (more of a worry) or do something sneaky like redirect legitimate payments to a different paypal account (which falls somewhere between the two in terms of worry).

I've been thinking I'd like to know if the PHP got altered. Would that pick up most intrusion attempts, and (while I'm at it) how would I pick up alterations further down the server stack? Is there a standard way of auditing changes to content?

The most secure option would presumably be a scheduled task on a different server that logs in periodically and compares the content to its own record. Is there an off the shelf, free tool that does this?

Improve this question

4 Answers 4

Reset to default
1

I assume you are keeping your customer data in some SQL database. It is typical for attackers to use techniques like SQL Injection to extract data from database. Since this technique doesn't need to modify any files on server you won't be able to spot this kind of attack. As I understand grabbing customer database by attacker is the scenario you are most worried about. Moreover in this case when there is a data breach it may be too late, so you should verify security of your app in the first place. You could also use WAF (i.e. ModSecurity) as detection or/and protection measure.

Monitoring system integrity is also good idea, but it is not sufficient.

Improve this answer
3
  • I'd also add that you should log all SQL queries. Once you've amassed enough data, it becomes relatively trivial to build scripts that find "unusual" requests, although you'll always have false positives. In the event of an attack, it makes discovering the injection vector much easier!
    – Polynomial
    Commented Apr 30, 2012 at 21:04
  • 2
    I would be careful with logging all SQL queries. SQL queries can contain sensitive data (i.e. passwords or PII). If you log them, you are creating another one, possibly critical, data store you should protect and monitor.
    – pgolen
    Commented May 1, 2012 at 6:50
  • It should go without saying that all logs should be kept in a secure location. You never know what they might contain!
    – Polynomial
    Commented May 1, 2012 at 7:20
1

I think this is the wrong approach. The problem is that your application should not be writable. A notification that your website has been modified is not as good as preventing it in the first place. Make all files in the web directly readable and executable by Apache, but owned by another user. One of way doing this is chmod 550 and put Apache in the group.

A WAF like ModSecurity is a good preventive security measure, so is regular testing your site for defects. There are open source options such as Wapiti and Skipfish which have to be run manually. There are free scanning services such as Sitewatch, which I help develop.

Improve this answer
2
  • This is a good point however is it not possible that an attack could compromise the apache account, and then escalate to a user account? so there is still a place for integrity checking
    – Sideshow Bob
    Commented May 1, 2012 at 11:16
  • @Sideshow Bob Apache should not have ownership or write access to the file. If they have access to the Apache account, they don't have very much.
    – rook
    Commented May 1, 2012 at 14:18
1

For host-based IDS, there's tripwire (open source), tripwire (commercial), LIDS and many more tools which build a fingerprint database of your current files.

Although most software package managers (inclusing RPM) can very the integrity of files, it's tricky to run the verification against a remote database.

In addition there's malware detectors (using fingerprints and anomoly detection) including chkrootkit and rkhunter

Since an attacker can potentially compromise your system without modifying files, then including honeypot data is a great way to detect when a system is compromised (e.g. set up your own 'customer' accounts with email addresses and monitor the mailboxes).

Improve this answer
0

Good attacks only use memory. If you are troubled about static content changes - use a filesystem check that alerts you after a change to a file. fam, aide, samhain are some of these.

If you use RPMs for your installation you could check wether the rpms are still "original" with rpm -V packetname.

Improve this answer
4
  • 1
    I recently attended a talk about volatile in-memory HTML5 attacks that never touch the disk. The guy giving the talk worked for a major AV vendor, and was quite clear in saying that we cannot defend from this type of attack yet, and we may never be able to. Some of the high quality JS obfuscators/morphers are incredible, and the bad guys are always one step ahead of the detection signatures. Be wary.
    – Polynomial
    Commented Apr 30, 2012 at 21:01
  • But HTML(5) is client-side technology and it has almost nothing to do with server. I agree though that attacker could use client side attack to extract data from application, but it is different kind of attack than, say, SQL injection. Using SQLi I am able to get data of all users existing in attacked system, using client side attack I usually can get only that data which belongs to attacked user.
    – pgolen
    Commented May 1, 2012 at 6:56
  • @pgolen: does that mean that service proviers should not bother testing their site for XSS vulnerabilities? Or not overload websockets / XDomainRequest / XMLHttprequest ?
    – symcbean
    Commented May 1, 2012 at 12:18
  • @symcbean No, but this means that you probably won't notice any of this attack only by monitoring integrity of server side files.
    – pgolen
    Commented May 1, 2012 at 16:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .