firewall-wizards@listserv.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com
You can reach the person managing the list at
firewall-wizards-owner@listserv.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. Re: Do you permit X11 via proxy firewall? (ArkanoiD)
2. Re: IPS Content filtering techniques (Skough Axel U/IT-S)
3. Re: NuFW and multiuser hosts (Pierre Chifflier)
4. Isolating internal servers behind firewalls (Dan Lynch)
5. Re: Managing multiple Cisco Pix's (James Burns)
----------------------------------------------------------------------
Message: 1
Date: Fri, 7 Sep 2007 02:25:00 +0400
From: ArkanoiD <ark@eltex.net>
Subject: Re: [fw-wiz] Do you permit X11 via proxy firewall?
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20070906222500.GA12081@eltex.net>
Content-Type: text/plain; charset=us-ascii
On Wed, Sep 05, 2007 at 04:48:46PM -0700, dlang@diginsite.com wrote:
> On Thu, 6 Sep 2007, ArkanoiD wrote:
>
> > That's most practical, almost everyone is doing that.
> > So we can declare x11 gateways officially dead, i guess.
> >
> > On Wed, Sep 05, 2007 at 05:02:50PM -0400, Paul Melson wrote:
> >>> And, if yes, how do you implement it?
> >>
> >> No, that's what 'ssh -X' is for.
>
> why is tunneling X through firewalls noticably safer then just doing packet
> filtering to allow it through?
Because it ensures proper endpoint authentication, encryption and ensures
(well, to some extent) that no malicious connections will be made through
the tunnel. At least does it better as packet filtering rules are static.
The same rationale applies for x11 gateways: most of them present a kind
of confirmation dialog for every new client connection.
> if the only answer is becouse it prevents someone from intercepting and
> tinkering with the TCP datastream then it's only relavent in some situations and
> you are saying that in others it's perfectly safe to just do packet filtering.
>
> remember, just becouse everyone is doing it, it may not be safe.
It is not, as nothing is safe, but sometimes it is acceptable risk ;-)
> remember almost everyone thinks that firewalls are just packet filters and have
> no business actually looking at the packets that they let through.
Not us ;-)
------------------------------
Message: 2
Date: Fri, 7 Sep 2007 16:53:27 +0200
From: "Skough Axel U/IT-S" <axel.skough@scb.se>
Subject: Re: [fw-wiz] IPS Content filtering techniques
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>, "Firewall Wizards Security
Mailing List" <firewall-wizards@listserv.cybertrust.com>
Cc: Panahi Behzad U/IT-S <behzad.panahi@scb.se>
Message-ID: <7D5607434F895540B2A717820399633D3FDD99@exs13.scb.intra>
Content-Type: text/plain; charset="iso-8859-1"
The situation mentioned by you is an error as the Content-Type is improperly specified.
I am not intedning to propagate for the bypass of erroneous packets!
But in the situation when no content body is present, i e, specified by the Content-Length: 0, then the Content-Type may be excluded (according to RFC 2616) because there is no body to describe.
But the content-filtering implementations I've seen do not respect this special case and assume - following the RFC 2616 - that the content type should be interpreted to be "application/octet-stream" as stated in RFC 2616 although no body is present! The "guessing" one can do in accordance with RFC 2616 in this case is that because no body is present then one doesn't worry about the content type, the content filtering can be bypassed in this situation or assumed to be whatsoever - it has no meaning when no body exists!
So a bypass under these circumstances would be fully RFC 2616 compliant as far as I can understand! (Some Web servers pass a declared content type although no body is present, this is not an error as too much data not is formally prohibited, but generates unneccessary overhead).
Best regards and thank you very much for your cooperation! Let's see what other vendors may have to say!
Axel
-----Original Message-----
From: firewall-wizards-bounces@listserv.icsalabs.com
[mailto:firewall-wizards-bounces@listserv.icsalabs.com]On Behalf Of
ArkanoiD
Sent: den 28 augusti 2007 23:39
To: Firewall Wizards Security Mailing List
Cc: Panahi Behzad U/IT-S
Subject: Re: [fw-wiz] IPS Content filtering techniques
But why does redirect have some content-type
other than text/html?
Well, i can fix my code by simply making content type check conditional
to existense of the response body. Is it ok for you?
On Tue, Aug 28, 2007 at 08:15:30AM +0200, Skough Axel U/IT-S wrote:
>
> It is because some systems send informative responses indicating redirects (permanent or temporarily), HTTP code 301 or 302.
>
> The ways these redirects are created vary strongly, sometimes a data buffer is given, but not always. The rediection directive is present in a HTTP header statement indicating alternate location.
>
> Some implementations omits declaring the data buffer content as none is present, thus the content is left unknown. A content-filtering firewall therefore doesn't allow a HTTP packet with unknown data to pass - this is correct - BUT should be able to allow HTT packets with no data, i e, Content-Length: 0. In this situation the Content-Type argument can be properly excluded as stated in the RFC 2616 and we cannot therefore encourage the opinion that there should be some error in such a packet from its vendor!
>
> Best regards,
>
> Axel
>
> ________________________________
>
> From: firewall-wizards-bounces@listserv.icsalabs.com on behalf of ArkanoiD
> Sent: Thu 2007-08-23 00:47
> To: Firewall Wizards Security Mailing List
> Cc: Panahi Behzad U/IT-S
> Subject: Re: [fw-wiz] IPS Content filtering techniques
>
>
>
> Well, what's the purpose of getting those null data through?
> Why do you need it?
>
> On Wed, Aug 15, 2007 at 03:35:24PM +0200, Skough Axel U/IT-S wrote:
> >
> > Does really nobody know anything about a Web proxy product filtering on MIME Content-Type setting and capable to omit this check when the MIME Content-Length setting in force appears to be zero? The RFC 2616 states that the Content-Type header statement can be omitted in this situation and, indeed, it has no meaning as the data section is declared to be of length zero.
> >
> > Otherwise the data section should of course be in general be assumed to be of type "application/octet-stream" but when no data section is present it is obviously no problem in bypassing the Content-Type check! Thus, there are no data to prevent entering for in this situation, but the packet in force may have othre meanings such as redirect etc.
> >
> > I would appreciate any comments in this matter!
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
> email protected and scanned by AdvascanTM - keeping email useful - www.advascan.com
>
>
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
------------------------------
Message: 3
Date: Fri, 07 Sep 2007 10:02:15 +0200
From: Pierre Chifflier <chifflier@cpe.fr>
Subject: Re: [fw-wiz] NuFW and multiuser hosts
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Cc: ArkanoiD <ark@eltex.net>
Message-ID: <46E10587.3020100@cpe.fr>
Content-Type: text/plain; charset=ISO-8859-1
ArkanoiD wrote:
> There is a firewall, NuFW, which primary feature is to differentiate
> users in multiuser hosts networking environment.
>
> Do you find it useful? Acutally use it? Or ever seen someone who does?
Hi,
NuFW works fine in multi-user environment (ssh, citrix, etc.). You need
to install a client, and every user need to authenticate to a server
(nuauth), generally connected to a LDAP or AD server, and some other
authentication methods are supported: all methods supported by pam (sql,
etc.), certificates, ...
Administration of the firewall is done using a web interface.
(http://demo.edenwall.com)
A very interesting feature is that it allows you to define filtering
rules based on person/groups, not on IP addresses. The rules are applied
for the user, regardless of the workstation (you can still define
filtering rules based on IP if you want), and if several users are
connected, rules are different for each user.
NuFW is available as an appliance, named edenwall. See
http://www.edenwall.com/EdenWall-Typical-uses.html for example.
NuFW is opensource, and free. The only exception is the windows client,
which has a commercial license . So if you use an opensource
environment, everything is free.
links:
http://www.inl.fr/NuWINc,68.html
Regards,
Pierre
------------------------------
Message: 4
Date: Mon, 7 May 2007 12:35:25 -0700
From: "Dan Lynch" <DLynch@placer.ca.gov>
Subject: [fw-wiz] Isolating internal servers behind firewalls
To: <firewall-wizards@listserv.icsalabs.com>
Message-ID: <D0DF79CFF2A93F4CBB11E01DECDEFB377B7B92@EX1.placerco.ad>
Content-Type: text/plain; charset="us-ascii"
Greetings list,
I'm looking for opinions on internal enterprise network firewalling. Our
environment is almost exclusively Microsoft Active Directory-based.
There are general purpose file servers, AD domain controllers, SMS
servers, Exchange servers, and MS-SQL-based datase app servers. In all
about 80+ servers for over 2500 users on about 2000 client machines, all
running Windows XP.
How prevalent is it to segregate internal use servers away from internal
clients behind firewalls? What benefits might we gain from the practice?
What threats are we protected from?
The firewall/security group argues that servers and clients should exist
in separate security zones, and that consolidating servers behind
firewalls allows us to
- Control which clients connect to which servers on what ports
- Centralized administration of that network access
- Centralized logging of network access
- a single point for intrusion detection and prevention measures
These benefits protect us from risk associated with internal attackers
and infected mobile devices or vendor workstations.
On the other hand, the server team counters that
- troubleshooting problems becomes more difficult
- firewall restrictions on which workstations can perform administration
makes general maintenance inconvenient, esp. in an emergency
- the threats we're countering are exceedingly rare
- a broken (or hacked) firewall config breaks all access to servers if
consolidated behind firewalls
Any and all thoughts are appreciated.
Dan Lynch, CISSP
Information Technology Analyst
County of Placer
Auburn, CA
------------------------------
Message: 5
Date: Thu, 06 Sep 2007 09:26:11 +0100
From: James Burns <james.burns@sunderland.ac.uk>
Subject: Re: [fw-wiz] Managing multiple Cisco Pix's
To: 'Firewall Wizards Security Mailing List'
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <46DFB9A3.50501@sunderland.ac.uk>
Content-Type: text/plain; charset="iso-8859-1"
Sorry, to clarify:
We will have two firewalls at either side of our campus serving the same
internal network, but with different /external/ addresses - this is
necessary because of the way that our provider has arranged things.
Each runs OSPF. Both units are, in effect, active - but no traffic will
be passed via the "backup" until the primary goes down, because of the
way that the routing is configured.
Cisco allows for active/active failover between Pix units, but ONLY if
they are running multiple security contexts, and we do not do this, nor
need to. What we're looking for is an elegant and preferably inexpensive
way of keeping the ruleset up-to-date on both boxes without the need to
manually edit on both every time a rule is added/amended.
Hope this makes things clearer!
James
Paul Melson wrote:
>> In effect we are going to end up with two separate devices, but that we
>>
> will want to have matching rulesets
>
>> on. My question, therefore, is - what software is available for managing
>>
> multiple Pix units, and (if you've
>
>> any experience of it) is it any good?
>>
>
> Just to be clear, you are going to have 2 firewalls. One through which all
> traffic will pass, and another through which no traffic will pass. Until
> the former breaks, in which case all traffic will manually be switched over
> to the latter. Correct so far?
>
> If you're comfortable with the command interface and manually editing
> configs (as opposed to using PDM from a web browser), then I would recommend
> Kiwi CatTools* for managing configurations.
>
> PaulM
>
> * http://www.kiwisyslog.com/kiwi-cattools-overview/
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20070906/80303350/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3281 bytes
Desc: S/MIME Cryptographic Signature
Url : https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20070906/80303350/attachment.bin
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 17, Issue 5
***********************************************
No comments:
Post a Comment