Archived from groups: alt.internet.wireless (
More info?)
In article <56jqh055buov29uj52fu9t2t1sbb72s0dr@4ax.com>,
Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
:On 13 Aug 2004 19:40:02 GMT, roberson@ibd.nrc-cnrc.gc.ca (Walter
:Roberson) wrote:
:>It isn't impossible. I've posted code to do it.
:This code?
:http://groups.google.ca/groups?selm=bs125b%24do5%241%40canopus.cc.umanitoba.ca
That's the one.
:>To put it in more concrete terms: static map a public IP address to
:>one of the broadcast addresses listened to on the segment the WOL system
:>is on. In PIX terminology, this might be
:>static (inside, outside) 201.52.93.4 192.168.1.255
:Methinks (not sure) that it dumps everything from 201.52.93.4 to the
:LAN broadcast address. That would give an outside system access to
:the DHCP server and could theoreticaly be assigned a DHCP address on
:the LAN. They might also spoof a DHCP server. I dunno about this...
On the Cisco PIX, this sets up an address translation, but you still
need to set up an ACL on the outside interface in order for the packet
to be permitted through. One could eliminate the worries about DHCP
and so on by restricting the access by source IP, source port,
destination port [presuming TCP or UDP], ICMP major type [presuming
ICMP] or IP protocol [if you wanted to get more exotic and obscure
but not necessarily more secure.]
:Methinks an ACL that blocks broadcasts from the outside interface
:would effectively block it.
No, at the time the ACL is checked on the PIX, it is the *public*
IP that is examined. If the public IP is not one of the broadcast
ones for the network of the PIX outside interface, then the PIX doesn't
know at ACL checking time that the destination is a broadcast address.
On the PIX, if you want to block sending broadcasts inwards, you
have to either do so explicitly, or be careful with your 'permit'
statements and let the ACL fall off the end so that the traffic is
denied implicitly. There is no "no ip directed-broadcast" directive
on the PIX.
There is a circumstance under which the PIX checks for broadcast
addresses: if it sees a packet with a -source- IP that it believes is
a broadcast IP, then it will block it (at least if it's an inside
packet going out.) This blockage can happen accidently: if one
uses a 'static' command with a netmask other than 255.255.255.255
then the PIX treates the highest and lowest induced IPs as being
broadcast IPs and blocks packets sourced for them. This is nearly
the only place on the PIX where an IP mask is truely a netmask and
not just a [CIDR] bitmask, so this feature bites people from time to time.
:The way I kludged it on a Unix box was to setup a program that accepts
:input from a telnet connection to an IP socket run from inetd. The
:input is the MAC address of the target system. The packet is sent to
:the broadcast address of the LAN with a payload in magic packet
:format. It worked just fine 3 year ago, but I haven't done anything
:since then. I'm also a lousy programmer.
:There were a few problems. The big one is absolutely zero security.
:If I exposed the IP socket to the internet, any hacker could easily
:spray garbage all over my network. I have a router ACL rule to limit
:access to only my home system, but I would prefer an authorization
:system so I can use it anywhere.
Might I suggest using a http or https form with a small CGI backend
that checks the input for plausibility (e.g., isn't a broadcast
or multicast MAC, perhaps allows only ARIN-known manufacturer's prefixes]?
Going http or https would allow you to use a username/password system
for authorization; https would add encryption on top of that.
Coding it up to accept IPv6 would be a bit more work.
--
Scintillate, scintillate, globule vivific
Fain would I fathom thy nature specific.
Loftily poised on ether capacious
Strongly resembling a gem carbonaceous. -- Anon
Facebook
Twitter
Instagram