Re:Vol 1 #247 - 9 msgs: Re: printer problem

["Zbonski, David" <DZbonski () thrupoint net>]

You could drop a hub/switch & PC on the "outside" and see if you can telnet
to the printer TCP port. If you can, it's the firewall.  If not, it's
something else - probably beyond your control.

David Zbonski
Internetwork Solutions Engineer
ThruPoint
Chicago, IL
DZbonski () ThruPoint net



-----Original Message-----
From: firewall-wizards-admin () nfr com
[mailto:firewall-wizards-admin () nfr com]On Behalf Of
firewall-wizards-request () nfr com
Sent: Thursday, May 10, 2001 11:01 AM
To: firewall-wizards () nfr com
Subject: firewall-wizards digest, Vol 1 #247 - 9 msgs


Send firewall-wizards mailing list submissions to
        firewall-wizards () nfr co
To subscribe or unsubscribe via the World Wide Web, visit
        http://www.nfr.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
        firewall-wizards-request () nfr com

You can reach the person managing the list at
        firewall-wizards-admin () nfr 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: printer problem (=?iso-8859-1?q?m=20p?=)
  2. SSL and negotiated key strength (Scott, Richard)
  3. Re: dhcp altering firewall rules (Stephan)
  4. Re: printer problem (Bill_Royds () pch gc ca)
  5. RE: SOAP/XML Protocol and filtering, etc. (Nigel Willson)
  6. Inappropriate TCP Resets Considered Harmful (Sally Floyd)
  7. Re: dhcp altering firewall rules (George Capehart)
  8. Re: printer problem (Don Kendrick)
  9. RE: SOAP/XML Protocol and filtering, etc. (Dawes, Rogan (ZA -
Johannesburg))

--__--__--

Message: 1
Date: Wed, 9 May 2001 11:59:20 +0200 (CEST)
From: =?iso-8859-1?q?m=20p?= <sumirati () yahoo de>
Subject: Re: [fw-wiz] printer problem
To: hermit1 <hermits () mac com>
Cc: firewall-wizards () nfr com

Hi,


traceroute works on a lower level of the TCP/IP
protocol hierachie than the ports are.

With traceroute itself you can not test it because of
this.

But, you can try nmap from www.insecure.org. With this
tool you can check many setups of ports (open,
half-open, blocked with ip-filtering etc)

with the output you can than say something about the
status of the rules.

but - if there is a ip-filter, which is stateful and
configured as a "black-hole" there is no (easy) way to
find out about.

bye then

marc

--- hermit1 <hermits () mac com> schrieb: > I have a very
odd problem.  There are people here
> using a remote printer,
> and last week they lost access to the printer.  Of
> course they blamed the
> firewall, but FW-1 logs show the connections going
> out just fine.  Doing a
> telnet to the remote IP on port 515 times out.
> Traceroute, ping, telnet -
> all reach the destination.  We tried from home (two
> different ISPs) and
> could not connect on port 515.
>
> Sounds like port 151 was blocked at their end, but
> users from other sites
> can reach that printer without trouble.  Their
> network person can reach the
> printer from his home ISP, and print.
>
> My guess is that someone somewhere put a block on
> port 515.  Is there any
> way to find such a block?  Doing traceroute on port
> 515 would be good.....
>
> Thanks,
> hermit1
>
>
>
>
> ***************************************************
> This is an email.  Don't rely on anything seen here
> as being accurate without testing it yourself.
> ***************************************************
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://www.nfr.com/mailman/listinfo/firewall-wizards


__________________________________________________________________
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de

--__--__--

Message: 2
From: "Scott, Richard" <Richard.Scott () BestBuy com>
To: firewall-wizards () nfr com
Date: Wed, 9 May 2001 11:38:40 -0500
charset="iso-8859-1"
Subject: [fw-wiz] SSL and negotiated key strength

Greetings all,

I've been playing around with SSL and Certificates and have come across a
problem.  I'm using apache and IIS as the web servers, and for an example
IE5 with 56bit capable encryption.

This is what I am seeing:

(1) With a global certificate, 128 bit shout be enforced, and for all
browsers that do not support 128 bit, the browser is "stepped up" somehow.

- With my 56bit capable browser, only 40bit encryption is negotiated, not
128bit.
- With a 128bit browser, 128bit is supported.

Shouldn't it be the case that 128bit be used for all browsers with
Verisign's Global Certificates... ?  I shouldn't have to define in apache or
IIS to force 128bit, or should I? I am wondering whether the option in IIS,
for example, to enforce 128bit, only permits browsers with the high crypto
pack installed on the client?


(2) Connecting to Fortify.com, the SSL test for a 56bit capable browser only
negotiates to 40bit, why does it not use 56bit?


I believe that 128bit crypto can be exported now, please correct me if I am
wrong, and hence outside connections using SSL with 128bit encryption is
legal?

Cheers
r.


Richard Scott
Information Security
? Best Buy World Headquarters
7075 Flying Cloud Drive
Eden Prairie, MN 55344 USA
The views expressed in this email do not represent Best Buy
or any of its subsidiaries.



--__--__--

Message: 3
Date: Wed, 9 May 2001 12:24:03 -0400 (EDT)
From: Stephan <chenette () ccs neu edu>
To: George Capehart <capegeo () opengroup org>
Cc: firewall-wizards () nfr com
Subject: Re: [fw-wiz] dhcp altering firewall rules


We do NAT everything. As far as firewall polcies go, we are doing
egress/ingress filtering.

Stephan

"Securing a computer system has traditionally been a battle of wits:
the penetrator tries to find holes, and the designer tries to close them."
--- M. Gosser ---

On Wed, 9 May 2001, George Capehart wrote:

> Stephan wrote:
> > I was hoping someone could recommend software that could interact with
> > DHCP and my openBSD firewall rules. I don't want anyone to be able to
set
> > a static IP address and bypass DHCP to get net. I want them to have to
> > gain their IP address dynamically from DHCP. Once they do that, I want
> > something to open up a rule in the firewall to that IP address is now an
> > IP address that can gain access to the outside world.
>
> I've been following this thread and up until now no one has asked the
> question, so I guess I will.  Why it is important to expose internal IP
> addresses to the outside world?  In some circles that is actively
> frowned upon.  Why not do NAT on the traffic?  Even SOHO
> firewall/routers do NAT.  If you expose your inside IP addresses to the
> world you're just providing nmappers with a lot of free information . .
> .
> --
> George W. Capehart                               Phone:  +1 704.953.1209
>                                                    Fax:  +1 704.853.2624
>
> SMS Messaging:  http://www.mobile.att.net/mc/personal/pager_show.html
>                 or
>                 mailto:  7049531209 () mobile att net
>
> "Does getiud() halt the spawning of child processes?"


--__--__--

Message: 4
From: Bill_Royds () pch gc ca
To: hermit1 <hermits () mac com>
Cc: firewall-wizards () nfr net
Date: Tue, 8 May 2001 14:08:00 -0400
Subject: Re: [fw-wiz] printer problem

Port 515 has been the object of many Internet attacks recently (LPrng
exploit)
so many ISPs may have blocked it.. Do a simple traceroute from your site to
printer and verify with ISPs on the way that they are not blocking it.
By the way, allowing printing over the Internet is a good way to get hacked
so
you really should find a better way to send your printing remotely.





hermit1 <hermits () mac com> on 05/08/2001 12:20:17



 To:      firewall-wizards () nfr net

 cc:      (bcc: Bill Royds/HullOttawa/PCH/CA)



 Subject: [fw-wiz] printer problem






I have a very odd problem.  There are people here using a remote printer,
and last week they lost access to the printer.  Of course they blamed the
firewall, but FW-1 logs show the connections going out just fine.  Doing a
telnet to the remote IP on port 515 times out.  Traceroute, ping, telnet -
all reach the destination.  We tried from home (two different ISPs) and
could not connect on port 515.

Sounds like port 151 was blocked at their end, but users from other sites
can reach that printer without trouble.  Their network person can reach the
printer from his home ISP, and print.

My guess is that someone somewhere put a block on port 515.  Is there any
way to find such a block?  Doing traceroute on port 515 would be good.....

Thanks,
hermit1







--__--__--

Message: 5
From: Nigel Willson <NWillson () tbg com>
To: "'Dawes, Rogan (ZA - Johannesburg)'" <rdawes () deloitte co za>,
'Mark Nottingham' <mnot () akamai com>, firewall-wizards () nfr com
Subject: RE: [fw-wiz] SOAP/XML Protocol and filtering, etc.
Date: Wed, 9 May 2001 12:36:50 -0600
charset="iso-8859-1"

Which leads to the notion that the last line of defense is the
application server that will process the request and is most
capable.

Firewalls are well past their sell-by date and if any port is
open then a protocol can be layered/tunnelled through it --
rendering the Firewall only a primary defense layer. Let them
do the thing they do best.

Proxies are typically a second line of defense, with more
intelligence and ability to filter the traffic once the noise
has been screened.

The issue is developing proxies and keeping pace with the
sophistication of evolving fluid applications.

So the bottom line seems the be that the application server itself,
1. needs a firewall service on its listening ports so that it is
protected according to its role and policy, 2. needs a "proxy"
policy-based pre-processor that will parse transactions and
discard those not authorized/specifically allowed/malicious.


> -----Original Message-----
> From: Dawes, Rogan (ZA - Johannesburg) [mailto:rdawes () deloitte co za]
> Sent: Monday, May 07, 2001 7:16 AM
> To: 'Mark Nottingham'; firewall-wizards () nfr com
> Subject: RE: [fw-wiz] SOAP/XML Protocol and filtering, etc.
>
>
> Hi Mark,
>
> The key thing to me is, what happens if the SOAPAction and
> the URI disagree?
>
> It would be simple to craft a message that would pass the
> firewall, based on
> the SOAPAction header, but turn out to call a completely
> different function
> based on the content of the XML.
>
> This suggests a flaw where one party (the firewall) permits
> an action, based
> on some information (the SOAPAction header), while the next party (the
> web-server/application server) takes action based on other
> information (the
> actual content of the XML)
>
> This seems to be asking for trouble.
>
> I would be happier to have a proxy that parsed the XML and
> took action based
> on the same information that the application server would be using.
>
> Rogan
>
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot () akamai com]
> Sent: 07 May 2001 07:46
> To: firewall-wizards () nfr com
> Subject: [fw-wiz] SOAP/XML Protocol and filtering, etc.
>
>
>
> [This was originally posted on the main IETF list, and it was
> suggested that this was a good place to go for input...]
>
> The W3C's XML Protocol WG [1], which is chartered with developing
> XML-based messaging based on SOAP [2], has been debating the merits
> of the SOAPAction header in SOAP's HTTP binding. I've taken it upon
> myself (with some misgivings ;) to solicit comments on the designs
> being discussed.
>
> Briefly, SOAPAction is intended to identify a service being accessed,
> independently from its URL. For example, if you're accessing a
> StockQuote service, you might put a URI which identifies this type of
> service in the SOAPAction header.
>
> The primary motivation of this is to allow firewall and filtering
> proxies to identify SOAP messages in HTTP and act appropriately.
>
> Some implementations and/or applications of SOAP also use SOAPAction
> for dispatch, but that's out of scope for this discussion.
>
> The three major designs being proposed are:
>   - allow any arbitrary URI to be placed in the SOAPAction header [3]
>   - force the content of the SOAPAction header to be the same as the
>     top-level XML namespace in the message body, thereby identifying
>     what kind of message it is (making this information available in
>     the header removes the requirement that the intermediary parse
>     the XML) [4]
>   - removing SOAPAction and requiring that only one service be
>     associated with any particular URI [5]
>
> I feel that if we're going to design something to satisfy an external
> requirement ("make SOAP play nice with firewalls, so they don't just
> block all SOAP messages"), we should consult with the affected
> communities.
>
> So, I would very much appreciate:
>   - constructive comments as to the designs
>   - pointers to mailing lists, etc. of communities that would be
>     interested in these issues (firewall admins, etc.)
>   - discussion of whether any such hints will be helpful for the
>     target audience
>   - pointers to filtering/access control techniques already used,
>     with particular emphasis on whether or not any current
>     implementations can identify HTTP headers and act upon them.
>
> Kind regards,
>
> [1] http://www.w3.org/2000/xp/Group/
> [2] http://www.w3.org/TR/SOAP
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0142.html
> [4] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0026.html
> [5] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0055.html
>
>
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://www.nfr.com/mailman/listinfo/firewall-wizards
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://www.nfr.com/mailman/listinfo/firewall-wizards

--__--__--

Message: 6
To: firewall-wizards () nfr com
From: Sally Floyd <floyd () aciri org>
Date: Tue, 08 May 2001 20:34:54 -0700
Subject: [fw-wiz] Inappropriate TCP Resets Considered Harmful

I am new to this mailing list, but I wanted to point people here
to a new internet-draft of mine on "Inappropriate TCP Resets Considered
Harmful", at
"http://www.ietf.org/internet-drafts/draft-floyd-tcp-reset-00.txt";,
which argues that firewalls should not send TCP Resets (RST) in response
to TCP SYN packets that contain flags in the TCP Reserved field.

(Of 24,000 or so web servers that we tested as part of the TBIT project,
only 300 or so were behind firewalls that send TCP resets in this case,
so clearly most of the world seems to be maintaining reasonably adequate
security without sending TCP Resets in this case.)

I just learned of this mailing list, so I thought that, as long as
I was writing something directed in part at firewall behavior, I
would send it to this list for feedback.

Thanks,
- Sally
http://www.aciri.org/floyd/

--__--__--

Message: 7
Date: Wed, 09 May 2001 06:41:41 +0800
From: George Capehart <capegeo () opengroup org>
To: Stephan <chenette () ccs neu edu>
Cc: firewall-wizards () nfr com
Subject: Re: [fw-wiz] dhcp altering firewall rules

Stephan wrote:
> I was hoping someone could recommend software that could interact with
> DHCP and my openBSD firewall rules. I don't want anyone to be able to set
> a static IP address and bypass DHCP to get net. I want them to have to
> gain their IP address dynamically from DHCP. Once they do that, I want
> something to open up a rule in the firewall to that IP address is now an
> IP address that can gain access to the outside world.

I've been following this thread and up until now no one has asked the
question, so I guess I will.  Why it is important to expose internal IP
addresses to the outside world?  In some circles that is actively
frowned upon.  Why not do NAT on the traffic?  Even SOHO
firewall/routers do NAT.  If you expose your inside IP addresses to the
world you're just providing nmappers with a lot of free information . .
.
--
George W. Capehart                               Phone:  +1 704.953.1209
                                                   Fax:  +1 704.853.2624

SMS Messaging:  http://www.mobile.att.net/mc/personal/pager_show.html
                or
                mailto:  7049531209 () mobile att net

"Does getiud() halt the spawning of child processes?"

--__--__--

Message: 8
Date: Tue, 08 May 2001 14:47:55 -0400
From: "Don Kendrick" <don () hackertrackers net>
To: "hermit1" <hermits () mac com>
Cc: firewall-wizards () nfr net
Subject: Re: [fw-wiz] printer problem

Take a look at hping...you can kinda trouceroute

*********** REPLY SEPARATOR  ***********

On 5/8/01 at 9:20 AM hermit1 wrote:

> I have a very odd problem.  There are people here using a remote printer,
> and last week they lost access to the printer.  Of course they blamed the
> firewall, but FW-1 logs show the connections going out just fine.  Doing a=

> telnet to the remote IP on port 515 times out.  Traceroute, ping, telnet -=

> all reach the destination.  We tried from home (two different ISPs) and
> could not connect on port 515.
>
> Sounds like port 151 was blocked at their end, but users from other sites
> can reach that printer without trouble.  Their network person can reach
> the
> printer from his home ISP, and print.
>
> My guess is that someone somewhere put a block on port 515.  Is there any
> way to find such a block?  Doing traceroute on port 515 would be good.....
>
> Thanks,
> hermit1
>
>
>
>
> ***************************************************
> This is an email.  Don't rely on anything seen here
> as being accurate without testing it yourself.
> ***************************************************
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://www.nfr.com/mailman/listinfo/firewall-wizards


Don Kendrick, CNE, GCIA, CCNA, CISSP


--__--__--

Message: 9
From: "Dawes, Rogan (ZA - Johannesburg)" <rdawes () deloitte co za>
To: firewall-wizards () nfr com
Subject: RE: [fw-wiz] SOAP/XML Protocol and filtering, etc.
Date: Wed, 9 May 2001 20:55:34 +0200
charset="iso-8859-1"

I think you have left out one option, which would be ideal, though less
likely :-)

The application itself is well (securely) coded, and comes by default with
no transactions enabled. Those transactions required must be specifically
enabled.

Rogan

-----Original Message-----
From: Nigel Willson [mailto:NWillson () tbg com]
Sent: 09 May 2001 08:37
To: 'Dawes, Rogan (ZA - Johannesburg)'; 'Mark Nottingham';
firewall-wizards () nfr com
Subject: RE: [fw-wiz] SOAP/XML Protocol and filtering, etc.


Which leads to the notion that the last line of defense is the
application server that will process the request and is most
capable.

Firewalls are well past their sell-by date and if any port is
open then a protocol can be layered/tunnelled through it --
rendering the Firewall only a primary defense layer. Let them
do the thing they do best.

Proxies are typically a second line of defense, with more
intelligence and ability to filter the traffic once the noise
has been screened.

The issue is developing proxies and keeping pace with the
sophistication of evolving fluid applications.

So the bottom line seems the be that the application server itself,
1. needs a firewall service on its listening ports so that it is
protected according to its role and policy, 2. needs a "proxy"
policy-based pre-processor that will parse transactions and
discard those not authorized/specifically allowed/malicious.


> -----Original Message-----
> From: Dawes, Rogan (ZA - Johannesburg) [mailto:rdawes () deloitte co za]
> Sent: Monday, May 07, 2001 7:16 AM
> To: 'Mark Nottingham'; firewall-wizards () nfr com
> Subject: RE: [fw-wiz] SOAP/XML Protocol and filtering, etc.
>
>
> Hi Mark,
>
> The key thing to me is, what happens if the SOAPAction and
> the URI disagree?
>
> It would be simple to craft a message that would pass the
> firewall, based on
> the SOAPAction header, but turn out to call a completely
> different function
> based on the content of the XML.
>
> This suggests a flaw where one party (the firewall) permits
> an action, based
> on some information (the SOAPAction header), while the next party (the
> web-server/application server) takes action based on other
> information (the
> actual content of the XML)
>
> This seems to be asking for trouble.
>
> I would be happier to have a proxy that parsed the XML and
> took action based
> on the same information that the application server would be using.
>
> Rogan
>
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot () akamai com]
> Sent: 07 May 2001 07:46
> To: firewall-wizards () nfr com
> Subject: [fw-wiz] SOAP/XML Protocol and filtering, etc.
>
>
>
> [This was originally posted on the main IETF list, and it was
> suggested that this was a good place to go for input...]
>
> The W3C's XML Protocol WG [1], which is chartered with developing
> XML-based messaging based on SOAP [2], has been debating the merits
> of the SOAPAction header in SOAP's HTTP binding. I've taken it upon
> myself (with some misgivings ;) to solicit comments on the designs
> being discussed.
>
> Briefly, SOAPAction is intended to identify a service being accessed,
> independently from its URL. For example, if you're accessing a
> StockQuote service, you might put a URI which identifies this type of
> service in the SOAPAction header.
>
> The primary motivation of this is to allow firewall and filtering
> proxies to identify SOAP messages in HTTP and act appropriately.
>
> Some implementations and/or applications of SOAP also use SOAPAction
> for dispatch, but that's out of scope for this discussion.
>
> The three major designs being proposed are:
>   - allow any arbitrary URI to be placed in the SOAPAction header [3]
>   - force the content of the SOAPAction header to be the same as the
>     top-level XML namespace in the message body, thereby identifying
>     what kind of message it is (making this information available in
>     the header removes the requirement that the intermediary parse
>     the XML) [4]
>   - removing SOAPAction and requiring that only one service be
>     associated with any particular URI [5]
>
> I feel that if we're going to design something to satisfy an external
> requirement ("make SOAP play nice with firewalls, so they don't just
> block all SOAP messages"), we should consult with the affected
> communities.
>
> So, I would very much appreciate:
>   - constructive comments as to the designs
>   - pointers to mailing lists, etc. of communities that would be
>     interested in these issues (firewall admins, etc.)
>   - discussion of whether any such hints will be helpful for the
>     target audience
>   - pointers to filtering/access control techniques already used,
>     with particular emphasis on whether or not any current
>     implementations can identify HTTP headers and act upon them.
>
> Kind regards,
>
> [1] http://www.w3.org/2000/xp/Group/
> [2] http://www.w3.org/TR/SOAP
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0142.html
> [4] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0026.html
> [5] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0055.html
>
>
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://www.nfr.com/mailman/listinfo/firewall-wizards
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://www.nfr.com/mailman/listinfo/firewall-wizards


--__--__--

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards


End of firewall-wizards
Digest_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards