[prev in list] [next in list] [prev in thread] [next in thread] 

List:       firewalls-gc
Subject:    RE: Firewalls-Digest V5 #699
From:       "Tijani CHAOUCH BOURAOUI" <tbouraoui () msn ! com>
Date:       1997-01-03 6:38:54
[Download RAW message or body]



----------
From: 	firewalls-digest-owner@GreatCircle.COM on behalf of Firewalls-Digest
Sent: 	Thursday, January 02, 1997 1:00 AM
To: 	firewalls-digest@GreatCircle.COM
Subject: 	Firewalls-Digest V5 #699


Firewalls-Digest       Thursday, January 2 1997       Volume 05 : Number 699



In this issue:

        Re: Christopher Klaus and ISS
        RE: Air Force Web Site Hacked
        Re: DNS Proxy and Internal Root Name Server

See the end of the digest for information on subscribing to the Firewalls
or Firewalls-Digest mailing lists and on how to retrieve back issues.

----------------------------------------------------------------------

Date: Wed, 1 Jan 1997 19:06:25 -0500 (EST)
From: Todd Graham Lewis <lists@reflections.mindspring.com>
Subject: Re: Christopher Klaus and ISS

On Tue, 31 Dec 1996, Robert Hanson wrote:

> no disrespect intended to you Todd, yet....
> 
> kill! maime! shoot! my goodness... we are all capitalist pigs... what
> makes anyone better than anyone else standing next to them...

I not only like corporations, I work for one.  Believe it or not, I don't
even have a problem with vendors discussing their products on the list.
Those who offer help to newbies, contribute to technical discussions,
etc., are more than entitled to mention once in a while "BTW (disclaimer:
I work for 'em), our product X is designed to address this problem", or
even to say "In light of the discussion last month, I thought that the
list might be interested in our new product, SuperBlammo4000."

What I don't appreciate are bone-headed sales pitches coming from people
who never participate in the discussions on the list, and whose sole
purpose is to use the list as a free advertising channel.  

I don't think that this is too far off the mark, and the fact that Klaus
is a complete asshole just makes the decision that much easier.

(BTW, I'm sorry I wasn't able to participate in the discussion about Linux
firewalls.  I was visiting family during the holidays.)

__
Todd Graham Lewis             Linux!                 Core Engineering
Mindspring Enterprises  tlewis@mindspring.com   (800) 719 4664, x2804

------------------------------

Date: Thu, 2 Jan 1997 13:50:18 +0900
From: "Jason T. Luttgens" <luttgenj@kic.or.jp>
Subject: RE: Air Force Web Site Hacked

Why not get Practical Unix and Internet Security from O'Reilly and do what is 
says.
I bet if everyone disabled stupid services (on unix hosts), installed TCP 
wrappers to
allow telnets from limited IP addresses, did Cisco's recommendations on 
preventing
IP spoofing, used Linux or another free x86 Unix and ssh to telnet in, and 
subscribed
to security mailing lists to keep up on things, these incidents would slow 
down a LOT...how 
many people out there have done this to their unix host?? Get to work you 
system admins! 

All this is your fault......


- ----------
From:  Norm Laudermilch[SMTP:norm@UU.NET]
Sent:  Wednesday, January 01, 1997 8:57 AM
To:  firewalls@greatcircle.com
Subject:  Re: Air Force Web Site Hacked


[from Michael Idengren:]
> I don't know about the rest of you but I agree with the idea of putting a
> webserver on a CD-ROM.

[from Thomas Leitner:]
> why not just put it on a separate disk which is mounted
> read-only?

[from Dale Drew:]
> Using a CDROM web-server doesn't provide resistance to an 
> attacker who gains access to the system as ROOT...

Keep in mind that this entire thread assumes that the attacker will *not* 
take an easier approach, such as compromising the DNS records that point to
the server.  In this case, the attacker can create any web content they like,
spend all the time in the world creating it, and then quickly convince the
DNS servers that www.foo.com now resolves to the new (fake) address.  Securing
your www server is just a first (although important) step.

I do think read-only media is an interesting idea, by the way :)  Dale is 
right though, there are still vulnerabilities.  Personally, I like the idea 
of marking the files immutable myself.  This way, even root can't change the
content unless the machine is brought down into single-user mode.  Not sure
how many other operating systems support this other than (the great) BSDI
though.

Happy new year (2 minutes to go...),
Norm

- ----------------------------------------------------------------------
Have you cleaned your packet filter lately?     - Josh Osborne
- ----------------------------------------------------------------------
Norm Laudermilch                            E-mail: norm@uu.net
Manager, Information Security               Phone:  703-206-5952
UUNET Technologies, Inc.                    
3060 Williams Drive                        
Fairfax, VA 22031-4648                    
- ----------------------------------------------------------------------

------------------------------

Date: Thu, 02 Jan 1997 09:03:03 +0100
From: Jean-Francois ZWOBADA <zwobada@apogee-com.fr>
Subject: Re: DNS Proxy and Internal Root Name Server

At 16:59 31/12/1996 -0500, R. McMahon wrote:
>Background:
>I am looking at setting up a DNS proxy using "forwarders" and "slave"
>lines in by /etc/named.boot file as described in the "Building
>Firewalls" and "DNS and BIND" books by O'Reilly.  However, I want to do
>this where I can maintain an internal Root name server.  For resolution
>of domain names outside the internal top-level domains, I would like the
>proxy name server (which will have an "external" domain name) be the
>only name server queried by the internal root name server and having
>this proxy be the only host to query external name servers.  (I would
>set up UDP port 53 filtering on the router.)  
>
>Problem:
>One problem I thought of concerns the mitigation between the internal
>root name server and the forwarders/slave lines.  If a subordinate
>domain name server queries the root name server for an "outside" domain,
>how would it know to forward the query to the proxy (being that it is a
>internal root name server)?  I could have my subordinate top-level
>domain name serves query the proxy directly by putting forwarders line
>in it's /etc/named.boot, however, this would bypass the internal root
>structure.  It seems to be straight forward w/o an internal root name
>server, however, I need to maintain these root name server.  Can anyone
>help.
>
>Thanks,
>
>rwm
>
The problem with an internal root server is that it wont take any account
of your forwarders & slave options because it is said to be a root server.
The only solution I think of is adding the noforward patch in the named
daemons of the first level name servers you have under your root server.
You just have to specify all the domains known by your internal root
nameserver
so that your lower level nameserver would query it but would forward to your
proxy for everything else.

Hope this helps

Jean-Francois

PS: the noforward patch is available for BIND on ftp.vix.com (but I can't
remember the path...)

------------------------------

End of Firewalls-Digest V5 #699
*******************************

To unsubscribe from Firewalls-Digest, send the following command
in the body of a message to "Majordomo@GreatCircle.COM":

unsubscribe firewalls-digest

If you want to subscribe or unsubscribe an address other than the
account the mail is coming from, such as a local redistribution list,
then append that address to the command; for example, to subscribe
"local-firewalls":

subscribe firewalls-digest local-firewalls@your.domain.net

A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "firewalls-digest"
in the commands above with "firewalls".

Compressed back issues are available for anonymous FTP from
FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN"
is the volume number, and "MMM" is the issue number).

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic