Guest User!

You are not Sophos Staff.

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

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
  • They just tested again. Our overall score (which needs to be 4 or below) went down from 128 to 10. The top two were the admin port mentioned at the beginning of this thread (risk factor of 5) and an SSH port forward (risk factor of 3), which I've now turned off.

    Barry, I decided to take your advice and have now limited access to the admin interface to the local LAN and any VPN-connected LANs (including client-to-site).

    One of the remaining gripes they had concerns timestamping of ICMP replies(!)... I'm not going to turn off ICMP, as I use it on a regular basis, but I consider the timestamping issue to be completely silly.

    More on this after the next scan.

    PS - The first test took about two hours. This one ran for almost 12 hours. I really don't know how they were even able to get to us from their IP's unless they masqueraded somehow. I'll have to review the logs...
Reply
  • They just tested again. Our overall score (which needs to be 4 or below) went down from 128 to 10. The top two were the admin port mentioned at the beginning of this thread (risk factor of 5) and an SSH port forward (risk factor of 3), which I've now turned off.

    Barry, I decided to take your advice and have now limited access to the admin interface to the local LAN and any VPN-connected LANs (including client-to-site).

    One of the remaining gripes they had concerns timestamping of ICMP replies(!)... I'm not going to turn off ICMP, as I use it on a regular basis, but I consider the timestamping issue to be completely silly.

    More on this after the next scan.

    PS - The first test took about two hours. This one ran for almost 12 hours. I really don't know how they were even able to get to us from their IP's unless they masqueraded somehow. I'll have to review the logs...
Children
No Data