Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 3840 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Tightening Admin web server

LewisRosenthal
Astaro v6 (Novell Security Manager):

I was recently port scanned by SecurityMetrics without my knowledge or consent. Annoying and rude, yes. This was done at the request of one of the merchant account providers for one of our hosted websites.

Anyway, on my admin port, they came back with the following:

                 Synopsis : Debugging functions are enabled on the remote web server. Description : The
                  remote webserver supports the TRACE and/or TRACK methods. TRACE and TRACK are HTTP
                  methods which are used to debug web server connections. In addition, it has been shown that
                  servers supporting the TRACE method are subject to cross-site scripting attacks, dubbed XST
                  for "Cross-Site Tracing", when used in conjunction with various weaknesses in browsers. An
                  attacker may use this flaw to trick your legitimate web users to give him their credentials. See
                  also : http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
                  Apache Week. Security issues force release of 2.0.44 US-CERT Vulnerability Note VU#867593 Solution:
                  Disable these methods. Risk Factor: Medium / CVSS Base Score : 5.0
ies-lm 5 (CVSS2#AV:N/AC:L/Au:N/C[:P]/I:N/A:N) Solution: Add the following lines for each virtual host
                  in your configuration file : RewriteEngine on RewriteCond %{REQUEST_METHOD}
                  ^(TRACE|TRACK) RewriteRule .* - [F] Alternatively, note that Apache versions 1.3.34, 2.0.55,
                  and 2.2 support disabling the TRACE method natively via the 'TraceEnable' directive. Plugin
                  output : The server response from a TRACE request is : TRACE /17loj9st.html HTTP/1.1 Host:
                  www.domain.com Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png,
                  */* Connection: Close Accept-Language: en User-Agent: Mozilla/4.0 (compatible MSIE 6.0
                  Windows NT 5.0) Accept-Charset: iso-8859-1,*,utf-8 Date: Wed, 28 Jan 2009 21:14:36 GMT
                  Pragma: no-cache CVE : CVE-2004-2320 BID : 9506, 9561, 11604 Other references :
                  OSVDB:877, OSVDB:3726
I haven't moved this particular installation to v7 for a variety of reasons, but aside from that, what to do? Any suggestions?

TIA


This thread was automatically locked due to age.
Parents
  • 0
    That is a pretty low-risk issue, especially for a 'site' which is not used by the public.

    However, you have the option of restricting the webadmin to certain addresses, which should stop the scans from seeing it.

    Barry
  • 0 in reply to BarryG
    Thanks for posting this guys.  I saw a similar complaint and hadn't thought that the "problem" was just the scanning software not knowing the difference between a webserver and a web interface.

    Hey Jack, what's the "house" response to this "ding" from SecurityMetrics.

    Cheers - Bob
  • 0 in reply to BAlfson
    Barry: Thanks for your thoughts. Some more info:

    Again, the outfit which scanned me was SecurityMetrics and I've done some more digging on them since last evening. Some of their report has merit (I had a couple ports open which have since become deprecated; I closed those), while other stuff is pretty nonsensical (this particular issue, and a gripe about an instance of Apache 2.0.49 running a very specialized app on an isolated Linux box - not very likely to be a threat to anything else behind the firewall, even if someone could manage to exploit it).

    Anyway, thus far I've managed to do the following:

    [LIST=1]
    • Blacklist SecurityMetrics' address block with a rule to deny all traffic from them (this won't help if they really do need to test me, but at least it should make them ask first);
    • Moved the Apache 2.0.49 box to a different IP in my block and adjusted my Astaro rules so that it won't show up when scanning the IP where the subject site is hosted;
    • Close off the deprecated port forwards (should have done that some time ago, however, the OS/2 box to which those ports were directed has since changed IP's, so they would have been met with dead air, anyway);
    • Changed my port scan detection policy from blackhole to reject (Astaro did detect the port scan early on)
    [/LIST]
    I'm thinking that what I may do is move my admin port to yet another IP in my block. Changing allowed networks becomes problematic for me, as I never quite know where I may be when an issue arises and I don't have VPN access (or what if the VPN is down?). I need to think on that a bit more. Good suggestion, though; thanks.

    Bob: Misery loves company. I still think it's rather rude to be tested without being informed first. How to tell the difference between a legitimate "test" and a cracker? Before this, I had never even heard of this outfit. D-mn rude, in fact.

    Here's a rather interesting thread I found while Googling them. Of course, Matt Blaze has a reasonable take on this whole "testing" thing. I guess the grey area has to do with what one considers to be a "serious" risk vs a "trivial" one. An Apache instance on Linux - even 2.0.49 - running chrooted hardly compromises LAN security, as a proper chroot jail would keep even a root user (unless logged in locally, and then, why use Apache for the exploit?) from going any further.
Reply
  • 0 in reply to BAlfson
    Barry: Thanks for your thoughts. Some more info:

    Again, the outfit which scanned me was SecurityMetrics and I've done some more digging on them since last evening. Some of their report has merit (I had a couple ports open which have since become deprecated; I closed those), while other stuff is pretty nonsensical (this particular issue, and a gripe about an instance of Apache 2.0.49 running a very specialized app on an isolated Linux box - not very likely to be a threat to anything else behind the firewall, even if someone could manage to exploit it).

    Anyway, thus far I've managed to do the following:

    [LIST=1]
    • Blacklist SecurityMetrics' address block with a rule to deny all traffic from them (this won't help if they really do need to test me, but at least it should make them ask first);
    • Moved the Apache 2.0.49 box to a different IP in my block and adjusted my Astaro rules so that it won't show up when scanning the IP where the subject site is hosted;
    • Close off the deprecated port forwards (should have done that some time ago, however, the OS/2 box to which those ports were directed has since changed IP's, so they would have been met with dead air, anyway);
    • Changed my port scan detection policy from blackhole to reject (Astaro did detect the port scan early on)
    [/LIST]
    I'm thinking that what I may do is move my admin port to yet another IP in my block. Changing allowed networks becomes problematic for me, as I never quite know where I may be when an issue arises and I don't have VPN access (or what if the VPN is down?). I need to think on that a bit more. Good suggestion, though; thanks.

    Bob: Misery loves company. I still think it's rather rude to be tested without being informed first. How to tell the difference between a legitimate "test" and a cracker? Before this, I had never even heard of this outfit. D-mn rude, in fact.

    Here's a rather interesting thread I found while Googling them. Of course, Matt Blaze has a reasonable take on this whole "testing" thing. I guess the grey area has to do with what one considers to be a "serious" risk vs a "trivial" one. An Apache instance on Linux - even 2.0.49 - running chrooted hardly compromises LAN security, as a proper chroot jail would keep even a root user (unless logged in locally, and then, why use Apache for the exploit?) from going any further.
Children