problem with web shield and slipstream

[guestja]

 have been trying to test the web shield and have a problelm.
 I am using a "high speed internet program" called slipstream on win xp with sp-2.. In order for it to work with firefox I have to have it set to use local host port 5400. 
When I ran the eicar test with this port selected the file gets  downloaded and detected and then I am offered the option to delete it. If I remove the manual proxy configuration (local host 5400),  It works as it should - giving me the option to abort the connectiion before download.
Is there a way I can use slipstream and still have web shield work?

[Lisandro]

If you set WebShield to scan port 5400 (or even, 80,5400) and un-check the option 'Ignore local communication', won't it work?

[guestja]

technical,
by setting webshield to scan port 5400 did you mean:     Going to webshield customize and setting the "redirected http: ports" from the default "80" to "5400" and then unchecking  "ignore local communication"    If so, I tried this and it still does not block the connection before download.  Is this right, or anything else?

[sded]

In addition to redirecting 5400 and 80, in avast.ini, under [Webscanner] add OptinProcess=slipstream.exe (or whatever the real name of the slipstream executable is).  I believe this was a change made in .623 on the selection of processes to be webscanned. 

[guestja]

Okay,
I went to avast4.ini and enter the data like this:   OptinProcess=Slipaccel.exe   and added port 5400 to port 80 like this:  80,5400     and it still allows eicar to be downloaded.  Anything else?

[Vlk]

Did you restart the WebShield provider after making the INI file changes?

[guestja]

Vlk,
Yes, it still doesn't work though. (is it necessary to uncheck "ignore local communication"  - I tried it both ways)

[lukor]

Hey gyus,

let me explain what are you doing.

1) adding the port 5400 and unchecking the box: Ignore localhost communication means that Web Shield will be trying to monitor connections to the port 5400 (where the slipstream app is running) and this monitoring will take place even if the slipstream program is running on the same computer as your browser. This seems like a good solution for this specific configuration. It would go like this:

IE <- localhost 5400 <- gets catched by webshield, scanned <- slipstream running on localhost:5400 <- compressed <- slipstream server <- HTTP server

2) adding the Slipaccel.exe to the OptinProcess= in [WebScanner] section in avast4.ini instructs Web Shield to scan all outgoing connection from the application. Outgoing connections to the specified ports will be checked, in this situation perhaps 80 and 5400. Hmm, what we are trying to do here: we have some app, the Slipstream accelerator and this possibly compresses our data, after the data are compressed or before they are uncompressed the communication should be catched by Web Shield and scanned for viruses!!!! Hmmm, this does not seem like anything that might possibly work and believe me, it is not as easy as it might seem to detect such junk you are sending to the Web Shield and let it go through - because compressed data mostly does not adhere to HTTP standards. Anyway, there is a chance that this slipstream program accesses it's partner on some other port than 80 or 5400 and hopefully it will pass unnoticed by Web Shield - this may help. At all times, this would NOT be the way how to make this work.

IE <- localhost:5400 gets catched by WebShield cause 5400 is redirected port <- slipstream, compressed / uncompress data <- get catched by WebShield cause slipstream is in OptinProcess <- slipstream server possibly <- HTTP server.   


Hope this will bring some light. ;-)

Lukas.

[sded]

Don't think this can be made to work unless either-
1) webshield can make outbound connection requests to port 5400, or
2) slipstream can listen on port 80 for connection requests
And, of course, unless the connection browser-->webshield-->slipstream--->web is made, the data won't flow correctly.
Webshield can trap the port 5400 connection requests from the browser, but can't route them to anything but port 80, where slipstream can't see them?  Or is there a way around this?

[Vlk]

No...!

WebShield works as a TRANSPARENT proxy. This means that,

If it is set up to capture requests to port 80, and sees some communication on this port, it passes it further on this port (80). 
If it is set up to capture requests to port 5400, sees some communication on this port, it passes it further on this port (5400), of course...

It does its best to pretend it's not even there.
Does that make sense?

[sded]

OK, so port 12080-->80  is just a special case for proxy use from the browsers?   And avast! just routes the connection request for port 5400 to port 5400 of localhost (where ss is listening), and sets itself up to intecept incoming traffic from port 5400 without making a (TCP) connection?  For web scanning, caches the traffic, does packet dissassembly and page reconstruction, scans for viruses, passes the original? traffic to the browser, along with any messages generated by the scanner?  Or something like that?
I guess the normal behavior is what confuses me in terms of transparency.   The KPF log shows the tcp traffic for http://www.avast.com.  The Opera Browser requests a connection to port 80 of the avast website, which Webshield redirects to a port 12080 connection on localhost.  Then Webshield sets up a separate connection to avast website port 80 (http).

[Vlk]

Forget 12080. That's just an implementation detail (WebShield basically needs to pick a port number - more or less on a random basis; so we picked 12080).

The way it works from a high-level point of view is that it's simply inspecting traffic that's going on on a specific port (whichever configured).
From a lower-level view, it redirects all traffic that's going on on the specific port (typically 80) to the port its listening on (in this case, 12080), inspects the traffic and finally passes it on to the original target (whatever hostname/port_number pair it was).

Vlk

[guestja]

Ok Guys,
A  little difficult for me to follow. Im sure slipstream is using compression to gain their web "acceleration" effect. I seem to get pretty good results with it vs running without, and would like to keep using it if possible.
 If I understand Lukas correctly he feels the problem might be with the compression itself seeing that is does not follow http: standards  But doesn't  application downloads, pdfs, images etc. also come compressed when you download them?
 Does this mean bottom line that it can not be made to work and I have to choose betweeen webshield and slipstream?

[sded]

Are you using a firewall?  If you have something like the free version of Kerio or Sygate, it might be worthwhile to log the web traffic to see if something is going awry or being blocked.

[guestja]

I have Zone Alarm free 5.5. I don't think I can log traffic other than alerts with it.    I guess what I was not able to understand from the discussion above was whether I would be able to use slipstream with web shield. Lukor seemed to be saying that he didn't think so. But I am not sure what conclusion  vlk came to  with his responses. I got the impression he thought, at least  earlier, that it should work.