44net October 2017

44net@mailman.ampr.org

47 participants
42 discussions

Allocation change
by Mike Vespoli 17 Oct '17

17 Oct '17

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

3 2

Re: [44net] Getting Started Requesting ips
by Charles 17 Oct '17

17 Oct '17

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

1 0

RFC2468 - Remembering Oct 16, 1998
by Brian Kantor 15 Oct '17

15 Oct '17

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]

1 0

Re: [44net] DDoS via net44
by Rob Janssen 13 Oct '17

13 Oct '17

> 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

2 1

DDoS via net44
by Pedro Ribeiro 13 Oct '17

13 Oct '17

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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

5 4

greylisting on mailman (this list)
by Brian Kantor 11 Oct '17

11 Oct '17

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

2 3

behind nat
by Steve L 11 Oct '17

11 Oct '17

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

1 1

Re: [44net] greylisting on mailman (this list)
by Rob Janssen 11 Oct '17

11 Oct '17

> 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

1 0

Re: [44net] greylisting on mailman (this list)
by Rob Janssen 11 Oct '17

11 Oct '17

> 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

2 1

Re: [44net] new ntp server for amprnet
by Martinez, Philip 11 Oct '17

11 Oct '17

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

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net October 2017