Short answer is: No, there isn't currently a way to prevent the filer from listening and accepting socket connections on port 80.
Some additional details might be helpful.
The httpd.enable option toggles HTTP access to the web hierarchy on the filer, in the case that HTTP is licensed on the filer.
Port 80 is left open for purposes of administrative access - for example FilerView and SecureShare Quota Manager, even if HTTP is not licensed on the filer. Access to administrative areas can be toggled using the httpd.admin.enable option.
If httpd.enable and httpd.admin.enable are both off, and HTTP is not licensed, then the server will immediately close incoming connections without reading any HTTP headers (this feature appears in 6.0 and higher).
We are not currently aware of any flaws in the HTTP server which allow exploitation in the manner of the worms mentioned.
Hope that helps, Steve Klinkner
-----Original Message----- From: Leigh David Heyman [mailto:leigh@ai.mit.edu] Sent: Wednesday, September 19, 2001 8:34 AM To: toasters@mathworks.com Subject: port 80 answers tcp
Hi, I've noticed that in DoT, the filer still has tcp port 80 open and listening even with "options httpd.enable off."
Since the nimda and code red worms send attack traffic to any hosts which respond on port 80, regardless of whether it's a vulnerable windows webserver, is there any way to actually prevent the filer from having tcp port 80 open and listening?
Thanks,
-Leigh
===================================================================== Leigh Heyman,GCIA Artificial Intelligence Lab Systems Administrator Massachusetts Institute of Technology leigh@ai.mit.edu 617-253-1729
On Thu, Sep 20, 2001 at 01:23:38AM -0700, Klinkner, Steve wrote:
Short answer is: No, there isn't currently a way to prevent the filer from listening and accepting socket connections on port 80.
I think we'd all like to see an option to just shut it down. Exploitable or not, if nothing more the worms eat CPU trying to get at the webserver.
Some additional details might be helpful.
The httpd.enable option toggles HTTP access to the web hierarchy on the filer, in the case that HTTP is licensed on the filer.
Port 80 is left open for purposes of administrative access - for example FilerView and SecureShare Quota Manager, even if HTTP is not licensed on the filer. Access to administrative areas can be toggled using the httpd.admin.enable option.
If httpd.enable and httpd.admin.enable are both off, and HTTP is not licensed, then the server will immediately close incoming connections without reading any HTTP headers (this feature appears in 6.0 and higher).
We are not currently aware of any flaws in the HTTP server which allow exploitation in the manner of the worms mentioned.
Hope that helps, Steve Klinkner
-----Original Message----- From: Leigh David Heyman [mailto:leigh@ai.mit.edu] Sent: Wednesday, September 19, 2001 8:34 AM To: toasters@mathworks.com Subject: port 80 answers tcp
Hi, I've noticed that in DoT, the filer still has tcp port 80 open and listening even with "options httpd.enable off."
Since the nimda and code red worms send attack traffic to any hosts which respond on port 80, regardless of whether it's a vulnerable windows webserver, is there any way to actually prevent the filer from having tcp port 80 open and listening?
Thanks,
-Leigh
===================================================================== Leigh Heyman,GCIA Artificial Intelligence Lab Systems Administrator Massachusetts Institute of Technology leigh@ai.mit.edu 617-253-1729
We are not currently aware of any flaws in the HTTP server which allow exploitation in the manner of the worms mentioned.
I think we'd all like to see an option to just shut it down. Exploitable or not, if nothing more the worms eat CPU trying to get at the webserver.
exactly. My concern is not that the system will be exploited, but that these worms automatically throw a ton of traffic at any host which SYN/ACK's on port 80, regardless of whatever webserver (or lack thereof) is at the other end. The risk is Denial of service, not exploitation, and being able to simply close the port is the best way to mitigate this problem.
-Leigh
===================================================================== Leigh Heyman,GCIA Artificial Intelligence Lab Systems Administrator Massachusetts Institute of Technology leigh@ai.mit.edu 617-253-1729
On Thu, Sep 20, 2001 at 12:44:46PM -0400, Leigh David Heyman wrote:
80, regardless of whatever webserver (or lack thereof) is at the other end. The risk is Denial of service, not exploitation, and being able to simply close the port is the best way to mitigate this problem.
In the meantime you could, of course, filter at nearby routers.
Though I'm rather surprised that you're letting a filer be reachable from outside of your internal network anyway. You do at least filter NFS and RPC traffic to only legitimate hosts and networks, right?
(I thought it was accepted & best common practice to make NFS services accessible via private networks, and CIFS restricted to your site only.)
James.
-
James R Grinter -
Kelsey Cummings -
Klinkner, Steve -
Leigh David Heyman