Re: Subtle Info Leak of the Year...

2009-12-01 Thread Volker Kuhlmann
On Tue 01 Dec 2009 18:40:16 NZDT +1300, steve wrote:

 rfc 1122 3.2.2.6
 
 Every host MUST implement an ICMP Echo server function that receives
 Echo Requests and sends corresponding Echo Replies.

That was obiously written in the days of telnet when someone thought
both were a Good Idea(TM).

Volker

-- 
Volker Kuhlmann is list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.


Subtle Info Leak of the Year...

2009-11-30 Thread John Carter

We're mucking about with openwrt routers and we stumbled across this
curious scenario...


We couldn't ping the router yet we could see the ethernet mac address
in the arp cache.

Clear the address out of the cache, check it's not there, ping, the
ping fails, check the arp cache, and lo, the mac address is there
again!

The critical clue was the router could ping the PC.

Solution?

The router has a fairly fancy firewall thingy that was rejecting the
incoming ICMP ip packet, but the arp is handled at the ethernet MAC
layer _below_ the ip layer.

Hence the subject line... subtle info leak of the year.

Firewalls leak tiny bits of info at the mac level, even if they
reject everything at the IP level.



John Carter Phone : (64)(3) 358 6639
Tait ElectronicsFax   : (64)(3) 359 4632
PO Box 1645 ChristchurchEmail : john.car...@tait.co.nz
New Zealand



Re: Subtle Info Leak of the Year...

2009-11-30 Thread Douglas Royds
The MAC address of the router must be visible on the upstream link, or 
the router is useless. Isn't that the only information that is being 
leaked? The router is only trying to prevent pinging of boxes _behind_ 
the firewall. As a side effect, you can't ping the router.



John Carter wrote:

We're mucking about with openwrt routers and we stumbled across this
curious scenario...


We couldn't ping the router yet we could see the ethernet mac address
in the arp cache.

Clear the address out of the cache, check it's not there, ping, the
ping fails, check the arp cache, and lo, the mac address is there
again!

The critical clue was the router could ping the PC.


Solution?

The router has a fairly fancy firewall thingy that was rejecting the
incoming ICMP ip packet, but the arp is handled at the ethernet MAC
layer _below_ the ip layer.

Hence the subject line... subtle info leak of the year.

Firewalls leak tiny bits of info at the mac level, even if they
reject everything at the IP level.



John Carter Phone : (64)(3) 358 6639
Tait ElectronicsFax   : (64)(3) 359 4632
PO Box 1645 ChristchurchEmail : john.car...@tait.co.nz
New Zealand


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__



===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



Re: Subtle Info Leak of the Year...

2009-11-30 Thread Jim Cheetham
On Tue, Dec 1, 2009 at 5:22 PM, John Carter john.car...@tait.co.nz wrote:
 Firewalls leak tiny bits of info at the mac level, even if they
 reject everything at the IP level.

That's probably because the 'firewall' employed by Linux/OpenWRT is
called 'IP Tables', and has to receive an IP packet in order to decide
what to do; and on Ethernet that means ARP has to complete first.

Real network-level firewalls give you much lower-level controls,
should you need them. There are still some limits regarding what you
need to do in order to receive data, and some hacks to get around
that; but in an Ethernet network that leakage can be restricted to
just the nearest switch. IP Tables is basically a host firewall, and
the host can also be a router if it likes; but that doesn't make it
real network equipment. However, if all you're doing is running IP
networks, the difference is small enough to be ignored in most cases.

Oh, and as an aside; please allow your network edge devices to respond
to ping. It's very difficult telling the difference between an
ISP-link failure (i.e. a non-IP network) and a firewall failure if the
damn firewall won't respond to ping when everything is working
normally ...

-jim


Re: Subtle Info Leak of the Year...

2009-11-30 Thread John Carter

On Tue, 1 Dec 2009, Douglas Royds wrote:

The MAC address of the router must be visible on the upstream link, or the 
router is useless. Isn't that the only information that is being leaked? The 
router is only trying to prevent pinging of boxes _behind_ the firewall. As a 
side effect, you can't ping the router.



Not much info of value is being leaked except...

 * Existence. ie. If you thinking of a firewall as being invisible if
   it isn't jabbering, you're mistaken.

 * Nature. ie. You can infer the manufacturer from the mac
   address. Looking at the arp stream going by me with wireshark at
   the moment I can tell there are vmware virtual environments, cisco
   routers, toshiba, sun, intel,...

As I said, it's subtle. Nothing great..

Just enough to confuse the hell out of me for a while. A sort minor
WTF moment. How could arp be getting through but not ping?

Well, now I know.


John Carter Phone : (64)(3) 358 6639
Tait ElectronicsFax   : (64)(3) 359 4632
PO Box 1645 ChristchurchEmail : john.car...@tait.co.nz
New Zealand



Re: Subtle Info Leak of the Year...

2009-11-30 Thread John Carter

On Tue, 1 Dec 2009, Jim Cheetham wrote:


Oh, and as an aside; please allow your network edge devices to respond
to ping. It's very difficult telling the difference between an
ISP-link failure (i.e. a non-IP network) and a firewall failure if the
damn firewall won't respond to ping when everything is working
normally ...


I _love_ ping and never willingly harm my very very helpful little
friend.

Alas... the out of the box defaults for more and more things are
getting quite hostile.

Sigh!


John Carter Phone : (64)(3) 358 6639
Tait ElectronicsFax   : (64)(3) 359 4632
PO Box 1645 ChristchurchEmail : john.car...@tait.co.nz
New Zealand



Re: Subtle Info Leak of the Year...

2009-11-30 Thread steve
On Tue, 2009-12-01 at 18:23 +1300, John Carter wrote:
 On Tue, 1 Dec 2009, Jim Cheetham wrote:
 
  Oh, and as an aside; please allow your network edge devices to respond
  to ping. It's very difficult telling the difference between an
  ISP-link failure (i.e. a non-IP network) and a firewall failure if the
  damn firewall won't respond to ping when everything is working
  normally ...
 
 I _love_ ping and never willingly harm my very very helpful little
 friend.
 
 Alas... the out of the box defaults for more and more things are
 getting quite hostile.
 
 Sigh!

rfc 1122 3.2.2.6

Every host MUST implement an ICMP Echo server function that receives
Echo Requests and sends corresponding Echo Replies.

Steve
-- 
Steve Holdoway st...@greengecko.co.nz
http://www.greengecko.co.nz
MSN: st...@greengecko.co.nz
GPG Fingerprint = B337 828D 03E1 4F11 CB90  853C C8AB AF04 EF68 52E0


signature.asc
Description: This is a digitally signed message part