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. CISCO ROUTER AT THE BORDER (dmauro@cmpprinceton.com)
2. Excluding certain NAT in linux iptables? (Greg Spath)
3. Re: Host based vs network firewall in datacenter (Alin-Adrian Anton)
4. RE: Proxy - content filter related (Bruce Smith)
5. Re: SSH brute force attack (David Ross)
6. pptpproxy v2 released (Emmanuel Mogenet)
7. Opinion: Worst interface ever. (Paul D. Robertson)
8. Re: Opinion: Worst interface ever. (Marcus J. Ranum)
9. Re: Opinion: Worst interface ever. (Paul D. Robertson)
10. Re: Opinion: Worst interface ever. (Adam Jones)
--__--__--
Message: 1
Date: Fri, 01 Jul 2005 08:55:21 -0400
From: "dmauro@cmpprinceton.com" <dmauro@cmpprinceton.com>
To: <firewall-wizards@honor.icsalabs.com>
Subject: [fw-wiz] CISCO ROUTER AT THE BORDER
Can anyone help me to get an acl list made on this router. I have read a
lot of stuff but its time to do it. I read about netflow, but its not
supported on a 2600. I need to find out what comes in and what goes out in
a effective way, one that is not going to interupt anything. Any help would
be great, im trying to take the load off my firewall and secure my router
more then it is.
--__--__--
Message: 2
Date: Fri, 1 Jul 2005 11:44:06 -0400
From: Greg Spath <gkspath@armstrong.com>
To: firewall-wizards@honor.icsalabs.com
Organization: Armstrong World Industries
Subject: [fw-wiz] Excluding certain NAT in linux iptables?
Hi all,
My first post to the list, let me know if not on topic or if I should go
elsewhere.
Background:
We deploy a linux-based appliance to form branch office IPSec tunnels.
I've recently added a squid proxy to the mix, and want to use it
transparently using iptables REDIRECT.
This is all well and good, but there are certain Internal web server
auth methods (I'm sure you can guess which company) which this will
break (unless I spend far too much time building that configuration
into these squid caches).
So, for this pilot rollout, I want to redirect only stuff destined to
the Internet to the squid cache, and leave stuff that goes through the
tunnels alone.
Here is the line to direct everything (eth1 is my private interface on
the gateway):
/sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j
REDIRECT --to-port 3128
To exclude rfc1918, I did this:
/sbin/iptables -t nat -A PREROUTING -d 192.168.0.0/16 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -d 172.16.0.0/12 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -d 10.0.0.0/8 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j
REDIRECT--to-port 3128
Should it be "FORWARD" instead of "ACCEPT?" Is there a better way to do
this? I was unable to find any examples of this situation in any groups
or iptables documentation.
ACCEPT does work, btw. I just want to verify that I'm not doing
something stupid.
Thanks in advance for taking the time to read through this.
-- Greg
--
Greg Spath <gkspath@armstrong.com>
Infrastructure Security Analyst
Armstrong World Industries, Inc.
--__--__--
Message: 3
Date: Sun, 03 Jul 2005 02:36:59 +0300
From: Alin-Adrian Anton <aanton@spintech.ro>
To: sin <sin@pvs.ro>
Cc: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] Host based vs network firewall in datacenter
sin wrote:
> Alin-Adrian Anton wrote:
>
>
>>No matter what kind of network you have, you need at least one firewall
>>at the border with the Internet.
>>
>>Having a datacenter without a fast firewall at the border, is simply
>>insane.
>
>
> in fast firewall i presume you mean basic ACLs to filter much of the
> junk traffic, no ?
>
Fast firewall is fast firewall. The minimum requirement would be with
basic ACLs to filter junk traffic. If the circumstances can offer
better, the better the better.
>>The machine at the border can be some expensive hardware, like a cisco,
>>or can be a powerful BSD-based packet filter, sitting on powerful
>>hardware (the best you can get, Intel based).
>
>
> It can also be run on commodity hardware; expensive hardware it's not
> always gonna give you uber performance over cheaper hardware.
>
Correct. By all means, I've seen many second-hand brands doing a great
job for years without interruption. Powerful hardware doesn't necessarly
mean it has to be uber expensive ;). It just has to be decently
powerful, depending on loads, complexity of ACL, other needs, etc.
>
>
>>If you chose cisco-like solution, chose an expensive one. You defenately
>>need it (because expensive ones can handle smarter ACLs and keep state
>>much better, and also can resist to DDoS over 100 Mbps. Cheap ones may
>>die).
>
>
> every router dies because of DDOS if some part of that traffic is not
> filtered upstream, and by dieing i mean that you have a big chance
> running out of bandwidth before you run out of vip cpu power.
>
>
By dieing I mean literally provide malfunction and require a reboot (or
provide auto-reboot).
>
>>If you chose BSD solution use ipfw (fastest), or pf (best in terms of
>>what it can do). Pf on FreeBSD with Intel "FXP" cards is able to use the
>>hardware chip for checking CRC of the packets. This feature is only
>>available on FreeBSD, and as far as I know nobody ported it to other OS.
>>Having hardware to check for checksums greatly improves performance,
>>even over ipfw.
>
>
> Intel's Linux drivers also offer the same facility.
>
>
Great.
>
>>I would not chose a linux based solution for firewalling high loads of
>>evil traffic.
>
>
> can you also give some arguments why not ?
>
>
From my past experience, I've managed BSD much better. I don't want to
get into OS war, I'm not a holly knight. It's just my opinion, and
providing solid arguments would turn into a different thread, named "BSD
vs Linux" or viceversa.
Anyway iptables seems much buggier than BSD firewalls, and defenately it
is slower. However I never did benchmarks for such things.
>
>>Even better, if you can afford it, you can have both: the cisco and the
>>BSD, cisco sitting maybe in front of the BSD. This way you also keep a
>>simple and good control of what goes in and what goes out, and you can
>>cut down packets which the hardware firewall missed (it happens).
>
>
> firewalls just don't miss packets. they allow them to pass based on
> certain rules. maybe some software bugs can cause some unwanted packets
> to pass on certain situations.
>
I was reffering to a past situation when the DDOS contained random junk
with random valid protocols. This ment some of the junk went through the
ACL. (over 200 Mbps)
>
>>In case of a serious DDoS problem, you can even enable statefull ACL
>>version (keep it somewhere) on the BSD box, to really cut down whatever
>>the hardware firewall skips into the internal network.
>
>
> i believe you might want to do exactly the opposite, disabling any
> statefull ACLs on the router (you know, a 7500 cisco router can get
> pretty busy processing a high rate of small packets without any ACLs
> defined on a particular interface). adding statefull ACL's can have
> negative impact on the router performance in case of DoS/DDoS attack.
>
Depends on the situation. If your hardware is powerful enough, statefull
ACLs can take out the junk from the internal network way much better,
and prevent the situation of random junk traffic skipping inside the
network. A preset ACL for that (for example allow just HTTP/etc and
outgoing connections from within the internal network to outside) can
help. In order to allow outgoing connections you need statefull mechanisms.
I mean just how fast can the DDOS go? It can go as fast as your
bandwidth is allowed by your ISP. How much is that? 100 Mbps? 1 Gbps?
It's not hard to work with 100 Mbps stateful filter (on BSD and decent
hardware). For 1 Gbps you can use a multiprocessor or a firewall cluster
(PF on BSD with CARP for instance).
And that statefull firewall is going to be used only in rare situations,
like a DDOS. It won't help too much in cases of intrusion, but IDS can
be added (like an isolated SNORT machine logging and providing output).
I do 50-60 Mbps statefull inspection with PF (at home) on a P2 266 Mhz
second-hand Dell, without using Intel-based CRC check.
For real enviroments one needs write-back caches and fast RAM. And as
much as possible by budget/hardware slots.
>
>
>>On the inside land, it may be a very good idea to use any kind of
>>firewall you want on each machine, in order to limit access to SNMP (if
>>you are going to monitor them via SNMP), and so on. You should use a
>>different switch for the monitoring connection, such that an internal
>>server cannot impersonate you in any way (arp, ISN prediction, etc).
>
>
> It can get quite expensive doing out of band management on a fairly big
> network, and also somewhat complex.
>
Complex yes, too complex not (no need to shoot in the foot). Expensive,
no I don't think so. Just some basic local ACLs on the existing
hardware, at minimum.
>
>
>>Limit all services to what they really need to accept, and nothing else.
>>If they are not going to use the LAN, always bind them on the local
>>interface.
>>
>>Each host inside the lan should not trust anyone from the LAN, so
>>writing down what is strictly needed for each of them is a good thing.
>>Implementing it is the next step, I just pointed some ideas.
>
>
> it will have to trust another host by some degree...
>
Sure. But better is *much* better, otherwise just unplug the cables. I
know making it harder makes the difference. Maybe somebody knows a bug
in SNMP but doesn't know in SMTP. Fortunately he/she can't access the
SNMP, but he/she can connect to SMTP. Etc.. It minimizes the probability
that "the right person" will say hello from within the LAN.
Regards,
--
Alin-Adrian Anton
GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA)
gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA
"It is dangerous to be right when the government is wrong." - Voltaire
--__--__--
Message: 4
From: "Bruce Smith" <bruces@southerngold.co.za>
To: <aptgetd@gmail.com>, <firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Proxy - content filter related
Date: Sun, 3 Jul 2005 22:08:16 +0200
Hi,
This isn't a direct answer to your question, but here's my 2000 lira.
Simplest way to do this is to get some sort of firewall, *BSD, *Linux or
even a Linksys class box, in place and to block outgoing traffic except for
the proxy server. Force the little ones through the proxy by making it the
only route to the Internet. If they can get a direct route, NATed or
unNATed, to the Internet, then there's a big problem if the idea is to
control what they have access to. Then the proxy can do the work it's
supposed to be doing.
If the kids are using tunneling software that goes via legitimate channels,
then you're s****ed. They're already several steps ahead of you and you're
never going to catch up. We run in a billing situation and try to control
access to media files to conserve bandwidth. When the users began tunneling,
we investigated ideas on how to block them and found that since we were
getting the money for the tunneled traffic anyway (goes through the billing
proxy), it wasn't worth our while.
As for sniffing flowing traffic, you would have to stick a *BSD or *Linux
router in the path, hook a sniffer like Ethereal to it and hunt through what
is probably large volumes of traffic. With the capture filters that Ethereal
can use, you could try and catch the first packets in a conversation only.
That would lessen the volume. Another option is to use Snort in a
listen-only configuration, although this may require a switch capable of
spanning ports, and write custom rules to look for HTTP traffic, unless they
already exist.
Hope this has helped a bit.
Regards
Bruce Smith
-----Original Message-----
From: firewall-wizards-admin@honor.icsalabs.com
[mailto:firewall-wizards-admin@honor.icsalabs.com] On Behalf Of noc ops
Sent: Thursday, June 30, 2005 7:21 PM
To: firewall-wizards@honor.icsalabs.com
Subject: [fw-wiz] Proxy - content filter related
Hi,
I'm not sure if my previous e-mail made it the list as I didn't see it.
Anyway, here it is again and my apologies for any duplication.
Is it possible to look at the *outgoing* client-proxy request headers
(w/o going through a local proxy server) in order to identify/block
proxy related traffic?
a. users (user-agent) to non-SSL HTTP proxies
b. users (user-agent) to SLL HTTP proxy (encrypted)
Since the traffic is being redirected (transparently) via school's
content filter appliance (open-source product), does it make sense to
enable proxy so that the appliance provides SSL & non-SSL tunneling
CONNECT extension method, so that we can identify (via CONNECT) and
filter traffic (via keyword). Is it a worthwhile effort?
I can't see any other way to address proxy related traffic (google web
accelerator as an example) which is currently bypasses our content
filter based on egress traffic. Unless I perform deep packet inspection,
look for incoming response, which might slow things down since filtering
is being done in the software.
I'm not sure what I can get out of SSL proxy packets since it creates
a secure connection (encrypted session) between client and server but
any thoughts will be greatly appreciated.
The purpose of this is to inspect/block naughty sites which students
access using third party proxies to bypass school's content filter(s).
I'm trying to help a public school with this issue and any help will be
awesome!
Any pointers to any in-depth papers or books which talks about proxies
in depth will be excellent.
Appreciate your time/help.
regards,
/vicky
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
--__--__--
Message: 5
Date: Sun, 03 Jul 2005 21:37:43 +0000
From: David Ross <David.Ross@isrc.qut.edu.au>
Reply-To: David.Ross@member.sage-au.org.au
Organization: Information Security Institute
To: "Toderick, Lee W" <TODERICKL@MAIL.ECU.EDU>
Cc: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] SSH brute force attack
Toderick, Lee W wrote:
> Our computers running SSH daemons have logged attacks. The attacks begin
> with a scan logged "Did not receive identification string from x.x.x.x",
> followed approximately 15 minutes later with "Illegal user " or " Failed
> password for root".
>
> Does anyone have information or documentation about this scan/attack?
I see it daily - and usually ignore it.
Sometimes I filter the address blocks if they belong to ISPs in
countries that I am unlikely to visit (and hence ssh from).
That keeps the logs manageable.
--
David Ross
--__--__--
Message: 6
Date: Tue, 05 Jul 2005 03:07:30 -0700
From: Emmanuel Mogenet <mgix@mgix.com>
To: firewall-wizards@honor.icsalabs.com
Subject: [fw-wiz] pptpproxy v2 released
Release 2 of pptpproxy, a PPTP userland
proxy for Unix firewalls is available at
http://www.mgix.com/pptpproxy
--__--__--
Message: 7
Date: Tue, 5 Jul 2005 08:54:40 -0400 (EDT)
From: "Paul D. Robertson" <paul@compuwar.net>
To: firewall-wizards@icsalabs.com
Subject: [fw-wiz] Opinion: Worst interface ever.
I spent some time last week installing a new Watchguard X series appliance
at a customer site. It's the single most frustrating firewall install I
think I've ever done. Now, I've got a lot of not-my-favorite things on my
firewall list, but Watchguard has pretty much moved near the top just
based on the software interface.
I have a second customer co-located with this one, and they have a
Watchguard V series appliance with the Vcontroller software. I figured
I'd make it easy on anyone administering both sites by using the same
firewall vendor. While the V series software isn't the prettiest thing,
it's at least intuitive and functional to me.
The new Watchguard software "automatically" decides ruleset evaluation
order, and there's no easy way that I can find to figure out what order
something's going to be evaluated in. Worse-yet, the logging software for
Windows doesn't even appear to be on the CD with the other software, so
"check the logs" starts to become an exercise in futility (thank goodness
I had a Linux box in the DMZ that I could syslog to- if it didn't support
syslog, it was getting shipped back!)
In the old software, it took me a whopping half a minute to set up an
inbound rule with authentication and NAT *without* reading the
documentation. In the new software we're talking ~45 minutes *following*
the documentation to get it set up and actually functional (set up was
easy, functional seemed to be rather quirky, and I'm still not sure why.)
Calling for support got me a "we just outsourced out support to India,
if you want a call back from US support press $foo" message that gets you
to a receptionist who happily transfers you to hold music in India. I got
it working (but not figured out) while on hold, so I decided that I didn't
want to experience support that came with a "if you can't understand"
warning up front- mostly because I was too upset to deal with some 1st
level support person who was new at their job in any type of civil manner
even without potential communication issues.
The firewall functions fine, tests just fine, and once it's configured,
seems to do the right thing. However, I've installed a fair number of
firewalls in my day, and this is the only time the experience has been so
frustrating that even after a long weekend, I'm *still* agitated over the
experience enough to rant about it.
I can't even imagine trying to audit the "we'll pick the most exact match"
ruleset evaluation of one of these beasts. If I thought there was any
chance the old software would work with the new box, I'd be loading that
tomorrow. My "same vendor" rationale is right out the window- the two
products aren't even close- other than the fact they're both red.
Maybe I'm too stupid for the new interface. Maybe I can't follow the
instructions in the manual well. As I said, the product functions just
fine, I just can't deal with the interface at all.
Adding to my frustration, every link in the manual requires you to have
authentication credentials for their Web site. Of course, in my case, the
person who set all that up was out for the holiday weekend, making finding
additional information a "call support" type of activity.
While I'm ranting- what's with support hours from 9-6pm *at my location*?
Hello Watchguard- firewalls are *production* boxes, downtime doesn't get
scheduled for when the users are still working!
I'll be happy to approve responses from anyone who feels the least bit
slighted by my opinions, or who wants to address any of this directly.
I'll also happily take personal e-mails on the issues.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
paul@compuwar.net which may have no basis whatsoever in fact."
--__--__--
Message: 8
Date: Tue, 05 Jul 2005 09:25:48 -0400
To: "Paul D. Robertson" <paul@compuwar.net>,
firewall-wizards@icsalabs.com
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] Opinion: Worst interface ever.
Paul D. Robertson wrote:
>The new Watchguard software "automatically" decides ruleset evaluation
>order, and there's no easy way that I can find to figure out what order
>something's going to be evaluated in.
That's a chip-head thing, Paul. Remember - it's all about performance,
not security. By re-ordering the ruleset the firewall can evaluate the
rules in the fastest possible manner. I had this explained to me once
by an engineer who builds ASIC firewalls for a living - he thought it was
a very cool optimization.
When I suggested that they optimize the "deny all" default deny to the
top of the sequence, because then it'd really scream - it took him a
couple of seconds to laugh.
mjr.
--__--__--
Message: 9
Date: Tue, 5 Jul 2005 09:45:43 -0400 (EDT)
From: "Paul D. Robertson" <paul@compuwar.net>
To: "Marcus J. Ranum" <mjr@ranum.com>
Cc: firewall-wizards@icsalabs.com
Subject: Re: [fw-wiz] Opinion: Worst interface ever.
On Tue, 5 Jul 2005, Marcus J. Ranum wrote:
> That's a chip-head thing, Paul. Remember - it's all about performance,
> not security. By re-ordering the ruleset the firewall can evaluate the
> rules in the fastest possible manner. I had this explained to me once
> by an engineer who builds ASIC firewalls for a living - he thought it was
> a very cool optimization.
I don't mind the optimization[1], I mind the fact that the UI won't tell
me how the rules are optimized. I mind that I can't seem to find the
logging software on the disk the UI came on, so I can't even see what the
heck rule is making the box send out ICMP port unreachables. I mind that
following the instructions doesn't produce the results I expect.
If I ever have to audit one of these things, I'm charging extra.
> When I suggested that they optimize the "deny all" default deny to the
> top of the sequence, because then it'd really scream - it took him a
> couple of seconds to laugh.
I bet!
Paul
[1] Caveat: I'd like to be able to override it in a perfect world.
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
paul@compuwar.net which may have no basis whatsoever in fact."
--__--__--
Message: 10
Date: Tue, 5 Jul 2005 08:54:40 -0500
From: Adam Jones <ajones1@gmail.com>
Reply-To: Adam Jones <ajones1@gmail.com>
Subject: Re: [fw-wiz] Opinion: Worst interface ever.
Cc: firewall-wizards@icsalabs.com
On 7/5/05, Marcus J. Ranum <mjr@ranum.com> wrote:
> Paul D. Robertson wrote:
> >The new Watchguard software "automatically" decides ruleset evaluation
> >order, and there's no easy way that I can find to figure out what order
> >something's going to be evaluated in.
>=20
> That's a chip-head thing, Paul. Remember - it's all about performance,
> not security. By re-ordering the ruleset the firewall can evaluate the
> rules in the fastest possible manner. I had this explained to me once
> by an engineer who builds ASIC firewalls for a living - he thought it was
> a very cool optimization.
>=20
> When I suggested that they optimize the "deny all" default deny to the
> top of the sequence, because then it'd really scream - it took him a
> couple of seconds to laugh.
>=20
> mjr.
>=20
Although I understand why the auto-optimization would be important,
shouldn't it be intuitive to look up what the rule order is? Maybe
this is inexperience talking but I cannot see optimizing the rule
order on a by-packet or by-host basis. At that point you are left to
either larger subsets of the internet, or a general rule order. Either
way it seems rediculous to not provide an easy to use means of at
least looking up the current rule order.It sounds like the original
poster at least knows his way around firewall software, which should
be enough to rule out user error in any halfway decent design.
I would say that you should at least discuss your problems with the
software and see if your client wants to return it. Having your
firewall expert spend ~45 minutes poking through the interface to
accomplish basic tasks sounds like the beginnings of a downtime
nightmare to me. If it took that long just to get a reasonably
standard configuration going how long will it take to troubleshoot a
complex problem?
--__--__--
_______________________________________________
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