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
smime.p7s
Description: S/MIME Cryptographic Signature
