Brian. Can u tell me how. Been having some kind of issues here. Also think my router it sick. Have a new one on way. Buffalo wzr-600dhp running dd-wrt latest .. Non beta..
73 jerry
On Apr 29, 2014 1:34 PM, Brian Kantor <Brian(a)UCSD.Edu> wrote:
>
> (Please trim inclusions from previous messages)
> _______________________________________________
> You should check to make sure that you have the 'chargen' service
> disabled on your hosts, and block it in your routers if you can.
>
> I've already contacted the people whose system was involved in this attack.
> - Brian
>
>
> ----- Forwarded message -----
>
> Subject: Exploitable chargen service used for an attack: 44.x.x.x.
>
> It appears that a public "chargen" service on your network, running
> on IP address 44.x.x.x, participated in a large-scale attack against a
> customer of ours today, generating large UDP responses to spoofed probes
> that claimed to be from the attack target.
>
> chargen is an old testing service that generates large quantities of
> traffic with only a small request required. It is commonly enabled by
> default on old printers and other connected appliances, but it has no
> useful purpose over the open internet.
>
> Please block UDP port 19 (inbound and outbound) at your network
> edge, as this should stop these chargen attacks without blocking
> legitimate traffic. If the endpoint device that generated this traffic
> is configurable, please further investigate whether it is running a
> chargen service (and disable it, if so) -- commonly exploited devices
> include Cisco hardware that has "udp small servers" mistakenly enabled,
> old printers, old UNIX boxes with "chargen" running under inetd, and
> Windows boxes with the "Simple TCP/IP services" package installed. Also,
> it is worth checking if it is a machine that has been compromised, as
> some malware directly generates port 19 traffic, simulating chargen,
> and in this way masks its presence.
>
> If you are an ISP, please also look at your network configuration and
> make sure that you do not allow spoofed traffic (that pretends to be from
> external IP addresses) to leave the network. Hosts that allow spoofed
> traffic make possible this type of attack.
>
> ----- End forwarded message -----
>
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
>
Ok, so I am a licensed HAM, an amateur that has no formal education or job
experience regarding networking. However, I believe I have a better handle
on IT than most hams in general, present company excluded. (Anything I can
do to help)
I am assisting the Penn State Amateur Radio Club, a student organization,
to get a couple of 1Gb network backbone connections lit up. One is
dedicated to a D-star gateway (K3CR). The other location is the ham shack,
for web browsing and other future uses, such as APRS Igate, IRLP or
Asterisk.
We will have a /29 assigned by the University. The two Microtik routers we
have purchased are capable of BGP. The university will not advertise 44net,
or allow me to announce BGP. sigh.
Does anyone have any suggestions?
Another regional resource we have in the state of Pennsylvania is PennREN.
It is a partnership that built out fiber optics in a figure-eight footprint
all around the state. They can provide connectivity (I would like to get a
VPN server co-located in their facilities), but they also have dark fiber
available.
My long-term vision is to have a 501c(3) organized by hams light up a
couple of those strands to create a regional 44net. Local hams/clubs would
each have to provide their own 'last mile'
I believe there is a group in Pittsburgh already doing something similar.
I want to learn enough to understand the conversation. Thanks for the video!
Jim Alles, KB3TBX
On 4/24/14, 6:54 PM, K7VE - John wrote:
> I think the better model is BGP "nodes" which provide VPN to subnets.
> The BGP node admins would provide the VPN authentication to know what
> subnets were attaching and BGP would provide Internet connectivity
> (including subnets).
+1
I trust my VPN users and announce via BGP to the global routing table. If you
want to trust my routes cool, if not that's cool too.
I think everyone is over-thinking this. It does no good if the majority of
traffic over 44net allocations is ping and traceroute. Let shit flow and see
what happens.
IF some one starts abusing it, shut it down and fix it. It's like a repeater
when there is a jammer. Once you're aware of it, you shut it down till they
go away and you're not liable for it.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
Ridiculous. Amprgw was out for 4 plus hours some months ago. Your plan would put two such failure points between most end-points.
A comment like that could ONLY come from someone with ZERO experience running production networks. The last thing we need is a bunch of self important amateurs with little to no succesful carrier experience and zero contractual obligation for performance inserting themselves in the middle of our existing traffic.
Michael
N6MEF
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: K7VE - John <k7ve(a)k7ve.org>
Date:04/25/2014 4:01 PM (GMT-08:00)
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] What is 44net?
(Please trim inclusions from previous messages)
_______________________________________________
Most failures are localized and temporary.
------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
On Fri, Apr 25, 2014 at 3:41 PM, Michael E Fox - N6MEF <n6mef(a)mefox.org>wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
>
>
> -----Original Message-----
>
> >So how do you do it now? You use an IPIP tunnel (another type of
> >VPN), nothing changes for the end user except, his tables get much
> >smaller, she routes local 44.x.x.x traffic locally and uses an IPIP
> >tunnel to a tier or border router.
>
> So you're creating multiple new single points of failure. With your plan,
> I
> can get to a few other local gateways. Anything else has to go through
> this
> new single point of failure locally, plus, presumably, and another single
> point of failure near my destination. So most worldwide connectivity would
> now have to traverse two single points of failure that currently don't
> exist. This is good because ...?
>
> Michael
> N6MEF
>
>
>
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
>
dhcp-44-24-240-172.paine-s2.hamwan ADD A 44.24.240.172
dhcp-44-24-240-165.paine-s2.hamwan ADD A 44.24.240.165
dhcp-44-24-240-162.paine-s2.hamwan ADD A 44.24.240.162
dhcp-44-24-240-173.paine-s2.hamwan ADD A 44.24.240.173
dhcp-44-24-240-164.paine-s2.hamwan ADD A 44.24.240.164
dhcp-44-24-240-171.paine-s2.hamwan ADD A 44.24.240.171
dhcp-44-24-240-161.paine-s2.hamwan ADD A 44.24.240.161
dhcp-44-24-240-174.paine-s2.hamwan ADD A 44.24.240.174
dhcp-44-24-240-163.paine-s2.hamwan ADD A 44.24.240.163
dhcp-44-24-240-166.paine-s2.hamwan ADD A 44.24.240.166
dhcp-44-24-240-168.paine-s2.hamwan ADD A 44.24.240.168
dhcp-44-24-240-169.paine-s2.hamwan ADD A 44.24.240.169
dhcp-44-24-240-167.paine-s2.hamwan ADD A 44.24.240.167
dhcp-44-24-240-170.paine-s2.hamwan ADD A 44.24.240.170
On 4/25/14, 3:25 PM, lleachii(a)aol.com wrote:
> Some of those who announce their allocations now refuse to maintain tunnels for others.
I will maintain tunnels for others (excluding aol users), even have IPsec vpn
going for dial on demand hamnet goodness.
73's
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
Hello fellow radio/network geeks!
While trying as much as I can to not come off as condescending, I would
like to try and provide a little perspective so that we can hopefully clear
up some confusion and speak in mutually agreeable terms.
There seems to be many misconceptions by several people on this list who
may be seeing 44net as a single service or network where everyone needs to
be able to speak to each other and where all traffic sourced from it can be
trusted. Oh, and RADIO :)
The global internet isn't even one large network in that sense. It's
actually just a concept that allows many different individual autonomous
networks to coordinate and cooperate with each other while allowing them to
share traffic among their users. Those in control of things like
allocating IP space and DNS are only in that position because the majority
of networks recognize their authority.
Just like similar authorities on the internet, ARDC is just a registry that
provides chunks of the globally unique IP space to individual networks
which allows them to interoperate with each other or any other global
network without conflict (but does not mean that they *must* work with
other networks). In this case, they only agree to provide these services
to networks that support amateur radio in one form or another. It just so
happens that they also provide a service that coordinates IPIP tunnels so
these networks can send encapsulated traffic to each other without needing
to make their own peering arrangements with other networks on the internet
at large. Since most people are only used to the idea of the internet
being a "service" provided to them, it's easy to see why this can be
confused.
Those familiar with the HSMM projects may have noticed that they chose to
operate in the non-unique 10/8 space in order to support autoconfiguration.
However, once their project grew beyond those specific linksys models,
they started having conflicts. Even now, those HSMM networks that are up
and running can't communicate with users on other networks without
complicated NAT tables. It would be much better to take advantage of our
44/8 resources for those projects by assigning blocks to each mesh island.
That way they can start peering with other networks or other mesh islands
directly. When asked why having 44/8 is important, this is a perfect
example and there are many others.
When talking about technical solutions to problems we come across, it's
also important to consider that as hams, it's likely that our networks are
experimental and will therefore have a wide range of configurations that
could prohibit their ability to share traffic with some others. This
should absolutely be encouraged as long as what they do does not impact any
other network's ability to operate normally. Therefore, there is no
"right" or "wrong" way to configure your network as long as you get your
expected result. Just keep in mind that following best-practices is the
best way to ensure compatibility. Ideally, those who operate the registry
will shift closer to this way of thinking and start supporting more
advanced users to do non-standard things (such as DNS or PTR delegation,
for example).
We also need to be careful about the terminology we use when referring to
security, in order to avoid mistaken assumptions. Source addresses can be
used in our case to provide a convenient filter against the majority of
incoming junk internet traffic. However, this must not be confused for
"authentication" or knowing *who* is sending you the packets. Make sure
you understand the risks when opening up a service on your network. If
you're trying to filter out most undesirables, source filtering can be
okay. However, if you need to know who you are talking to, you must use
another method. Also, myself and several others on this list may be in a
good position to help if you need assistance in this area.
Best regards,
-Cory NQ1E
Your friendly neighborhood radio hacker
