Date: Tue, 25 Aug 2009 19:33:18 -0400 From: Steve Bertrand <steve@ibctech.ca> To: Adam Vande More <amvandemore@gmail.com> Cc: Paul Schmehl <pschmehl_lists@tx.rr.com>, Bill Moran <wmoran@potentialtech.com>, Colin Brace <cb@lim.nl>, freebsd-questions@freebsd.org Subject: Re: what www perl script is running? Message-ID: <4A9474BE.6020501@ibctech.ca> In-Reply-To: <6201873e0908251511q643f3662nc73f264cbfcfe645@mail.gmail.com> References: <4A924601.3000507@lim.nl> <25132123.post@talk.nabble.com> <20090825082604.41cad357.wmoran@potentialtech.com> <25134277.post@talk.nabble.com> <E668BECE594402B585544841@utd65257.utdallas.edu> <20090825120504.93a7c51d.wmoran@potentialtech.com> <6201873e0908250921w46000c2by78893a1c5b581e78@mail.gmail.com> <20090825130616.20ab0049.wmoran@potentialtech.com> <6201873e0908251237n5c819d9ag36f867b5e68e258c@mail.gmail.com> <20090825154358.7c792d3a.wmoran@potentialtech.com> <6201873e0908251511q643f3662nc73f264cbfcfe645@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms070308040704070201050709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Vande More wrote: [ huge, huge snip ] > You said block by destination port. What you presented is not this, > although it gives give a functional environment of it. Sorry for the > pedantic pursuit here, but IMO terminology is important here. I've read this thread on a 'best-effort' basis throughout the day. Although I can *personally* translate what Bill's excellent feedback is saying into functional protection, I have to say that your statement quoted was the 'politically correct' way to express it. We've (ie: I've) been compromised in the past (several times), and experience based on having an installed Perl-based httpd program tells me thus: - it is likely a PHP script that was the root cause - it is likely that the script had access to a MySQL database - bulletin boards, mailer apps and blog software was often the culprit - it's a common hack, the Perl code that is installed can be downloaded anywhere We have a multi-site hosting environment, so we see things like this from time-to-time. I can't remember for sure if it was this list or not, but I know I've posted "what to look for" someplace. In this case, OP, look for: - directories named as such: -- ... -- . .. -- . . -- etc, particularly under: -- /var/tmp -- /tmp -- or anywhere else the [gu]id of the webserver could possibly write to There are other similar problems that are prevalent out there that someone running a web server may run into (one I've seen recently). It inserts HTML redirects into files (or directly into a MySQL table, in situations where links are generated dynamically) that direct the browser to foreign pages (presumably so that the browser will inadvertently download rogue programs into the visiting computer). This has had the effect of having Google block the page, and for client relations, it doesn't look good. Any time we've seen this, we refer the client to their web developer for assistance (heh). This such infection has noticeably been caused by server-side PDF management software, and a specific PHP video management software. We've never found that such 'kiddie/automated' hacks tried to manipulate or steal any information directly/initially, even after reviewing the code. With that said, I firmly agree with Bill that you should/must replace all passwords both on the Unix side of things, as well as within MySQL. tcpdump(1) is your friend. On the firewall side of things... I am on the fence with both Paul and Bill's comments as to whether having protection on each machine is a bonus or a failure. This really depends... and it depends on the environment which and where the box is logically attached. Given that I'm in an ISP environment, I don't want to manage ACLs for web servers on my network edge routers, so it's best that I contain them locally to the hosted web box itself. In other cases (such as an enterprise environment), it would be easier to manage such ACLs at the network perimeter. For a home box, a firewall-per-box may lead to better understanding and experience. What I haven't read in this thread so far is the term 'state', relative to stack protection. For instance, if I were to: % ipfw add 10 allow all from any to me 80 keep-state % ipfw add 15 deny all from any to any ... it would dynamically allow all requests to my web server (fw running on the host itself), would allow all responses back to the client (regardless of the port they used to send the request (because of state)), but it would deny everything and anything else, inbound and outbound. Note that in heavy environments that keeping state can have it's own detrimental drawbacks, which there is no need to get into here. These drawbacks are generally why one might decide not to block everything at the network edge, but on the box itself. Steve --------------ms070308040704070201050709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII/zCC AtowggJDoAMCAQICEEs5xg/J3t77QWJ4SatV1HcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUwNzIzMTYxMFoX DTEwMDUwNzIzMTYxMFowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0G CSqGSIb3DQEJARYQc3RldmVAaWJjdGVjaC5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAJSTRAjP1RVa87/mnZn+PBTbENgyhhBJ4rWApmaNcthzRdk2DB/49KrXx3EQP60w Lj4KU0DFkiGNVj9BnVxRAx/WDXKxGC3uGGEG6gjyWv8KFMWMsH9mL7y7uNow1HueT6pZUf9o yY8Ewd+01QpGi7FfXOae7lGHhbEwnEJGwz08ytRfLmH0KtEzlZanZZhwDGX5s1kIHnyxdACh 3byXY6Z2bOrx0rcrQHCnHJppxddR60F7igjaMuBFstE51h9XTgXDNKJbglqTug5ghGihNuP6 VsBN7ue62y96UGIE22TvKEcAQ665vQGjHqZeSzZYy+hWNOa27pWFmhlqFjx0x8MCAwEAAaMt MCswGwYDVR0RBBQwEoEQc3RldmVAaWJjdGVjaC5jYTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4GBAMOmjxjp2Xzk6ZHLwTgFDzVhm98RjRT3UXotKjNIR7SgwfWF5wkJrx4I+dXu ui5ztMEq4bTTRgJ344MqE6uZiZlg+tBIFHZGCJfKdzsX4QuV2jmw0sR5dMaYxG6tlDB0YUMv gTqzV7ZDpiusTMOZe9pP1PdxFhOcIJXtMQDj5LhuMIIC2jCCAkOgAwIBAgIQSznGD8ne3vtB YnhJq1XUdzANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDkwNTA3MjMxNjEwWhcNMTAwNTA3MjMxNjEwWjBCMR8wHQYD VQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBzdGV2ZUBpYmN0 ZWNoLmNhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlJNECM/VFVrzv+admf48 FNsQ2DKGEEnitYCmZo1y2HNF2TYMH/j0qtfHcRA/rTAuPgpTQMWSIY1WP0GdXFEDH9YNcrEY Le4YYQbqCPJa/woUxYywf2YvvLu42jDUe55PqllR/2jJjwTB37TVCkaLsV9c5p7uUYeFsTCc QkbDPTzK1F8uYfQq0TOVlqdlmHAMZfmzWQgefLF0AKHdvJdjpnZs6vHStytAcKccmmnF11Hr QXuKCNoy4EWy0TnWH1dOBcM0oluCWpO6DmCEaKE24/pWwE3u57rbL3pQYgTbZO8oRwBDrrm9 AaMepl5LNljL6FY05rbulYWaGWoWPHTHwwIDAQABoy0wKzAbBgNVHREEFDASgRBzdGV2ZUBp YmN0ZWNoLmNhMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAw6aPGOnZfOTpkcvB OAUPNWGb3xGNFPdRei0qM0hHtKDB9YXnCQmvHgj51e66LnO0wSrhtNNGAnfjgyoTq5mJmWD6 0EgUdkYIl8p3OxfhC5XaObDSxHl0xpjEbq2UMHRhQy+BOrNXtkOmK6xMw5l72k/U93EWE5wg le0xAOPkuG4wggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoT EVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERp dmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcN MTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f 6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRw Oi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8E BAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqG SIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEs5xg/J3t77QWJ4SatV 1HcwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDkwODI1MjMzMzE4WjAjBgkqhkiG9w0BCQQxFgQU5MRkirZIKMQjZwHYhXg2VYjz nGEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBLOcYPyd7e+0Fi eEmrVdR3MIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBLOcYPyd7e+0FieEmrVdR3MA0GCSqGSIb3DQEBAQUABIIB AEEL7pc5OPU9JQu21LS6oNxVYQUzREl761qgUh6VZhNqzrfPb2zgxha3e4cxp+Oy2IRyg9b5 PvynzuljkkpFFF4ANGz13iNUZ11shUCECr9s85doWYomz8GCCmo32W3+QzrXBccmawWcoA8t tfaeEHfDlfklR9/9TJpnHAWzoU2seNwtmipdg8t2bV3DMX9pr6YvnDd+ZguPig0ejGqLuw1m XbNHv0H6oZrF9ysorPSQMdFW1EFw3ysM6RUJNG/IPJ5sX8RgEawLs6zfYxYoTyE8+MYYSH01 GtTnwqPJanJCj27y3B02vaMWda7WKQaDNMxR4CY1ohQK2NKspHcainQAAAAAAAA= --------------ms070308040704070201050709--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A9474BE.6020501>