Since we are talking about it.
I had previously requested a subnet and was approved. I originally thought
I was going to have to do an IPIP tunnel but I was able to get my ISP to
advertise the route. I went to the allocation section on my portal and
checked the box under Direct. Do I need to do anything else? The ticket
hit the queue at my ISP and they are just waiting for authorization. I
was hoping to get the new firewall installed on November 4th.
Thanks for all of your help. I personally like how helpful and
informative everyone is.
Mike Vespoli
KE0HFH
Leaving already? It's a good place to share amateur radio networking ideas.
<div>-------- Original message --------</div><div>From: Loren Tedford <loren(a)lorentedford.com> </div><div>Date:10/17/2017 14:58 (GMT-05:00) </div><div>To: 44net <44net(a)mailman.ampr.org> </div><div>Cc: </div><div>Subject: Re: [44net] Getting Started Requesting ips </div><div>
</div>I just want to say good bye to the group 73 thanks for the fun while it
last ~ KC9ZHV
On 2017-10-17 11:13, Loren Tedford wrote:
> Ok so i sent off to get a /24 however the statement that came back to
> me was i need to put this under IL so my question is... Is this
> because i live in IL or because you think i will be routing this from
> all from IL..
>
> I own several servers around the country I rent and release servers
> all the time.. I have currently servers in Canada, London and just
> shut down one in Dallas Texas so what i am trying to say is that all
> ip's may not be pointed to IL all the time is this an issue? I guess i
> am kinda confused as to why under IL..
>
> Here is the message.
> Request rejected. You are located in Illinois, please apply in the
> Illinois subnet, 44.72.
>
>
>
>
> --
> LOREN TEDFORD (KC9ZHV)
> Phone:618-553-0806
> Fax: 1-618-551-2755
> http://www.lorentedford.com
> ***************************************************
> CONFIDENTIALITY NOTICE: Confidential information, such as
> identifiable
> patient health information or business information, is subject to
> protection under state and federal law. If you are not the intended
> recipient of this message, you may not disclose, print, copy or
> disseminate
> this information. If you have received this in error, please reply and
> notify the sender (only) and delete the message. Unauthorized
> interception
> of this e-mail is a violation of federal criminal law.
> **************************************************
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
--
LOREN TEDFORD (KC9ZHV)
Phone:618-553-0806
Fax: 1-618-551-2755
http://www.lorentedford.com
***************************************************
CONFIDENTIALITY NOTICE: Confidential information, such as identifiable
patient health information or business information, is subject to
protection under state and federal law. If you are not the intended
recipient of this message, you may not disclose, print, copy or disseminate
this information. If you have received this in error, please reply and
notify the sender (only) and delete the message. Unauthorized interception
of this e-mail is a violation of federal criminal law.
**************************************************
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
Network Working Group V. Cerf
Request for Comments: 2468 MCI
Category: Informational October 1998
I REMEMBER IANA
October 17, 1998
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Remembrance
A long time ago, in a network, far far away, a great adventure took
place!
Out of the chaos of new ideas for communication, the experiments, the
tentative designs, and crucible of testing, there emerged a
cornucopia of networks. Beginning with the ARPANET, an endless
stream of networks evolved, and ultimately were interlinked to become
the Internet. Someone had to keep track of all the protocols, the
identifiers, networks and addresses and ultimately the names of all
the things in the networked universe. And someone had to keep track
of all the information that erupted with volcanic force from the
intensity of the debates and discussions and endless invention that
has continued unabated for 30 years. That someone was Jonathan B.
Postel, our Internet Assigned Numbers Authority, friend, engineer,
confidant, leader, icon, and now, first of the giants to depart from
our midst.
Jon, our beloved IANA, is gone. Even as I write these words I cannot
quite grasp this stark fact. We had almost lost him once before in
1991. Surely we knew he was at risk as are we all. But he had been
our rock, the foundation on which our every web search and email was
built, always there to mediate the random dispute, to remind us when
our documentation did not do justice to its subject, to make
difficult decisions with apparent ease, and to consult when careful
consideration was needed. We will survive our loss and we will
remember. He has left a monumental legacy for all Internauts to
Cerf Informational [Page 1]
RFC 2468 I REMEMBER IANA October 1998
contemplate. Steadfast service for decades, moving when others
seemed paralyzed, always finding the right course in a complex
minefield of technical and sometimes political obstacles.
Jon and I went to the same high school, Van Nuys High, in the San
Fernando Valley north of Los Angeles. But we were in different
classes and I really didn't know him then. Our real meeting came at
UCLA when we became a part of a group of graduate students working
for Professor Leonard Kleinrock on the ARPANET project. Steve
Crocker was another of the Van Nuys crowd who was part of the team
and led the development of the first host-host protocols for the
ARPANET. When Steve invented the idea of the Request for Comments
series, Jon became the instant editor. When we needed to keep track
of all the hosts and protocol identifiers, Jon volunteered to be the
Numbers Czar and later the IANA once the Internet was in place.
Jon was a founding member of the Internet Architecture Board and
served continuously from its founding to the present. He was the
FIRST individual member of the Internet Society I know, because he
and Steve Wolff raced to see who could fill out the application forms
and make payment first and Jon won. He served as a trustee of the
Internet Society. He was the custodian of the .US domain, a founder
of the Los Nettos Internet service, and, by the way, managed the
networking research division of USC Information Sciences Institute.
Jon loved the outdoors. I know he used to enjoy backpacking in the
high Sierras around Yosemite. Bearded and sandaled, Jon was our
resident hippie-patriarch at UCLA. He was a private person but fully
capable of engaging photon torpedoes and going to battle stations in
a good engineering argument. And he could be stubborn beyond all
expectation. He could have outwaited the Sphinx in a staring
contest, I think.
Jon inspired loyalty and steadfast devotion among his friends and his
colleagues. For me, he personified the words "selfless service".
For nearly 30 years, Jon has served us all, taken little in return,
indeed sometimes receiving abuse when he should have received our
deepest appreciation. It was particularly gratifying at the last
Internet Society meeting in Geneva to see Jon receive the Silver
Medal of the International Telecommunications Union. It is an award
generally reserved for Heads of State, but I can think of no one more
deserving of global recognition for his contributions.
While it seems almost impossible to avoid feeling an enormous sense
of loss, as if a yawning gap in our networked universe had opened up
and swallowed our friend, I must tell you that I am comforted as I
contemplate what Jon has wrought. He leaves a legacy of edited
documents that tell our collective Internet story, including not only
Cerf Informational [Page 2]
RFC 2468 I REMEMBER IANA October 1998
the technical but also the poetic and whimsical as well. He
completed the incorporation of a successor to his service as IANA and
leaves a lasting legacy of service to the community in that role.
His memory is rich and vibrant and will not fade from our collective
consciousness. "What would Jon have done?", we will think, as we
wrestle in the days ahead with the problems Jon kept so well tamed
for so many years.
There will almost surely be many memorials to Jon's monumental
service to the Internet Community. As current chairman of the
Internet Society, I pledge to establish an award in Jon's name to
recognize long-standing service to the community, the Jonathan B.
Postel Service Award, which will be awarded to Jon posthumously as
its first recipient.
If Jon were here, I am sure he would urge us not to mourn his passing
but to celebrate his life and his contributions. He would remind us
that there is still much work to be done and that we now have the
responsibility and the opportunity to do our part. I doubt that
anyone could possibly duplicate his record, but it stands as a
measure of one man's astonishing contribution to a community he knew
and loved.
Security Considerations
Security issues are not relevant to this Remembrance.
Author's Address
Vinton G. Cerf
MCI
EMail: vcerf(a)mci.net
Cerf Informational [Page 3]
RFC 2468 I REMEMBER IANA October 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Cerf Informational [Page 4]
> I've noticed that after I've leaven the router a few days with the DNS
> relay open (big mistake!), I was receiving a stream of dummy querys
> about a hundred per second.
Indeed that is a big mistake :-)
But it is good that you know that and so you can take countermeasures.
Normally after a couple of days this flood will stop, although there is
always some remaining noise from other kinds of DDoS.
E.g. systems on internet sending a DNS request like that to a resolver they
want to attack, with (one of) your address(es) as the source. The resolver
will send back the large "reply" to your system and there is nothing that
can be done about it. The source address of the packets is the system under
attack, and it is no use sending an abuse message to them because they cannot
do anything either (except blocking DNS requests from 44.x.x.x addresses, but
that could result in "problems" for legitimate users in our network).
This problem can only be solved by widespread adoption of BCP38 (source
address filtering), and the takeup is slow.
Anyway, when configuring your firewall make sure you have a "default deny"
policy and allow only the protocols that you know you are using. This is
especially true for UDP. e.g. SNMP (UDP port 161) is another attack vector
similar to what you have seen now. Don't allow SNMP from the internet.
Best is to allow only what you really need, and for protocols like NTP (UDP 123)
make sure that it is correctly configured so that it only does time replies
to internet addresses and does not allow queries except from the local network.
(queries can return much more data than the size of the query packet so they
are used in amplification attacks, time replies are the same size as the request)
Rob
Hello everyone,
I'm creating a gateway here, to be used to static and dynamic VPNs to
Portuguese HAMs trying to access the 44net.
I've noticed that after I've leaven the router a few days with the DNS
relay open (big mistake!), I was receiving a stream of dummy querys
about a hundred per second.
I was able to block it in our (Lisbon Polytechnics) firewall (before
ipip de-encapsulation) with the next iptables rule:
# iptables -t raw -A PREROUTING -i eth0 -p ipencap -d 193.137.237.9 -m
length --length 87 -m u32 --u32 "42 = 0x0035002f" -j DROP
Now I've disabled the gateway at the AMPR portal and I'll wait for them
to calm down.
I don't know if more tunnels are affected by this so I'm sharing the
information.
tcpdump output at the firewall:
> 10:24:57.864885 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864886 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864888 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864889 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864929 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864931 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864933 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864934 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864936 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864937 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864938 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864940 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864941 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864943 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864944 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
> 10:24:57.864945 IP 169.228.34.84 > 193.137.237.9: IP
> 101.173.185.122.17596 > 44.158.128.1.53: 46623+ [1au] ANY? activum.nu.
> (39) (ipip-proto-4)
73!
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Callsign: CT7ABP
QRA: Pedro Ribeiro
GRID Locator: IM58mr
QTH: São Francisco, Alcochete, Portugal
NET: http://www.qrz.com/db/CT7ABP
CT7ABP is also home station of CR7AJI Diogo
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I've turned off greylisting on mailman.ampr.org as it seemed to
be causing more trouble than it was fixing. We'll just have to
see how bad the spam problems get, and may have to turn it back
on again sometime down the road.
In the meantime, mail to the mailing list should no longer be
delayed by greylisting requiring senders to retry delivery.
- Brian
Alright just when you think you are a pro, I am a bit puzzled:
I am trying to deploy a new gateway. The router runs tomato shibby
firmware with DMZ pointed to 192.168.1.44, the ampr-gw.
When I run tcpdump I see the rip announcements and my route table is
populating, but I don't see my test pings, etc coming from the general
internet (and there is a dns entry)
Do you have to set a special ip rule vs if the wan interface is an
outside IP. I have a tried a few things that I thought made sense
with no luck. Could someone who is also behind nat share their start
script with me?
I guess I need to build a gateways with different hardware more often.
Thanks
11:50:01.034204 IP (tos 0x0, ttl 49, id 11797, offset 0, flags [none],
proto IPIP (4), length 552)
169.228.34.84 > 192.168.1.44: IP (tos 0x0, ttl 255, id 0, offset
0, flags [none], proto UDP (17), length 532)
44.0.0.1.520 > 224.0.0.9.520: [no cksum]
RIPv2, Response, length: 504, routes: 25 or less
Simple Text Authentication data: pLaInTeXtpAsSwD.
AFI IPv4, 44.151.62.1/32, tag 0x0004, metric: 1,
next-hop: 88.161.142.195
AFI IPv4, 44.151.67.67/32, tag 0x0004, metric: 1,
next-hop: 78.226.112.146
AFI IPv4, 44.151.67.100/32, tag 0x0004, metric: 1,
next-hop: 77.202.52.153
AFI IPv4, 44.151.67.101/32, tag 0x0004, metric: 1,
next-hop: 82.231.84.133
AFI IPv4, 44.151.69.52/32, tag 0x0004, metric: 1,
next-hop: 78.193.255.113
AFI IPv4, 44.151.74.102/32, tag 0x0004, metric: 1,
next-hop: 151.80.196.50
AFI IPv4, 44.151.75.15/32, tag 0x0004, metric: 1,
next-hop: 82.251.146.223
AFI IPv4, 44.151.77.1/32, tag 0x0004, metric: 1,
next-hop: 89.92.44.3
AFI IPv4, 44.151.91.7/32, tag 0x0004, metric: 1,
next-hop: 90.63.239.151
AFI IPv4, 44.151.91.12/32, tag 0x0004, metric: 1,
next-hop: 90.63.239.151
AFI IPv4, 44.151.91.13/32, tag 0x0004, metric: 1,
next-hop: 90.63.239.151
AFI IPv4, 44.151.91.45/32, tag 0x0004, metric: 1,
next-hop: 91.160.176.199
AFI IPv4, 44.151.92.10/32, tag 0x0004, metric: 1,
next-hop: 78.123.177.245
AFI IPv4, 44.151.92.21/32, tag 0x0004, metric: 1,
next-hop: 213.41.152.199
AFI IPv4, 44.151.95.10/32, tag 0x0004, metric: 1,
next-hop: 78.225.88.39
AFI IPv4, 44.151.127.1/32, tag 0x0004, metric: 1,
next-hop: 217.182.129.131
AFI IPv4, 44.151.240.66/32, tag 0x0004, metric: 1,
next-hop: 91.176.67.16
AFI IPv4, 44.153.0.0/23, tag 0x0004, metric: 1,
next-hop: 186.124.165.82
AFI IPv4, 44.153.32.97/32, tag 0x0004, metric: 1,
next-hop: 190.105.83.232
AFI IPv4, 44.153.35.0/24, tag 0x0004, metric: 1,
next-hop: 190.105.83.232
AFI IPv4, 44.153.52.6/32, tag 0x0004, metric: 1,
next-hop: 209.13.176.78
AFI IPv4, 44.153.54.0/28, tag 0x0004, metric: 1,
next-hop: 190.97.49.15
AFI IPv4, 44.153.54.16/30, tag 0x0004, metric: 1,
next-hop: 190.97.49.15
AFI IPv4, 44.153.54.20/32, tag 0x0004, metric: 1,
next-hop: 190.1.38.237
0x0000: 0202 0000 ffff 0002 704c 6149 6e54 6558
0x0010: 7470 4173 5377 4400 0002 0004 2c97 3e01
0x0020: ffff ffff 58a1 8ec3 0000 0001 0002 0004
0x0030: 2c97 4343 ffff ffff 4ee2 7092 0000 0001
0x0040: 0002 0004 2c97 4364 ffff ffff 4dca 3499
0x0050: 0000 0001 0002 0004 2c97 4365 ffff ffff
0x0060: 52e7 5485 0000 0001 0002 0004 2c97 4534
0x0070: ffff ffff 4ec1 ff71 0000 0001 0002 0004
0x0080: 2c97 4a66 ffff ffff 9750 c432 0000 0001
0x0090: 0002 0004 2c97 4b0f ffff ffff 52fb 92df
0x00a0: 0000 0001 0002 0004 2c97 4d01 ffff ffff
0x00b0: 595c 2c03 0000 0001 0002 0004 2c97 5b07
0x00c0: ffff ffff 5a3f ef97 0000 0001 0002 0004
0x00d0: 2c97 5b0c ffff ffff 5a3f ef97 0000 0001
0x00e0: 0002 0004 2c97 5b0d ffff ffff 5a3f ef97
0x00f0: 0000 0001 0002 0004 2c97 5b2d ffff ffff
> I have sendmail's 'greetdelay' function enabled, which delays sending
> the initial greeting herald by 5 seconds after the connection opens,
> and flushes any mail where commands arrive before that time has elapsed.
> This pre-greeting-flush catches one or two senders a day, presumably
> spammers because they don't come back.
That isn't much... but maybe a lot of those clients have implemented a workaround
for that sendmail trick, because it has been around for a while and is part of the
default config on some systems. So this particular check might not be effective anymore.
However, I did other things in my mailserver:
- sending intermediate replies (a minus sign immediately after the 3-digit code)
and checking for a few seconds if that makes them send the next command (it shouldn't)
- doing the delaying not only on the greeting but also on other commands
- perform rigid syntax checking (e.g.: there should NOT be a space after the colon
in the "mail from:<address>" and "rcpt to:<address>" commands, according to the RFC,
but a popular free smtp client that is often used by spammers puts it there)
The outcome of those tests only added to the spamscore so faulty mail clients were
not completely blocked.
Rob
> The problem is that the large email purveyors like AOL, Yahoo, Microsoft, etc,
> use large server farms that balance the load between multiple hosts, so
> when the mail retries it comes from different IP addresses on every retry.
> Microsoft, for example, lists thousands of IP addresses as part of their
> email service.
> Greylisting by IP address hasn't got a chance of working in that
> environment.
When I ran my own mailserver I had greylisting that only worked by sender mail address.
Additionally, it did the usual SPF checking etc.
This did not cause the abovementioned problem, but I'm not sure it added much spam prevention.
I had other methods to detect trojaned PCs with bad SMTP senders (e.g. doing PIPELINING without
having negotiated it) and that was much more effective.
Rob
Hi Ronen,
Yes I can make my ntp server available to non amprnet host just let me know the ips its comming from.. I can expect to receive from. host name: kc3ipf-01.ampr.org.
Philip KC3IPF
>What about the kc3ipf server ? is it available also to non amprnet hosts ?
>
>
>Ronen - 4Z4ZQ
