Send firewall-wizards mailing list submissions to
firewall-wizards@honor.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@honor.icsalabs.com
You can reach the person managing the list at
firewall-wizards-admin@honor.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. stopping bots from phoning home (mason@schmitt.ca)
2. Windows VPN/RRAS traffic through watchguard (Danny)
3. Fwd: [fw-wiz] firewall rule lifecycle management (Brenno Hiemstra)
4. Re: Windows VPN/RRAS traffic through watchguard (Chuck Swiger)
5. Re: firewall rule lifecycle management (Martin)
6. Re: stopping bots from phoning home (Kevin)
7. Re: firewall rule lifecycle management (Victor Williams)
8. Re: stopping bots from phoning home (Paul D. Robertson)
--__--__--
Message: 1
Date: Wed, 31 Aug 2005 11:52:45 -0700 (PDT)
From: mason@schmitt.ca
To: firewall-wizards@honor.icsalabs.com
Subject: [fw-wiz] stopping bots from phoning home
It seems that the majority of bots connect to an IRC server in order to
get their instructions and some spyware is starting to do the same. So if
the avenue for abuse of an infected machine is via connection to IRC
networks, why not block all outbound IRC traffic (we have a Packeteer
packet shaper that I think can classify IRC traffic regardless of the port
it runs on) and implement a proxy that legitimate users of IRC have to log
into in order to gain access to IRC servers outside our network? This way
an infected PC can't phone home, legitimate use of IRC is still possible
with only a slight hurdle, and I can log all traffic that hits my block so
that I can investigate those PCs.
Your thoughts?
Given that this flies in the face of this list's mantra of, "block
outbound IRC, there is no business case for it's use" and "a default deny
stance is far more secure than a default allow stance", I feel compelled
to say that I absolutely fully agree with these points as well as the
vast majority of security truisms that are stated repeatedly on this list.
However, I'm not talking about our company LAN or the servers that I
manage. The network that takes the majority of my time is our customer
network.
I've posted before, but not often. I'm a sysadmin for a small cable ISP.
I frequently struggle with the seemingly unworkable position of being
transparent to our customers while simultaneously protecting them from
themselves and the "big bad net". As you can well imagine, I can't make a
default deny stance work in this environment, so I am left with exactly
what I don't want to be doing which is watching for problems and trying to
stop them before they make a real mess... Needless to say, this sucks.
Because I am in this state and we have very little man power for things
such as maintaining router blacklist rules for known spyware sites, irc
botnet controllers, etc (which have their own support staff payload and
customer satisfaction issues as well), I'm always trying to think of ways
of reducing our customer's exposure to threats without getting in their
way more than I have to and without creating a maintenance nightmare for
myself. I have implemented ingress/egress blocks for really common
problem ports, configured multiple layer virus filtering for inbound and
outbound email, we have a very cost effective anti-spam solution, I have
blocked windows popup spam, etc, but spyware and bots are finding plenty
of ways around my basic defences and the spyware problem is only going to
get more pronounced. This is why I suggest awkward things like the
authenticating IRC proxy idea above. I'm also currently looking at a
multi function gateway (sounds just as cheesy as those multi function
printer, fax, scanner things...) that does spyware, virus scanning and IPS
on all traffic traversing our link.
At this point, I don't see any way around it. This is my quiet plea for
answers.
--
Mason
--__--__--
Message: 2
Date: Wed, 31 Aug 2005 14:54:19 -0400
From: Danny <nocmonkey@gmail.com>
To: firewall-wizards@honor.icsalabs.com
Subject: [fw-wiz] Windows VPN/RRAS traffic through watchguard
I thought with firewalls, traffic is either allowed or it's not
allowed. :) Well, in this case, a Watchguard is connected directly to
the Internet via broadband DSL modem (no router). Rules on the
Watchguard have been configured to allow PPTP VPN (Windows-based PPTP
VPN, nothing fancy or 3rd party client software) traffic through to an
ISA server.
Now, a VPN "connection" is established from the Internet into the ISA
server without a problem, however VPN traffic through the tunnel does
not work most of the time. It's inconsistent but primarily does not
work.
So, now I try without the Watchguard in the picture, and the tunnel
carries traffic just fine - as it should.
Has anyone ever experience such a problem?
Thank you,
...D
--__--__--
Message: 3
Date: Wed, 31 Aug 2005 14:51:55 +0200
From: Brenno Hiemstra <brenno.hiemstra@gmail.com>
To: firewall-wizards@honor.icsalabs.com
Subject: Fwd: [fw-wiz] firewall rule lifecycle management
Zm9yZ290IHRvIGluY2x1ZGUgdGhlIG1haWxpbmdsaXN0LgoKCgo+IC0tLS0tLS0tLS0gRm9yd2Fy
ZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQo+IEZyb206IEJyZW5ubyBIaWVtc3RyYSA8YnJlbm5vLmhp
ZW1zdHJhQGdtYWlsLmNvbT4KPiBEYXRlOiBBdWcgMzEsIDIwMDUgMTE6MDYgQU0KPiBTdWJqZWN0
OiBSZTogW2Z3LXdpel0gZmlyZXdhbGwgcnVsZSBsaWZlY3ljbGUgbWFuYWdlbWVudAo+IFRvOiBN
aWNoYWVsIENveCA8bWljaGFlbEB3YW5kZXJpbmdiYXJrLm5ldD4KPgo+IE1pY2hhZWwsCj4KPiBX
ZSB1c2UgYSB3ZWJiYXNlZCBzb2x1dGlvbiB3aGVyZSBwZW9wbGUgbmVlZCB0byBzdXBwbHkgdGhl
aXIgZmlyZXdhbGwgcnVsZXMuCj4gV2hlbiB0aGV5IGZpbGwgaW4gdGhlIGZvcm0gdGhleSBuZWVk
IHRvIHByb3ZpZGUgZGV0YWlsZWQgaW5mb3JtYXRpb24gKHNvdXJjZQo+IElQLCBkZXN0aW5hdGlv
biBJUCwgZGVzdGluYXRpb24gcG9ydCwgZXRjZXRlcmEpLiBUaGlzIGFsc28gbmVlZHMgdG8gYmUK
PiB2YWxpZGF0ZWQgYnkgdGhlIGZpcmV3YWxsIHRlYW0uCj4KPiBXaGVuIGFsbCB0aGUgYnVyZWF1
Y3JhdGljIHN0dWZmIGlzIGRvbmUgdGhlIHJ1bGUgaXMgZ2V0dGluZyBhIHRyYWNraW5nCj4gbnVt
YmVyIHdoaWNoIGlzIGFsc28gcHV0IGludG8gdGhlIGZpcmV3YWxsIHJ1bGViYXNlIGFzICdtb3Jl
IGluZm9ybWF0aW9uJy4KPiBUaGlzIHdheSB5b3UgY2FuIGFsd2F5cyBnbyBiYWNrIGFuZCB0cmFj
ayB0aGUgcnVsZSB0byBzZWUgd2hhdCBpdCB3YXMgYWJvdXQuCj4KPiBFYWNoIHJ1bGUgaGFzIGEg
bGlmZWN5Y2xlIG9mIDEgeWVhciB3aGVyZSBpdCBuZWVkcyB0byBiZSByZS12YWxpZGF0ZWQgYnkg
YQo+IHJlc3BvbnNpYmxlIHBlcnNvbi4gSWYgdGhhdCBkb2Vzbid0IGhhcHBlbiwgb3IgdGhlIHVz
ZXIgcmVtb3ZlZCB0aGUgcnVsZSBpbgo+IHRoZSBzeXN0ZW0sIHRoZSBydWxlIGlzIHJlbW92ZWQg
ZnJvbSB0aGUgZmlyZXdhbGwuCj4KPiBZb3UgYWxzbyBuZWVkIHRvIGtlZXAgbG9nZ2luZyBpbmZv
cm1hdGlvbiBzbyB5b3UgY2FuIHRyYWNrIGhvdyBtdWNoIHRoZSBydWxlCj4gaXMgYmVpbmcgdXNl
ZC4gQWZ0ZXIgYSBjZXJ0YWluIHBlcmlvZCBvZiB0aW1lICgzIG1vbnRocyBlZy4pIHlvdSBjYW4g
dGhpbmsKPiBhYm91dCByZW1vdmluZyB0aGUgcnVsZSBmcm9tIHRoZSBmaXJld2FsbC4KPgo+IEp1
c3QgYSBmZXcgb3B0aW9ucyB0byB0aGluayBhYm91dC4KPgo+Cj4KPgo+IEJyZW5uby4KPgo+IE9u
IDgvMzAvMDUsIE1pY2hhZWwgQ294IDxtaWNoYWVsQHdhbmRlcmluZ2JhcmsubmV0PiB3cm90ZToK
PiA+Cj4gPiBIaSBhbGwuCj4gPgo+ID4gUXVlc3Rpb246IFdoYXQgZG8gdGhvc2Ugb2YgeW91IGlu
IGxhcmdlIGVudmlyb25tZW50cyBkbyB0byBtYW5hZ2UgeW91cgo+ID4gcnVsZXNldHMgaW4gdGVy
bXMgb2YgcmVtb3ZpbmcgYWNjZXNzIHRoYXQgaXMgbm8gbG9uZ2VyIHJlcXVpcmVkPyBXZSBnZXQK
PiA+IGxvdHMgb2YgcmVxdWVzdHMgdG8gYWRkIGFjY2VzcywgYnV0IGFyZSBhbG1vc3QgbmV2ZXIg
dG9sZCB3aGVuCj4gPiBzb21ldGhpbmcgY2FuIGJlIHJlbW92ZWQuIFRoaXMgaXMgYSBsYXJnZSBj
b3Jwb3JhdGlvbiB3aXRoIGxvdHMgb2YKPiA+IHN1YmNvbnRyYWN0b3JzLCBCMkIsIGV0Yy4sIGFu
ZCB3ZSdyZSBsb29raW5nIGZvciBpZGVhcyBvbiBob3cgb3RoZXJzCj4gPiBnZXQgYSBoYW5kbGUg
b24gdGhpcyAob3IgZG9lcyBhbnlib2R5PykuCj4gPgo+ID4gVGhhbmtzIGluIGFkdmFuY2UhCj4g
PiBNaWNoYWVsCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwo+ID4gZmlyZXdhbGwtd2l6YXJkcyBtYWlsaW5nIGxpc3QKPiA+IGZpcmV3YWxsLXdpemFy
ZHNAaG9ub3IuaWNzYWxhYnMuY29tCj4gPiBodHRwOi8vaG9ub3IuaWNzYWxhYnMuY29tL21haWxt
YW4vbGlzdGluZm8vZmlyZXdhbGwtd2l6YXJkcwo+ID4K
--__--__--
Message: 4
Date: Wed, 31 Aug 2005 20:02:11 -0400
From: Chuck Swiger <chuck@codefab.com>
Organization: CodeFab
To: Danny <nocmonkey@gmail.com>
Cc: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] Windows VPN/RRAS traffic through watchguard
Danny wrote:
> Now, a VPN "connection" is established from the Internet into the ISA
> server without a problem, however VPN traffic through the tunnel does
> not work most of the time. It's inconsistent but primarily does not
> work.
>
> So, now I try without the Watchguard in the picture, and the tunnel
> carries traffic just fine - as it should.
>
> Has anyone ever experience such a problem?
Are you using NAT? If so, you'll need to use a UDP-based system, and/or assign
unique TCP port numbers to each distinct connection. Otherwise, you'll
probably be limited to only having one VPN session active at a time.
Are you passing GRE through? I recently had to deal with a similar situation
involving Cisco's VPN hardware and their VPN client, and the following helps:
redirect_proto gre routerIP
redirect_port udp routerIP:500 500
redirect_port udp routerIP:4500 4500
redirect_port udp routerIP:62515 62515
redirect_port tcp routerIP:10000 10000
redirect_port tcp routerIP:pptp pptp
Replace routerIP with your ISA server's IP. YMMV.
--
-Chuck
--__--__--
Message: 5
Date: Thu, 1 Sep 2005 10:14:29 +1000
To: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] firewall rule lifecycle management
From: marty@supine.com (Martin)
$quoted_author = "Bruce Smith" ;
>
> From my PIX experience, clear rule counters every month. After a while, look
> for the rules that have zero counts and then remove them. Can be scripted
> and searched with grep.
that's a neat way of picking up dormant rules, but you'd still need to
review them manually to identify rules that should no longer be in place
even if traffic is still matching them.
cheers
marty
--
In the 60's, people took acid to make the world weird. Now the world is weird
and people take Prozac to make it normal.
--__--__--
Message: 6
Date: Wed, 31 Aug 2005 20:24:36 -0500
From: Kevin <kkadow@gmail.com>
To: "mason@schmitt.ca" <mason@schmitt.ca>
Subject: Re: [fw-wiz] stopping bots from phoning home
Cc: firewall-wizards@honor.icsalabs.com
On 8/31/05, mason@schmitt.ca <mason@schmitt.ca> wrote:
> It seems that the majority of bots connect to an IRC server in order to
> get their instructions and some spyware is starting to do the same. So i=
f
> the avenue for abuse of an infected machine is via connection to IRC
> networks, why not block all outbound IRC traffic (we have a Packeteer
> packet shaper that I think can classify IRC traffic regardless of the por=
t
> it runs on) and implement a proxy that legitimate users of IRC have to lo=
g
> into in order to gain access to IRC servers outside our network?
Sounds like a good plan, even without bots in the picture.
There are a few open source IRC proxies, including bnc, JBouncer, etc.
> This way an infected PC can't phone home, legitimate use of IRC is
> still possible with only a slight hurdle, and I can log all traffic that
> hits my block so that I can investigate those PCs.
We take this a step further -- let all traffic that hits the blocks talk
to a "sandbox" minimal IRCd, and if the traffic looks like bot chatter,
quarantine the source host.
If enough sites start doing this, the Zombie Masters will find a
new C&C channel for their 'bots, perhaps SSL web sites on TCP/443...
> However, I'm not talking about our company LAN or the servers that I
> manage. The network that takes the majority of my time is our customer
> network.
I'm not sure that an explicit proxy solution will fly in a public ISP,
customers just are not going to be comfortable with having to jump
through hoops when they're used to just being able to click on the
"live chat" button on their brokerage or Invader Zim webboard and go
right into a conversation. Most of the time the user doesn't even know
they are using IRC!
> I've posted before, but not often. I'm a sysadmin for a small cable ISP.
> I frequently struggle with the seemingly unworkable position of being
> transparent to our customers while simultaneously protecting them from
> themselves and the "big bad net". As you can well imagine, I can't make =
a
> default deny stance work in this environment, so I am left with exactly
> what I don't want to be doing which is watching for problems and trying t=
o
> stop them before they make a real mess... Needless to say, this sucks.
I don't know that the situation can be made to suck any less for a
public ISP. I've been in that boat, am glad to be back on dry land.
Kevin Kadow
--__--__--
Message: 7
Date: Wed, 31 Aug 2005 21:03:38 -0500
From: Victor Williams <vbwilliams@neb.rr.com>
To: Martin <marty@supine.com>
Cc: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] firewall rule lifecycle management
True.
That's why I've started commenting rules, or groups of rules. Then I
can go back later and determine if they are actually needed.
Martin wrote:
> $quoted_author = "Bruce Smith" ;
>
>>From my PIX experience, clear rule counters every month. After a while, look
>>for the rules that have zero counts and then remove them. Can be scripted
>>and searched with grep.
>
>
> that's a neat way of picking up dormant rules, but you'd still need to
> review them manually to identify rules that should no longer be in place
> even if traffic is still matching them.
>
> cheers
> marty
>
--__--__--
Message: 8
Date: Wed, 31 Aug 2005 22:33:23 -0400 (EDT)
From: "Paul D. Robertson" <paul@compuwar.net>
To: mason@schmitt.ca
Cc: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] stopping bots from phoning home
On Wed, 31 Aug 2005 mason@schmitt.ca wrote:
> It seems that the majority of bots connect to an IRC server in order to
> get their instructions and some spyware is starting to do the same. So if
Yep, hence the "if you don't need to pass it" mantra that I like to chant.
> the avenue for abuse of an infected machine is via connection to IRC
> networks, why not block all outbound IRC traffic (we have a Packeteer
> packet shaper that I think can classify IRC traffic regardless of the port
> it runs on) and implement a proxy that legitimate users of IRC have to log
> into in order to gain access to IRC servers outside our network? This way
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.
> an infected PC can't phone home, legitimate use of IRC is still possible
> with only a slight hurdle, and I can log all traffic that hits my block so
> that I can investigate those PCs.
>
> Your thoughts?
I'd probably look at who's using legitimate ports and offer them a
pass rule, or just pass them and close off everyone else, then get to
figuring out what's legitimate (there's a snooping line that you need to
be careful of.) Then make a new signup process that involves proxy info-
that'd probably get you less customer complaints than anything.
> Given that this flies in the face of this list's mantra of, "block
> outbound IRC, there is no business case for it's use" and "a default deny
> stance is far more secure than a default allow stance", I feel compelled
> to say that I absolutely fully agree with these points as well as the
> vast majority of security truisms that are stated repeatedly on this list.
> However, I'm not talking about our company LAN or the servers that I
> manage. The network that takes the majority of my time is our customer
> network.
>
> I've posted before, but not often. I'm a sysadmin for a small cable ISP.
> I frequently struggle with the seemingly unworkable position of being
> transparent to our customers while simultaneously protecting them from
> themselves and the "big bad net". As you can well imagine, I can't make a
> default deny stance work in this environment, so I am left with exactly
> what I don't want to be doing which is watching for problems and trying to
> stop them before they make a real mess... Needless to say, this sucks.
>
Like the last time this surfaced, I'd recommend offering the customers a
default deny option and see how many bite- if you can do per-user rules
(and I don't know what sort of scale you're talking about- MSOs come in
all sizes.) then you may get them to agree to it- I think the time is
right for that.
> Because I am in this state and we have very little man power for things
> such as maintaining router blacklist rules for known spyware sites, irc
> botnet controllers, etc (which have their own support staff payload and
> customer satisfaction issues as well), I'm always trying to think of ways
> of reducing our customer's exposure to threats without getting in their
> way more than I have to and without creating a maintenance nightmare for
> myself. I have implemented ingress/egress blocks for really common
> problem ports, configured multiple layer virus filtering for inbound and
> outbound email, we have a very cost effective anti-spam solution, I have
> blocked windows popup spam, etc, but spyware and bots are finding plenty
> of ways around my basic defences and the spyware problem is only going to
> get more pronounced. This is why I suggest awkward things like the
> authenticating IRC proxy idea above. I'm also currently looking at a
> multi function gateway (sounds just as cheesy as those multi function
> printer, fax, scanner things...) that does spyware, virus scanning and IPS
> on all traffic traversing our link.
You know, if we could get rid of the home user problem, all our lives
would get easier...
> At this point, I don't see any way around it. This is my quiet plea for
> answers.
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...
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
End of firewall-wizards Digest
No comments:
Post a Comment