This appears to be somewhat serious; it will probably require people
to reflash the firmware in some or all of their wireless devices when
fixes become available. How one reflashes IoT devices is problematic.
- Brian
From ARSTechnica:
"The proof-of-concept exploit is called KRACK, short for Key
Reinstallation Attacks. The research has been a closely guarded
secret for weeks ahead of a coordinated disclosure that's scheduled
for 8 a.m. Monday, east coast time. An advisory the US CERT recently
distributed to about 100 organizations described the research this way:
"US-CERT has become aware of several key management vulnerabilities in
the 4-way handshake of the Wi-Fi Protected Access II (WPA2) security
protocol. The impact of exploiting these vulnerabilities includes
decryption, packet replay, TCP connection hijacking, HTTP content
injection, and others. Note that as protocol-level issues, most or all
correct implementations of the standard will be affected. The CERT/CC
and the reporting researcher KU Leuven, will be publicly disclosing
these vulnerabilities on 16 October 2017."
https://arstechnica.com/information-technology/2017/10/severe-flaw-in-wpa2-…
> I get a screen ful of garbadge because most of it are fail login attempt and then i can not see any usefull info because the garbadge is so big it cover the few line of real info i want to see
It is not a good idea to have the admin interface of your router open to the entire internet.
Fix that using the input chain of the firewall, and the messages will be far fewer.
Of course you may also want to limit what the router forwards to systems behind it, depending on your network config.
Rob
Hi there
I have a Mikrotik for the 44 net
It have a firewall and currently it logs to the screen and the ram (not to the disk) any fail login ... and some rules (not too much as i want open network)
such as SIP signals that are many and some other big intruders protocols
Now i have some deliberation (i hope it is the right word i used google translate) how to configure the logs ?
I get a screen ful of garbadge because most of it are fail login attempt and then i can not see any usefull info because the garbadge is so big it cover the few line of real info i want to see
I wanted to change the log rules that only successful login will be logged so i will not see so much traffic .. but then i will not see the break in attempt and might loose real break in
currently i check the fail login and im more aware so if i see a raise in login failures i check the reason and even make rule to block the IP
im afraid when i will rely only on logging the successful logins it might be too late when i will discover that someone have already logged in to the system
Indeed ist not a top secret router and network behind it its only ham radio // but still ...
Is there are experts here that might tell me what is the best way to do ?
when i was long ago sys admin i followed a rule that said what you dont look at you dont know what is going on behind but the garbage info today is so big that it require hours to real look at it
Regards
Ronen - 4Z4ZQ
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.
**************************************************
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
