Thanks Brian, I was already filtering that port for traffic outside AMPRnet.
It would not have affected us much because we forward new incoming traffic from internet
only to users who have explicitly requested this. This list now includes 10 /28 subnets
and 29 individual hosts. (189 addresses out of the 65536 address network)
All other users receive new traffic only from 44.0.0.0/8, and replies to their own outgoing traffic.
I added this after the SNMP DDOS incident.... in case there are other problems like this.
Ports filtered here on input from internet are:
135:139,445,1025:1028 TCP and UDP (SMB)
53 TCP and UDP (DNS)
111 UDP (portmap)
161 UDP (SNMP)
1900 (SSDP)
Rob
Can someone please direct me to the right place where I can purchase a
complete kit so that I can setup an IP Ham network system. I would like to
experiment with using using the 44Net as a fall back network in times of
disaster.
Any assistance / direction will be very appreciated as I am new at this.
Thanks
Arnold Villeneuve
www.networkologist.com <http://www.networkologist.com>
Change is the end result of all true learning.- Leo Buscaglia
Thanks Marius. It looks like the instruction are jumbled up a bit to me,
and don't include the creation syntax for the tunnel interface, on the
Wiki. Maybe someone could make an edit to that??
I will try this when I get home later, and see if I can get it to play!!
More to come after that!
--
Rod Ekholm
kc7aad(a)gmail.com
Folks, I have begun blocking the portmapper port (UDP 111) at the UCSD
amprgw gateway. This is to mitigate a new DDOS exploit that is taking
place on the Internet.
This would prevent the use of various RPC services across the
amprgw gateway, but I don't think anyone is currently using NFS,
NIS, or the like in that context. The performance would be very
poor in any case.
You might consider blocking this port in your firewalls.
I recommend that everyone running their own BGP'd subnet insert a
blocking filter rule for this port as well.
More information:
http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-…
Thanks.
- Brian
Where are you located? Most important (unless you want to build a set of portable nodes that you
can all deploy yourself during an emergency) is to have others to link to. So you need to check what
others are doing in your area, to be compatible with the systems they use.
In the old days, everyone built their own modems and sometimes even radios, and connected them
to general purpose computers running special software.
However, today you can buy ready wireless link and routing equipment from manufacturers like
MikroTik and Ubiquiti for prices much below what we spent on homebrew equipment, and if you wish
you can build an IP network by just plugging those together and do basic routing and linking configuration.
Others have taken existing hardware from Linksys and those same two and replaced the firmware
with own developments that e.g. go beyond the point-to-point linking by offering automatic routing
in a mesh configuration. This may be more convenient in a temporary deployment during an emergency,
but the point-to-point range of such a system is less than with directed links using dish antennas.
Rob
I get all the way to the section where it says I need to run 'sudo
./findpass.sh', and it gives me output of 'Tunnel Socket: Setting
SO_BINDTODEVICE: No suck device'.
The instructions I am following are at:
http://wiki.ampr.org/wiki/Ubuntu_Linux_Gateway_Example#Setting_up_the_Tunne…
And I am to the section of ' Finding the password for AMPR-RIPD"
The only section that had an issue during this process is the
isc-dhcp-server will not start. I don't believe this should make any
difference, other than if I have a client on my Ham Network that needs
DHCP, but I plan to statically assign those devices.. so I believe that
point should be moot.
My installation is Ubuntu 14.04.4 LTS
I only have 2 interface.. eth0 (outside WAN address from ISP. One of my /29
allocations) and eth1 (inside 192.168.44.0/24)
I know enough to make my way around, but am not normally a linux guy!! Let
me know what other info would be helpful to share out, so we can get this
one going.
Thanks guys!!
--
Rod Ekholm
kc7aad(a)gmail.com
Thanks for the reply's guys. Lynnwood.. I have Ubuntu installed and working
on my network (outside address as to not have anything blocking right
now!!), but when it came time for the box to listen to the AMPR RIP
broadcasts, I never did see anything. The notes say to let it sit for a
little bit.. I let it sit for two days before I got back to it! :)
So.. I haven't been diligently working on it, that's on me. But something
seemed to go awry. Dangit. That's on me toooooo!! :(
I'll try and get back to it over the next few days, and report back again.
But if there are any ideas off the tops of ones heads.. Hit me with your
best shot.. Fire Away!!
Thanks.
--
Rod Ekholm
kc7aad(a)gmail.com
Yes, but since the machine is a standard Ubuntu Linux Server machine,
I'm not sure how an OVA will help you. You still have to assign your IP
addresses, turn on routing, etc. per the instructions in the Wiki.
In the time it would take you to transfer it the file, you could simply
have the same thing by running the ISO on a fresh VM.
Are you having issues with setup?
73,
Lynwood
KB3VWG
Has anyone built an OVA of a VM used for an AMPR Gateway yet? Or has anyone
Exported their local VM that they would be willing to share?
*Disclaimer:* Yes.. I realize it is easy to build a host(though my attempt
so far has failed). But If someone has already put in the work to build a
VM, I'm willing to piggyback in their expertise in what they've built.
Thank you!!
--
Rod Ekholm
kc7aad(a)gmail.com
> two ways to solve this as well.
> 1. NAT the 44. address out the public internet. That is what I am doing
> here.
That only works when you have made special arrangements (policy routing)
to make sure the Echolink traffic is ALWAYS sent to the NAT device and never
routed directly. See what I explained to Gustavo.
> 2. have the server have two NIC cards. One with a 44 address and the
> other a local non-routable which is then NATed ouot your public internet IP.
That does not require 2 cards (you can put 2 addresses on 1 card), and it is
basically the same as the policy routing method, in this case using the IP
address as the base for the policy routing.
In practice it can be more difficult to implement because you need to force
the Echolink application to bind to the correct card address. Fortunately
Svxlink can do that, but many other programs cannot.
Rob
