Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
Hi, On Fri, Oct 18, 2002 at 08:48:05AM +1000, Brian May wrote: > On Thu, Oct 17, 2002 at 02:18:34PM +0200, Emile van Bergen wrote: > > Of course, you need to implement quite a bit of SMTP before getting at > > the DATA phase, but it's potentially cleaner than doing it in a > > transparent proxy, because you only have to deal with the pure data > > stream through a set of open file descriptors, not with the IP side > > of things. > > If postfix (or whatever MTA you use) sees the connection as comming from > the proxy server, rather then the real server, you have just broken the > code which prevents postfix being used as an open relay. > > The MTA needs to know where the connection started of from, in order to > decide if it is allowed to relay the mail or not. Sure, of course. If you look at how Qmail handles this though, it doesn't have the actual server do a getpeername() on its standard in on the assumption that that's the original socket; rather, it has tcpserver passing down the peer IP and a few other things in environment variables to the server or 'proxy process' it spawns. See http://www.qmail.org/qmail-manual-html/man5/tcp-environ.html. In short, this way that information is preserved even if you put some 'filter' in the pipeline from tcpserver to qmail-smtpd. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgpmnoNM9NPyP.pgp Description: PGP signature
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
Hi, On Fri, Oct 18, 2002 at 08:48:05AM +1000, Brian May wrote: > On Thu, Oct 17, 2002 at 02:18:34PM +0200, Emile van Bergen wrote: > > Of course, you need to implement quite a bit of SMTP before getting at > > the DATA phase, but it's potentially cleaner than doing it in a > > transparent proxy, because you only have to deal with the pure data > > stream through a set of open file descriptors, not with the IP side > > of things. > > If postfix (or whatever MTA you use) sees the connection as comming from > the proxy server, rather then the real server, you have just broken the > code which prevents postfix being used as an open relay. > > The MTA needs to know where the connection started of from, in order to > decide if it is allowed to relay the mail or not. Sure, of course. If you look at how Qmail handles this though, it doesn't have the actual server do a getpeername() on its standard in on the assumption that that's the original socket; rather, it has tcpserver passing down the peer IP and a few other things in environment variables to the server or 'proxy process' it spawns. See http://www.qmail.org/qmail-manual-html/man5/tcp-environ.html. In short, this way that information is preserved even if you put some 'filter' in the pipeline from tcpserver to qmail-smtpd. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info msg06964/pgp0.pgp Description: PGP signature
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, Oct 17, 2002 at 02:18:34PM +0200, Emile van Bergen wrote: > Of course, you need to implement quite a bit of SMTP before getting at > the DATA phase, but it's potentially cleaner than doing it in a > transparent proxy, because you only have to deal with the pure data > stream through a set of open file descriptors, not with the IP side > of things. If postfix (or whatever MTA you use) sees the connection as comming from the proxy server, rather then the real server, you have just broken the code which prevents postfix being used as an open relay. The MTA needs to know where the connection started of from, in order to decide if it is allowed to relay the mail or not. -- Brian May <[EMAIL PROTECTED]>
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, Oct 17, 2002 at 08:57:01AM -0400, Jeff S Wheeler wrote: > Is this true, or will a getsockname() performed on a TCP socket which > was created as one endpoint of a connection which is being transparently > proxied give the client's intended destination address? I do not know. My experience is that getsockname returns the new address which the data is being redirectected to. Once the tranparent proxy creates the real connection to the remote host though, the remote host only sees the connection to the proxy server, not the host that initiated the connection. > > A transparent HTTP proxy relies on the server name HTTP1.1 request > > field to determine what host the client really wanted to connect to. > > (this has been tested with Pacific's transparent proxy). > I do know that all HTTP/1.1 requests must contain a Host: header to be > valid. Even if you knew the destination IP address, if you did not have > a Host: header you couldn't successfully complete an HTTP/1.1 request. I have changed ISPs so can no longer check this now, but my experience is that doing something like this works: telnet www.microsoft.com.au 80 (or *any* IP address) GET / HTTP/1.1 Host: www.monash.edu.au will return the web page for www.monash.edu.au instead of www.microsoft.com.au. In fact if you leave out the Host: field, even for HTTP/1.0, the proxy gets confused and doesn't know where you want to connect to. Or, enter an invalid host name for the Host field, and you get a squid proxy error that the DNS cannot be found. Which is a bit weird considering no proxy's are used as far as the client is concerned. (I first encountered this when trying to connect to a remote web server which had no DNS entry, but required a certain Hosts: field. I thought no problem, I will just create an /etc/hosts entry on my local computer. Trouble is, this transparent proxy intercepted the request, tried to look up the non-existant domain, and failed.) -- Brian May <[EMAIL PROTECTED]>
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, 17 Oct 2002 23:15, Alex Borges (lex) wrote: > This kind of thing is simple at least with qmail, u set up a front > end box that does the smtp, make it scan through qmailscan...whatever, > those filters will let u decide the action to take if a virus is found. The problem is that spam is often unbouncable (or if bounced will go to the wrong place). Discarding messages without bouncing is bad for false-positives. So the ideal solution is to send a 5xx SMTP message and drop the connection when you see a spam and never queue it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, Oct 17, 2002 at 02:18:34PM +0200, Emile van Bergen wrote: > Of course, you need to implement quite a bit of SMTP before getting at > the DATA phase, but it's potentially cleaner than doing it in a > transparent proxy, because you only have to deal with the pure data > stream through a set of open file descriptors, not with the IP side > of things. If postfix (or whatever MTA you use) sees the connection as comming from the proxy server, rather then the real server, you have just broken the code which prevents postfix being used as an open relay. The MTA needs to know where the connection started of from, in order to decide if it is allowed to relay the mail or not. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, Oct 17, 2002 at 08:57:01AM -0400, Jeff S Wheeler wrote: > Is this true, or will a getsockname() performed on a TCP socket which > was created as one endpoint of a connection which is being transparently > proxied give the client's intended destination address? I do not know. My experience is that getsockname returns the new address which the data is being redirectected to. Once the tranparent proxy creates the real connection to the remote host though, the remote host only sees the connection to the proxy server, not the host that initiated the connection. > > A transparent HTTP proxy relies on the server name HTTP1.1 request > > field to determine what host the client really wanted to connect to. > > (this has been tested with Pacific's transparent proxy). > I do know that all HTTP/1.1 requests must contain a Host: header to be > valid. Even if you knew the destination IP address, if you did not have > a Host: header you couldn't successfully complete an HTTP/1.1 request. I have changed ISPs so can no longer check this now, but my experience is that doing something like this works: telnet www.microsoft.com.au 80 (or *any* IP address) GET / HTTP/1.1 Host: www.monash.edu.au will return the web page for www.monash.edu.au instead of www.microsoft.com.au. In fact if you leave out the Host: field, even for HTTP/1.0, the proxy gets confused and doesn't know where you want to connect to. Or, enter an invalid host name for the Host field, and you get a squid proxy error that the DNS cannot be found. Which is a bit weird considering no proxy's are used as far as the client is concerned. (I first encountered this when trying to connect to a remote web server which had no DNS entry, but required a certain Hosts: field. I thought no problem, I will just create an /etc/hosts entry on my local computer. Trouble is, this transparent proxy intercepted the request, tried to look up the non-existant domain, and failed.) -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
Um This kind of thing is simple at least with qmail, u set up a front end box that does the smtp, make it scan through qmailscan...whatever, those filters will let u decide the action to take if a virus is found. If none, then forward to smtp on your real server for delivery... Probably lost myself part of this thread, forgive me if this is redundant
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, 17 Oct 2002 23:15, Alex Borges (lex) wrote: > This kind of thing is simple at least with qmail, u set up a front > end box that does the smtp, make it scan through qmailscan...whatever, > those filters will let u decide the action to take if a virus is found. The problem is that spam is often unbouncable (or if bounced will go to the wrong place). Discarding messages without bouncing is bad for false-positives. So the ideal solution is to send a 5xx SMTP message and drop the connection when you see a spam and never queue it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
Um This kind of thing is simple at least with qmail, u set up a front end box that does the smtp, make it scan through qmailscan...whatever, those filters will let u decide the action to take if a virus is found. If none, then forward to smtp on your real server for delivery... Probably lost myself part of this thread, forgive me if this is redundant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, 2002-10-17 at 04:51, Brian May wrote: > AFAIK transparent proxying in Linux is limited to redirecting all ports > to a given port another host. It is not possible for the proxy server to > tell, for instance what the original destination IP address was. Is this true, or will a getsockname() performed on a TCP socket which was created as one endpoint of a connection which is being transparently proxied give the client's intended destination address? I do not know. > A transparent HTTP proxy relies on the server name HTTP1.1 request > field to determine what host the client really wanted to connect to. > (this has been tested with Pacific's transparent proxy). I do know that all HTTP/1.1 requests must contain a Host: header to be valid. Even if you knew the destination IP address, if you did not have a Host: header you couldn't successfully complete an HTTP/1.1 request. -- Jeff S Wheeler [EMAIL PROTECTED] Software DevelopmentFive Elements, Inc http://www.five-elements.com/~jsw/ signature.asc Description: This is a digitally signed message part
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, Oct 17, 2002 at 11:41:20AM +0200, Emile van Bergen wrote a few disorganized lines, saying: > Qmail has such a smtp filter (rblsmtpd[2]) that checks MAIL FROM: > domains against RBLs; it only runs the real server (qmail-smtpd[3]) if > the domain is not listed. Of course, it checks the peer IP address instead of the envelope sender's domain. I wasn't fully awake yet. The point that separation of the TCP server from the smtp server as done by qmail gives you the ability to insert scanners and whatnot that reject mail with a 5xx still stands though. Of course, you need to implement quite a bit of SMTP before getting at the DATA phase, but it's potentially cleaner than doing it in a transparent proxy, because you only have to deal with the pure data stream through a set of open file descriptors, not with the IP side of things. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgp1toBtskTqJ.pgp Description: PGP signature
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, 2002-10-17 at 04:51, Brian May wrote: > AFAIK transparent proxying in Linux is limited to redirecting all ports > to a given port another host. It is not possible for the proxy server to > tell, for instance what the original destination IP address was. Is this true, or will a getsockname() performed on a TCP socket which was created as one endpoint of a connection which is being transparently proxied give the client's intended destination address? I do not know. > A transparent HTTP proxy relies on the server name HTTP1.1 request > field to determine what host the client really wanted to connect to. > (this has been tested with Pacific's transparent proxy). I do know that all HTTP/1.1 requests must contain a Host: header to be valid. Even if you knew the destination IP address, if you did not have a Host: header you couldn't successfully complete an HTTP/1.1 request. -- Jeff S Wheeler [EMAIL PROTECTED] Software DevelopmentFive Elements, Inc http://www.five-elements.com/~jsw/ signature.asc Description: This is a digitally signed message part
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, Oct 17, 2002 at 11:41:20AM +0200, Emile van Bergen wrote a few disorganized lines, saying: > Qmail has such a smtp filter (rblsmtpd[2]) that checks MAIL FROM: > domains against RBLs; it only runs the real server (qmail-smtpd[3]) if > the domain is not listed. Of course, it checks the peer IP address instead of the envelope sender's domain. I wasn't fully awake yet. The point that separation of the TCP server from the smtp server as done by qmail gives you the ability to insert scanners and whatnot that reject mail with a 5xx still stands though. Of course, you need to implement quite a bit of SMTP before getting at the DATA phase, but it's potentially cleaner than doing it in a transparent proxy, because you only have to deal with the pure data stream through a set of open file descriptors, not with the IP side of things. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info msg07011/pgp0.pgp Description: PGP signature
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
Hi, On Thu, Oct 17, 2002 at 10:44:06AM +0200, Russell Coker wrote: > On Thu, 17 Oct 2002 10:32, Brian May wrote: > > On Thu, Oct 17, 2002 at 10:25:52AM +0200, Russell Coker wrote: > > > Ideally we would be able to detect the virus as it comes in and give a > > > 5xx SMTP code. > > > > Yes, that would be the best solution. > > > > exim is the only MTA I know of where I have heard this is possible > > though. > > The best solution would be to have a transperant proxy in front of the mail > server that does this. > > The proxy could pass the data through until a SMTP "DATA" command is sent (so > if the envelope sender or recipient addresses or of the sending host name or > RBL isn't right then the mail server can drop it). Then it would pause the > data stream until it had received it all and scanned it (sending code 5xx for > a virus and passing it on otherwise). > > Is Linux transperant proxying up to this? Can you intercept a data stream > while preserving both the source and destination addresses? Well, once you separate the TCP listener from the actual SMTP server, as done for servers run from (ucspi-tcp's) tcpserver[1] or inetd, then you can insert arbitrary programs into the pipe, without having to dig at the networking layers. Qmail has such a smtp filter (rblsmtpd[2]) that checks MAIL FROM: domains against RBLs; it only runs the real server (qmail-smtpd[3]) if the domain is not listed. Of course, other policies could be implemented this way as well. Have a look at Cheers, Emile. [1] http://cr.yp.to/ucspi-tcp/tcpserver.html [2] http://cr.yp.to/ucspi-tcp/rblsmtpd.html [3] http://www.qmail.org/qmail-manual-html/man8/qmail-smtpd.html -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info pgpKeKDZl0vmB.pgp Description: PGP signature
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, Oct 17, 2002 at 10:44:06AM +0200, Russell Coker wrote: > Is Linux transperant proxying up to this? Can you intercept a data stream > while preserving both the source and destination addresses? I don't think it is possible, but I do not know why... AFAIK transparent proxying in Linux is limited to redirecting all ports to a given port another host. It is not possible for the proxy server to tell, for instance what the original destination IP address was. A transparent HTTP proxy relies on the server name HTTP1.1 request field to determine what host the client really wanted to connect to. (this has been tested with Pacific's transparent proxy). -- Brian May <[EMAIL PROTECTED]>
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, 17 Oct 2002 10:32, Brian May wrote: > On Thu, Oct 17, 2002 at 10:25:52AM +0200, Russell Coker wrote: > > Ideally we would be able to detect the virus as it comes in and give a > > 5xx SMTP code. > > Yes, that would be the best solution. > > exim is the only MTA I know of where I have heard this is possible > though. The best solution would be to have a transperant proxy in front of the mail server that does this. The proxy could pass the data through until a SMTP "DATA" command is sent (so if the envelope sender or recipient addresses or of the sending host name or RBL isn't right then the mail server can drop it). Then it would pause the data stream until it had received it all and scanned it (sending code 5xx for a virus and passing it on otherwise). Is Linux transperant proxying up to this? Can you intercept a data stream while preserving both the source and destination addresses? I've CC'd this to debian-isp for some more input. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
Hi, On Thu, Oct 17, 2002 at 10:44:06AM +0200, Russell Coker wrote: > On Thu, 17 Oct 2002 10:32, Brian May wrote: > > On Thu, Oct 17, 2002 at 10:25:52AM +0200, Russell Coker wrote: > > > Ideally we would be able to detect the virus as it comes in and give a > > > 5xx SMTP code. > > > > Yes, that would be the best solution. > > > > exim is the only MTA I know of where I have heard this is possible > > though. > > The best solution would be to have a transperant proxy in front of the mail > server that does this. > > The proxy could pass the data through until a SMTP "DATA" command is sent (so > if the envelope sender or recipient addresses or of the sending host name or > RBL isn't right then the mail server can drop it). Then it would pause the > data stream until it had received it all and scanned it (sending code 5xx for > a virus and passing it on otherwise). > > Is Linux transperant proxying up to this? Can you intercept a data stream > while preserving both the source and destination addresses? Well, once you separate the TCP listener from the actual SMTP server, as done for servers run from (ucspi-tcp's) tcpserver[1] or inetd, then you can insert arbitrary programs into the pipe, without having to dig at the networking layers. Qmail has such a smtp filter (rblsmtpd[2]) that checks MAIL FROM: domains against RBLs; it only runs the real server (qmail-smtpd[3]) if the domain is not listed. Of course, other policies could be implemented this way as well. Have a look at Cheers, Emile. [1] http://cr.yp.to/ucspi-tcp/tcpserver.html [2] http://cr.yp.to/ucspi-tcp/rblsmtpd.html [3] http://www.qmail.org/qmail-manual-html/man8/qmail-smtpd.html -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info msg06961/pgp0.pgp Description: PGP signature
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, Oct 17, 2002 at 10:44:06AM +0200, Russell Coker wrote: > Is Linux transperant proxying up to this? Can you intercept a data stream > while preserving both the source and destination addresses? I don't think it is possible, but I do not know why... AFAIK transparent proxying in Linux is limited to redirecting all ports to a given port another host. It is not possible for the proxy server to tell, for instance what the original destination IP address was. A transparent HTTP proxy relies on the server name HTTP1.1 request field to determine what host the client really wanted to connect to. (this has been tested with Pacific's transparent proxy). -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: VIRUS IN YOUR MAIL (W32/BugBear.A (Clam))
On Thu, 17 Oct 2002 10:32, Brian May wrote: > On Thu, Oct 17, 2002 at 10:25:52AM +0200, Russell Coker wrote: > > Ideally we would be able to detect the virus as it comes in and give a > > 5xx SMTP code. > > Yes, that would be the best solution. > > exim is the only MTA I know of where I have heard this is possible > though. The best solution would be to have a transperant proxy in front of the mail server that does this. The proxy could pass the data through until a SMTP "DATA" command is sent (so if the envelope sender or recipient addresses or of the sending host name or RBL isn't right then the mail server can drop it). Then it would pause the data stream until it had received it all and scanned it (sending code 5xx for a virus and passing it on otherwise). Is Linux transperant proxying up to this? Can you intercept a data stream while preserving both the source and destination addresses? I've CC'd this to debian-isp for some more input. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
