Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 6 subscribers
  • Views 57783 views
  • Users 0 members are here
Options
Suggested
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

Trouble with SophosWebIntelligence.bundle

nevets

I am using a Mac OS10.6.8

Yesterday Sophos Anti-Virus updated to 9.0.1 - but seems to have also installed at the same time SophosWebIntelligence.bundle

Now whenever I use the internet (Safari) numerous request popups show to allow or disallow connections.

I have Little Snitch installed and those connection requests seem not to show anymore: they were far fewer than what now shows  as SophosWebIntelligence.bundle

The issues are:

Some some reason I no logger access to Google search. Of course I didn’’’’t deny a goggle connection and google was already set under little snitch as always connect.

The internet has become I would guess 10 times slower; it’’’’s almost a snails pace.

I can’’’’t fine the preference details for the SophosWebIntelligence.bundle - I assume it is like Little Snitch were any access denied can be undone or permanent access set.

THere is now an excess of deny or accept popups for every page I visit - the obvious ones of course I allow but some are vague. There can be around 10 per page.

Any ideas how to solve these points would be welcome.

:1017909


This thread was automatically locked due to age.
Parents
  • 0

    Hi jayboyd,

    Its difficult for me to comment on the internal behavior or implementation choices of the Little Snitch product, but I can definitely share with you exactly how our product works. Here goes:

    We install a kernel extension (kext) to trap outgoing TCP connections from specific processes (we look for browsers and things like curl). Our kext is going to intercept the outgoing connect() call. In programmer-speak, connect() is the API responsible for initiating a connection from your computer to somewhere else on the network. For a connect() that is destined to leave your computer, we rewrite the destination such that instead of connecting remotely we tell it to connect locally, specifically to the SophosWebIntelligence daemon.

    When the SWID receives the connection, it determines the real destination, extracts the URL from the data sent by the browser, and does two things: (1) starts its own connect() to that remote server, and (2) does a lookup to our services to identify reputation of its IP address and the URL used in the browser. Its actually SophosSXLD that does this lookup on behalf of SWID.

    Then SWID will receive data from the remote server, scan its content to ensure we don't believe you are downloading malicious content, and if everything is ok (checks for the IP address and URL were favorable, and the content is clean) then we send the content on to the browser. Its actually SophosScanD which is doing the scanning.

    If any of the checks fail we terminate the connection to the remote server and instead send the browser our own HTML to explain the blocked condition.

    Hope that helps explain our side of it. Maybe you can get the Little Snitch guys to give you a similar explanation.

    :1018511

    ---

    Bob Cook (bob.cook@sophos.com) Director, Software Development

Reply
  • 0

    Hi jayboyd,

    Its difficult for me to comment on the internal behavior or implementation choices of the Little Snitch product, but I can definitely share with you exactly how our product works. Here goes:

    We install a kernel extension (kext) to trap outgoing TCP connections from specific processes (we look for browsers and things like curl). Our kext is going to intercept the outgoing connect() call. In programmer-speak, connect() is the API responsible for initiating a connection from your computer to somewhere else on the network. For a connect() that is destined to leave your computer, we rewrite the destination such that instead of connecting remotely we tell it to connect locally, specifically to the SophosWebIntelligence daemon.

    When the SWID receives the connection, it determines the real destination, extracts the URL from the data sent by the browser, and does two things: (1) starts its own connect() to that remote server, and (2) does a lookup to our services to identify reputation of its IP address and the URL used in the browser. Its actually SophosSXLD that does this lookup on behalf of SWID.

    Then SWID will receive data from the remote server, scan its content to ensure we don't believe you are downloading malicious content, and if everything is ok (checks for the IP address and URL were favorable, and the content is clean) then we send the content on to the browser. Its actually SophosScanD which is doing the scanning.

    If any of the checks fail we terminate the connection to the remote server and instead send the browser our own HTML to explain the blocked condition.

    Hope that helps explain our side of it. Maybe you can get the Little Snitch guys to give you a similar explanation.

    :1018511

    ---

    Bob Cook (bob.cook@sophos.com) Director, Software Development

Children
No Data
Unfiltered HTML