Re: Kazzaa- spyware
From: Michail Pappas (newsspam@mycosmos.gr)Date: 12/12/01
- Next message: Littlefish: "Re: ebu****.exe trying to acces the internet"
- Previous message: Jamez: "Re: nmap question."
- In reply to: Dr. Bob: "Re: Kazzaa- spyware"
- Next in thread: Dr. Bob: "Re: Kazzaa- spyware"
- Reply: Dr. Bob: "Re: Kazzaa- spyware"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: newsspam@mycosmos.gr (Michail Pappas) Date: 11 Dec 2001 23:37:26 -0800
rck@houston.rr.com (Dr. Bob) wrote in message news:<3c167527.79434320@news-server.houston.rr.com>...
> On 11 Dec 2001 05:24:31 -0800, newsspam@mycosmos.gr (Michail Pappas)
> wrote:
[...]
> >This does not
> >mean that remote users will not be able to retrieve files from your
> >system!
>
> As I understand, it if you disallow the app from being a network
> server, then file retrievals from your machine must be done with the
> help of the WinMX server as an intermediary - a sort of relay
> implementing passive FTP transfers.
>
> >I used to create a block rule
> >for the app and then fine-tuned the rule in the rules list, to
> >dissallow _all_ incoming traffic (TCP/UDP) for the app. This is what
> >you can deny server priviliges.
>
> OK, in order to remove server privileges for an app, I remove any rule
> that TPF built for that app which has the arrow pointing to the left
> and is labeled "Incoming". That seems easy enough.
Yes, that should be all needed!
> >Alternatively, after you've built all
> >needed _allow_ rules for apps, you can just disable the "prompt for
> >rule" checkbox.
>
> What about that new app you just installed? Do you have to go into TPF
> and change it to "prompt for rule" every time you install a new app?
Yes, unless you want to create a rule before running the app. That
involves knowledge of what the app uses in terms of ports/protocols
etc. "Prompt for rule" is ok though.
> >What happens is the following: we are talking about UDP traffic here
> >and not TCP. TCP uses an established link between two machines. UDP
> >packets on the other hand are fire and forget.
>
> Aha - UDP is stateless, so the app has to open a server connection in
> order to get the "stateless" response back.
>
> With TCP, the incoming packets are associated with the outgoing
> request - that it, there is state information present in the response
> packets which the firewall can identify as a valid response to the
> app's request. With UDP there is no state, so the firewall does not
> recognize the incoming packets as belonging to the prior request.
>
> Is that basically correct?
Correct!
>
> >Tiny is clever enough to understand that since you are allowing
> >outgoing access for the specific app (Dimension 4?) to a NTP server,
> >then you _do_ want a NTP reply to come back. That is why it created 2
> >rules instead of one.
>
> Yes, it is indeed D4. I used to use AtomTime but the latest version
> nags the crap out of you so I blew it off.
>
> Existential Question: Why are some developers so self-destructive?
Philosophical answer: nature tends to self-destruct overwhelmingly
complex structures, when their complexity does not match their
usefulness. Evolution under constraints perhaps...
> >The same is also true for DNS servers, since DNS utilizes UDP
> >(usually). A rule is needed for your outgoing request, but a rule is
> >also needed for the subsequent reply.
>
> >Hope that answers your question.
>
> Very clearly. Thanks.
You are most welcome!
> >BTW, for NTP you can just create a _single_ rule as follows:
> >- Allow all UDP for both direction, for local port 123 and remote port
> >123 and for remote server(s) (insert here a list of servers you want
> >to connect for NTP)
>
> Cool. I did it with just one simple edit of a drop down.
>
> I now wonder why I waited so long to use TPF. I wasted literally
> months with ZA crashing my machine all the time. There was one version
> where it crashed my machine every hour. Try day trading under those
> conditions.
>
> >Same thing for DNS:
> >- Allow all UDP for both direction, for local port 53 and remote port
> >53 and for remote server(s) (insert here a list of _your_ DNS servers
> >only)
>
> Right now TPF has built one bi-directional rule for
>
> [any address]:[53]
>
> But unfortunately RR is changing the DNS addresses all the time. It is
> a big enough nuisance to have to change them in Win2K TCP muchless in
> the firewall too.
>
> Or do you think it is worth the extra effort to make the system more
> secure? How insecure is port 53? I have NAT running in my Linksys and
> SPI enabled, so that port should be invisible to the outside world -
> unless my Linksys is exposing it and I do not realize it. But Port
> Detective says it is blocked, so I have to assume that no one can get
> into it from the Internet.
I guess that RR is the RoadRunner always-on connection? In that case,
it _would_ be useful to replace "any address" in the tiny rule with a
range of addresses utilized by the provider's DNS servers. This way
you are limiting the scope of the remote servers information can go
out/in. Also add to this rule a "local port=53" constraint, if one
does not exist.
The reason for constraining DNS (and DHCP) is that usually rules come
for this protocol pre-configured to work for every app. Suppose that
some spyware/trojan gets installed that communicates with remote
servers from local port 53 to remote port 53. The remote port belongs
to a trojan server that holds information for zombified clients. This
traffic could be allowed by Tiny, if fine-tuning as outlined above is
not performed, since the default DNS rule would allow UDP traffic to
_any_ application on _any_ remote server, on port 53. Don't get me
wrong, this is not a firewall fault! Just with any _real_ firewall, it
is the _user's_ responsibility to tighten security. Modifying the DNS
rule outlined above will limit DNS traffic to your DNS servers only.
Of course, one could clear altogether the application-independent DNS
rule, and create a new one for each communicating application, to
restrict DNS traffic to only the applications installed. It is your
decision.
--- Michael.-
- Next message: Littlefish: "Re: ebu****.exe trying to acces the internet"
- Previous message: Jamez: "Re: nmap question."
- In reply to: Dr. Bob: "Re: Kazzaa- spyware"
- Next in thread: Dr. Bob: "Re: Kazzaa- spyware"
- Reply: Dr. Bob: "Re: Kazzaa- spyware"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
