Printable View
I was looking at my webserver logs(apache 2.0.47) and saw this:
That 200 near the end means it was successfull right? Is there something in the httpd.conf that I can change to prevent this? What do I need to do. This is the first time I have ever seen anything like that. Also, the webserver is running php 4.3.3 and the OS is Redhat 9.Quote:
[ip censored] - - [08/Dec/2003:19:09:58 -0600] "CONNECT [smtp server censored]:25 HTTP/1.0" 200 871
are you using apache as a proxy? if so, change the "Allow from all" Line in the proxy directives of httpd.conf to allow only from your local network, or whatever computers you want to be able to use the proxy
I'm not using it as a proxy, and I did a search through the httpd.conf file for "Allow from all" and looked at the comments above each result and didn't see anything about proxies.
Easy way to test if you are relaying mail for others:-
Telnet smtp_host 25 <Enter>
helo test.com <Enter>
mail from: [email protected] <Enter>
rcpt to: [email protected] <Enter>
Up to this point you will have had replies from the SMTP server that begin with "250" and then, usually, "ok" but some people mess with the textual part of the response. After the receipt to you should receive a 500 series message, usually "550" followed by text that states "Mail Relay through this server is disallowed" or some such scribble.
If you get a "250 ok" or similar then you are an open relay and you need to find a way to close it or you could be blacklisted rather quickly.
They are trying to use your web server to proxy a connection to your mail server. This has the added benefit that their connection will take on the IP of your web server and possibly bypass restrictions you had on your mail server to limit spam. If you don't have proxy enabled on your web server you are probably ok, but look at these:
http://www.mail-archive.com/tomcat-u...msg107677.html
from: http://httpd.apache.org/docs/mod/core.html
/nebulusQuote:
<Limit> directive
Syntax: <Limit method [method] ... > ... </Limit>
Context: any
Status: core
Access controls are normally effective for all access methods, and this is the usual desired behavior. In the general case, access control directives should not be placed within a <limit> section.
The purpose of the <Limit> directive is to restrict the effect of the access controls to the nominated HTTP methods. For all other methods, the access restrictions that are enclosed in the <Limit> bracket will have no effect. The following example applies the access control only to the methods POST, PUT, and DELETE, leaving all other methods unprotected:
<Limit POST PUT DELETE>
Require valid-user
</Limit>
The method names listed can be one or more of: GET, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK. The method name is case-sensitive. If GET is used it will also restrict HEAD requests. The TRACE method cannot be limited.
Warning: A <LimitExcept> section should always be used in preference to a <Limit> section when restricting access, since a <LimitExcept> section provides protection against arbitrary methods.
Check this out, I just did a search through the access log and found this also:
[ip censored] - - [07/Dec/2003:20:54:58 -0600] "CONNECT 1.3.3.7:1337 HTTP/1.0" 200 871
and tigershark that thing you said wouldn't work. Nebulus, I don't have a proxy enabled but it is wierd that it seems to have worked twice. Nobody really confirmed, the 200 does mean success right? Thanks for the replies. I looked at those links nebulus and one of said to just apply security restraints, which is what I want to do, but just saying apply security restraints is too vague for me. Then I checked the second link and didn't really see anything although I probably missed what I needed. I'll have to look around the apache site more closely and see if there is a line I can add to the config file to stop connect requests. Thanks again.
Ok, yes 200 means it the web server believed it succeeded.
The second link I provided you was a method in your configuration file to DISABLE HTTP/1.1 methods that were added (examples of methods would be PUT, GET, TRACE, CONNECT, etc). The man page tells you how to turn off those methods you do not want:
So you would:
<Limit TRACE CONNECT>
Deny from all
</Limit>
No more connects, at least in theory. :)
The second thing you show is probably the result of a scanning tool (notice the l33t l33t ;) ) that is checking if you allow the connect method.
/nebulus
Was just thinking about this, and I think you are missing the bigger picture of what is going on here.
Spammers used to go around the Internet looking for misconfigured mail servers (and there were tons since the default configuration of most mail programs allowed relay, but hey, the net was alot friendlier then). In fact, they still do this to a large degree; however, because of the intensified efforts of network security and system administrators, a large number of the spam relay servers have been corrected to no longer relay email (ie my little spam relay discovery script helped us eliminate over 100 misconfigured servers) and as the number continues to dwindle, spammers are looking for alternate methods to deliver their garbage.
One way they are doing it is by modifying worms and viruses to setup the victims computer as a spam relay. They are then able to send out their unwanted garbage anonymously again.
Many mail servers on the net still allow relay; however, it is restricted to either domain or IP address (for example sendmail now checks /etc/mail/relay-domains) which compares the sender's IP/domain name to a set list, and if it is in the list, allows the relay, and if it is not it sends a RELAY NOT PERMITTED message. Now, if this is the case, how would a clever person get around the restriction of IP and domain name? Get someone in that domain/IP range to connect to the mail server for them, and this is where your web server comes in. They are essentially using the CONNECT method in the Apache web server to take make the connection to your mail server. The benefit of this is that even if you have restricted relays on your server (but note you must still allow them), chances are, the spam relay will work again since the mail appears to be coming from an internal address. The spammer is essentially using your web server as a proxy server to take on your IP's to bypass restrictions on your mail server (with apparently some degrees of success).
Check your web server configurations to make sure that you do not allow CONNECT and TRACE.
Check your mail servers like Tiger Shark suggested to ensure they do not allow mail relay by default (or if you have access to the addicts forum, use my script (you had better have permission, you will be noticed if you use it) ).
Between the two, you may still see the events of people trying it, but you should not longer see it be successful.
/nebulus
Thank you. I will definetly add that to the config file right after I type this. I can put it anywhere right? And about using me as a proxy, I knew that is what this person was doing, but it is not what you think. They were connecting to a server in another country, so basically I guess that server allowed relaying, only now it looks like i'm the spammer. I had sendmail running, but it only works for localhost, and now I have stopped the service. And I just tried the CONNECT command on my server and it doesn't seem to do anything, all it did was say HTTP/1.1 200 OK then it output the source for my index page 2 times. Once from the first command, then again when I typed quit <enter>. I will put those lines in the config and test again to see what happens. Thank you for the help.
edit
I just added that to the conf file and here is what happened:
[root@h3r3tic3 sbeaulli]# /apache2/bin/apachectl -k restart
Syntax error on line 1047 of /apache2/conf/httpd.conf:
TRACE cannot be controlled by <Limit>
[root@h3r3tic3 sbeaulli]# gedit /apache2/conf/httpd.conf
(gedit:5931): GnomeUI-WARNING **: While connecting to session manager:
Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed.
[root@h3r3tic3 sbeaulli]# /apache2/bin/apachectl -k restart
Syntax error on line 1048 of /apache2/conf/httpd.conf:
deny not allowed here
-----------------------------------
The second error was after I took out TRACE, and I still got an error with just CONNECT in the Limit. I'll have to look around on google for a fix, or the apache website.
It may have been because the documenation I pointed to was 1.3 not the 2.0 version of Apache. I guess I incorrectly assumed the syntax would be similar. I will look around and see what I find.
/nebulus
http://httpd.apache.org/docs-2.0/mod/core.html#limitQuote:
Description: Restrict enclosed access controls to only certain HTTP methods
Syntax: <Limit method [method] ... > ... </Limit>
Context: server config, virtual host, directory, .htaccess
Override: All
Status: Core
Module: core
Access controls are normally effective for all access methods, and this is the usual desired behavior. In the general case, access control directives should not be placed within a <Limit> section.
The purpose of the <Limit> directive is to restrict the effect of the access controls to the nominated HTTP methods. For all other methods, the access restrictions that are enclosed in the <Limit> bracket will have no effect. The following example applies the access control only to the methods POST, PUT, and DELETE, leaving all other methods unprotected:
<Limit POST PUT DELETE>
Require valid-user
</Limit>
The method names listed can be one or more of: GET, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK. The method name is case-sensitive. If GET is used it will also restrict HEAD requests. The TRACE method cannot be limited.
Make sure it is in your sever configuration or virtual hosts....
/nebulus