Security breach, or server burp?

Visitor nails secret /path/to/file/

[Pfui]

Something just happened that I've never seen before and it's got me stumped and more than a bit spooked. (Aside: We're running Apache 1.3.x on an old Linux box, with Perl/CGI; no PHP.)

A newish visitor from a 'free ISP' in S. Cal using WIN/Firefox, instead of looking for, say --

/pages

-- actually looked for --

/path/to/file/public_html/pages

They got a custom 404, proceeded to locate the correct directory, and thereafter browsed without incident. (And for the time being, anyone hailing from that free ISP will be redirected to another server where they'll see a message to contact me.)

The creepy part is:

They got /every/single/part/of/the/filepath RIGHT.

There's NO WAY they could know that entire combination. The ONLY people who do are my SysAdmin husband, myself and one trusted consultant who's never had access. The box is co-located, not shared. And the full filepath never appears in any publicly accessible pages, scripts, etc.

I grepped the site's access logs going back a few months and the ISP appears on only two other days, but there are no requests for even part of the filepath by anyone. The webserver's logs are normal. Doing a "ps awx" (my Unix is very limited:) shows all's well, no odd processes, no atypical readings.

So -- d'ya think the server burped? Or --?

If there's anything we should run, check or test to be sure one way or another about the server's integrity/security, TIA for any/all additional info!

-Annie

[g1smd]

I went to a site last week and they had some sort of PHP error. It showed:

Warning: main(includes/navig.php): failed to open stream: No such file or directory in /vhost/vhost6/m7/jp/www.example.com/www/index.php on line 109

Warning: main(): Failed opening 'includes/nav.global.php' for inclusion (include_path='.:/usr/share/pear') in /vhost/vhost6/m7/jp/www.example.com/www/index.php on line 109

Now. That gives a lot away about the site.

[jdMorgan]

There's a setting in many scripting languages that says, "show errors in the browser" or "only log errors on the server." While it is easy/good/convenient to display errors in the browser, it's really only safe for a development environment and should be turned off before going live.

You might want to ask about this in the appropriate scripting forums. However, I concur that that user should be blocked, since one way or the other, he/she was 'fishing around' in un-linked URL-space.

Also, make sure your anonymous FTP accounts (if any) are locked down; If you don't use them, make sure they're disabled.

Jim