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