Hi all,
Just to inform all of you about the special visit
at i0ojj.ampr.org/ir0rm-7.ampr.org by using the
following references:
fbi.gov. 0 IN TXT
Dgoogle-site-verification=L8cauHJF4MANoTCkMbrLkAVfHBta28ctva9n1IDekToQ
fbi.gov. 0 IN TXT
Dgoogle-site-verification=6UEk-jfg1xPNjz_rQGcRFJOBGxMy1aARDZUTXgSNAqw
fbi.gov. 0 IN TXT
XublrZj1CzpSEiwtiRFKDAyiek8hRqkqaTTApxvhwai14i8JqVBOauW4cA06i39H5Lhl3HnALCM/xfTxIPEXEpA==
fbi.gov. 0 IN TXT 625558384-8740534
--
73 and ciao, gus i0ojj
A proud member of linux team
Non multa, sed multum
All,
I did an upgrade of my OpenWRT device to LEDE 17.01.0. At this time,
everything is operation as before; except that I cannot execute the
ampr-ripd from the CLI or the scripts that worked in the previous versions.
I'm suspecting it may be missing dependencies; but while I troubleshoot,
I am only accessible from the Global Internet.
If anyone else is interested in upgrading and troubleshooting, I would
ask that you make a copy of a list of all your installed packages prior
to upgrading. In addition, please make an archive of your config before
and after your upgrade.
73 and good weekend,
- Lynwood
KB3VWG
> Just to keep everyone in the loop: there have been four DDOS attacks on the portal recently, two against just port 443 and late last night (UK time) two simultaneous attacks against 443 and 25.
> I have no idea why anyone is targeting the portal, nor who is behind it - as per your standard DDOS the attacks they mainly came from compromised PCs on the end of home DSL lines.
We had a DDoS attack that affected our gateway, but it targeted the "Brandmeister" servers for interlinking digital voice repeaters, that were hosted on our network.
(some on the same ESXi server as the gateway and some on another location linked by a radio link)
This took down our connectivity as we got >200 Gbit/s of traffic and the gateway only as a 1 Gbit/s connection.
The traffic in this case was "DNS reflection", i.e. DNS requests were sent by compromised PCs using a spoofed source address on AMPRnet,
and the DNS servers were sending their replies to our gateway. Due to the high packet loss and the large replies these were mainly
UDP fragments that would not re-assemble to complete datagrams.
Of course it is bad that there still are so many ISPs that do not implement BCP38. But what can we do?
However, more interesting is the cause of this attack: the maintainers of the Brandmeister system have a disagreement with the operators
of the French gateway in that system and decided to disconnect it. The DDoS was done as a retaliation against that, probably
by one or more French amateurs, not necessarily the gateway operators.
(the disconnection of that gateway of course affected the repeater users in France, not only the operators)
Like in your case, there were several waves of attacks. In the end, the affected addresses were nullrouted and the servers moved elsewhere.
It might be that these same people are still looking for things to attack, and maybe they researched a bit how .ampr.org works and decided
to attack the portal?
(not effective against Brandmeister as our network is BGP routed)
It is sad that people act this way, and the network operators do so little to prevent it.
Rob
> Instead of this debate -- why not spec what the software does and start an
> open source project to replicate its functionality.
Because this is a one-instance project. It does not bring much to opensource it and
have 5 different people working on it in 5 directions, because ultimately we need
one instance that governs the AMPRnet. Even when we want to replicate it for redundancy,
those copies need to run the same code or at least would have to have exactly the same
functionality.
Having said that, it appears to be a pretty mundane LAMP project and it has taken way more
time to discuss about the developments it needs than it would have taken to actually do
those developments. Maybe writing the specs and starting from scratch is not such a bad
idea, especially when done by someone who can actually spend some time on it.
I would have favoured integrating it with another AMPRnet application, HamnetDB, but
unfortunately it appears its developer has just as little spare time, so that probably
would be a tough project as well.
Rob
Hello,
I made some updates to the MT ROS script:
- The script now maintains an interface list named 'ampr-interfaces'
with all ampr tunnel interfaces. The list is persistent, and will be
created on first script run. Afterwards it will be maintained by each
interface add or remove. Useful for firewall rules.
- Corrected an error when tunnel endpoint host routes where not deleted
on interface removal.
- Added step by step instructions using winbox GUI (inside the zip file).
http://www.yo2loj.ro/hamprojects/ampr-gw-3.1.rschttp://www.yo2loj.ro/hamprojects/ampr-gw-3.1.zip
73s de Marius, YO2LOJ
During the night, amprgw fetched a copy of the encap file from the portal
which was truncated (it had 259 entries instead of over 600) and one of
the entries that was in the copy fetched had no gateway address. Viz:
route addprivate 44.131.168.128/29 encap
This caused the ipip daemon to segfault and so there was no routing
between Internet and tunnel subnets for an hour. The rip sender
was similarly affected.
Later fetches of the encap file obtained ones that appear to be intact
and all routing is again operational.
I've modified the code in the daemons to be more robust in the face
of a bad encap fetch, and taken steps to ensure that future fetches
are checked better.
- Brian
The Register reports a Linux/Android kernel flaw that could
expose you to remote privileged execution of arbitrary code:
http://www.theregister.co.uk/2017/04/14/new_critical_linux_kernel_flaw/
As a lot of the machines and routers on the Amprnet are based on
Linux, this may be incentive for you to update to the latest kernel.
- Brian
> During the night, amprgw fetched a copy of the encap file from the portal
> which was truncated (it had 259 entries instead of over 600) and one of
> the entries that was in the copy fetched had no gateway address. Viz:
> route addprivate 44.131.168.128/29 encap
> This caused the ipip daemon to segfault and so there was no routing
> between Internet and tunnel subnets for an hour.
For this particular issue it would help when the encap file had a trailer that
the script that fetches it could check for before loading it. Something like:
# EOF
Rob
So that time has come to get some DNS entries added.G1FEF seems to be my coordinator. Should I approach him about entries I cannot spot a contact address anywhere.
Regards Marc (2W0PNT)
