Re: [fw-wiz] stopping bots from phoning home
From: Paul D. Robertson (paul_at_compuwar.net)
Date: 09/08/05
- Previous message: mason_at_schmitt.ca: "[fw-wiz] The home user problem returns"
- In reply to: mason_at_schmitt.ca: "Re: [fw-wiz] stopping bots from phoning home"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: mason@schmitt.ca Date: Wed, 7 Sep 2005 23:02:05 -0400 (EDT)
On Wed, 7 Sep 2005 mason@schmitt.ca wrote:
> It was a good suggestion then and it's a good one now, but my boss has
> said that despite the obvious technical merit, he's not going for it.
> He's concerned about an increase in support costs and negative customer
> experiences with people phoning in that forget/don't understand the
> repercussions of their choice. Or worse, leave us for the competition
It seems to me that it wouldn't be that difficult to put the opt-in's
behind a cafe-style gateway and let them click to enable when they get a
new applicaiton- we *have* to get past joe idiot having unlimited access
since they can't secure their systems.
> without even phoning us, because they decide to use some new app that they
> just downloaded and find that it doesn't work and their friend down the
> street says, well it works fine on my dsl connection!
Under what circumstances would he consider it? What sort of
support/technology would make him decide to make it better?
[snip]
>
>
> > If you can get your customers to use an IRC proxy, great- it might be sort
> > of interesting to look at doing a transparent proxy and just sending up a
> > screen that asks for a specific response prior to continuing the
> > connection- I'd be *really* interested in your results though, espeically
> > with the newer IM clients that do IRC.
> >
>
> I have given this some thought and talked it over with others here and we
> think that your variation on the original idea is an improvement. Largely
> due to the fact that popular IM clients, such as Trillian, that kind of
> support IRC, wouldn't allow for authentication and some servers have a
> limit on the number of connections from a single IP. So, rather than run
> all connections through a proxy, we thought that perhaps we could just
> watch for IRC connections to be established (really easy with the
> packetshaper and doesn't require sniffing). When we see a connection
> established, have a bot kick off that logs onto the server the connection
> was made to and initiate a direct chat request to the user that just
> logged on. The bot would ask a question and if it didn't get a response,
> it would block IRC traffic for that IP and send an email to our ticket
> system so that we know who is infected.
That's a pretty neat idea- though you'll have to sniff the screen to see
who they log in as and a quick /nick race would suck- I expect that'd not
be an issue for most IRC users- though the bot connection might upset a
server owner or two (I can think of one network where it'd be seen as
hostile unless it was pre-approved.)
>
> There's probably a less convoluted way of approaching this (if you have
> one, let me know), but this is doable without having to do much
> programming.
It'd be kind of interesting to hand out DNS for irc.* addresses and NAT
that address outbound for anthing other than "standard" IRC ports- those
could hit a proxy - if it's a transparent proxy you might be able to get
past the address issues- surely it'd be easier to just pre-register folks
who *know* they'll use IRC and Web-gateway anyone else if they try to get
out via IRC (if all their connections go to "You're infected unless you
really just fired up a chat client, do *splat* to get out" instead of the
Web, you're likely to have less support issues.
> The big question is, whether it's worth the effort or not. I'm not sure.
> It increases the complexity of our network while only focusing on the
> current fad in spyware/trojans/bots (what do we call these things now?) of
> using IRC. Currently there are bots (settled on bots), that once on the
> host, will talk over http, p2p, or IM in order to get their instructions.
> IRC is the current dominant method, but not the only one.
We have to solve the bot problem, this is a start...
>
> I'm more inclined to take a broader proactive approach, but could use some
> guidance concerning some of my current half thought out ideas. I'll send
> these ideas along in my next email.
>
> > You know, if we could get rid of the home user problem, all our lives
> > would get easier...
> >
>
> Then there wouldn't be an internet and that would suck. But, I know what
> you mean...
>
> > Personal firewalls that block outbound connections are a good thing- you
> > might want to see if your marketing folks can do something akin to the
> > AOL and DSL provier firewall packages- marketing always has money that
> > techs don't...
>
> Ha! You wouldn't believe the support problems that we have with people
> that choose to install firewalls that ask them to make choices. I think
> that having a firewall on the box that can see which program is trying to
> connect is great! ...if there is a person interacting with it that
> understands some basics. When the person using the computer has no idea
> what the little pop ups are talking about and doesn't really want to know,
> they just blindly click ok, because clicking ok means that they are more
> secure right? We have had plenty of support calls where the customer is
> angry that our mail server is down... when in reality, they clicked ok
> when the window asked if they wanted to block pop3...
Surely that's all fixable in a once-a-month web presentation with Q&A-
that'd probably cost less than after-the-fact support calls- if you
include post-infection costs.
I'd also potentially be good for retention- this is worth more thought.
> We do what we can to help out these people and sometimes that means having
> them bring their pc in so that we can get a look at it. Often we tell
> them that they would be better off with a common home firewall. The crazy
> thing is that I know that many of the large ISPs (not sure if I should
> name names or not) have it as part of their level1 tech support flow chart
I'm all for naming if it's done in terms that protect from malicioius
lawsuits. We need to start differentiating between people adding to the
problem and people trying to solve it.
> to ask the customer to disable the firewall and leave it like that! That
> really chaps my ass. If these big ISPs weren't so careless, I wouldn't
> have so many problems... nor would the rest of the net for that matter.
> Oh well, finger pointing isn't going to get me anywhere.
>
I dunno- it might- if we can change it into a change in practices.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
paul@compuwar.net which may have no basis whatsoever in fact."
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
- Previous message: mason_at_schmitt.ca: "[fw-wiz] The home user problem returns"
- In reply to: mason_at_schmitt.ca: "Re: [fw-wiz] stopping bots from phoning home"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
