Just a heads up to the 44 Group who run 44 addressed mail servers.
Over the last few days I've had someone trying to break into my mail server.
After installing more detection software, I came up with IP Address
178.33.151.117.
Just a heads up he's probably scanning the network looking for others, so
heads up everyone.
Bill / KG6BAJ
==========================================
AUTOMATED NOTIFICATION !
The IP 178.33.151.117 has just been banned after several attempts against
dovecot.
Here are more information about 178.33.151.117:
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '178.33.151.112 - 178.33.151.127'
% Abuse contact for '178.33.151.112 - 178.33.151.127' is 'abuse(a)ovh.net'
inetnum: 178.33.151.112 - 178.33.151.127
netname: DVC-ITA
descr: DoveConviene.it Italian Network
country: IT
org: ORG-OS43-RIPE
admin-c: OTC5-RIPE
tech-c: OTC5-RIPE
status: ASSIGNED PA
mnt-by: OVH-MNT
source: RIPE # Filtered
organisation: ORG-OS43-RIPE
org-name: OVH Srl
org-type: OTHER
address: Via trieste 25
address: 20097 San Donato Milanese
address: Italia
abuse-mailbox: abuse(a)ovh.net
mnt-ref: OVH-MNT
mnt-by: OVH-MNT
source: RIPE # Filtered
role: OVH IT Technical Contact
address: OVH Srl
address: Via trieste 25
address: 20097 San Donato Milanese
address: Italia
admin-c: OK217-RIPE
tech-c: GM84-RIPE
nic-hdl: OTC5-RIPE
abuse-mailbox: abuse(a)ovh.net
mnt-by: OVH-MNT
source: RIPE # Filtered
% Information related to '178.32.0.0/15AS16276'
route: 178.32.0.0/15
descr: OVH ISP
descr: Paris, France
origin: AS16276
mnt-by: OVH-MNT
source: RIPE # Filtered
% This query was served by the RIPE Database Query Service version 1.71
(WHOIS1)
Lines containing IP:178.33.151.117 in /var/log/mail.log
Feb 5 04:15:37 linux1 dovecot: pop3-login: Disconnected (auth failed, 1
attempts): user=<test(a)ampr.org>, method=PLAIN, rip=178.33.151.117,
lip=44.2.14.2
Feb 5 04:17:23 linux1 dovecot: pop3-login: Disconnected (auth failed, 1
attempts): user=<test(a)ampr.org>, method=PLAIN, rip=178.33.151.117,
lip=44.2.14.2
Feb 5 04:17:41 linux1 dovecot: pop3-login: Disconnected (auth failed, 1
attempts): user=<test(a)ampr.org>, method=PLAIN, rip=178.33.151.117,
lip=44.2.14.2
...... <snip>
I suspect. I noted he was smart enough to trace the 44.2.14.1 to
"gvcity.ampr.org" and then try to access with ".....(a)ampr.org"
At 10:11 AM 2/5/2014, you wrote:
>(Please trim inclusions from previous messages)
>_______________________________________________
>looks like someones box has been hacked it is a shopping site in Italy.
>
>Lin
>
>
> Although I have finally pulled some strings for commercial tower space
> come spring.
Good work!
> Without one end up high (above the average 100 foot
> trees),
No. If you have 100 foot trees, you can't run long distance outdoor 802.11
> you need amplifiers to go anywhere, or a MESH node every
> couple miles?
>
No, and no.
So far I have not done anything with Mesh, and it sort of makes sense
> for the distance/propagation delima.. Till I think, wait a second,
> 802.11 is still half duplex, so when you make a (metric) hop using a
> mesh topology, aren't you effectively cutting your bandwidth in half?
>
And in half again, and again with each new node.
So there is more to this than throw a bunch of nodes out there.
> (bandwidth and hidden transmitter stuff), there is just no easy way
> around a decently designed network.. backbones! Then there is the oh,
> well we want to expand the network this way (something not in the
> original plan), and how to make the subnet and routes all work, short
> of re-addressing everything.
>
You got it in one! Please someone please package this text inside
something nice and solid, like a baseball bat, so we can whack the next
person with who has this idea.
> I watched the HamWAN DCC video.. and I have often thought about 5 GHz
> Mikrotik Groove as they way I'd go if I were to invest in equipment
> again.
No, stick with multi-chain polling stuff, like the MIMO AirMAX, and get
200mbit plus symbol rates, and solid 90mbit ACTUAL throughput.
> More so, if bouncing off say a water tower actually is doable.
>
No, stick with nice clear line-of-sight paths for infrastructure.
By all means, play with things as an experiment, but puhleeeaze don't hide
such a catastrophe inside a seemingly functional network, or you will bring
the rest of the network to its' knees.
> Whoever has IP 44.12.3.97, please stop sending UDP 5678 to 255.255.255.255.
> I'm getting this every single minute.
>
Hehe, a single UDP every minute.. If that was over the old 1200 digipeated
network it'd DDOS the entire network! lol
>
For those who use Mikrotik routers, please be aware that there is a possible
bug with route marks in the latest firmware (6.9).
So stay put on 6.7 until this is clarified/solved.
73 de Marius, YO2LOJ
>
> Yes. Amateur RF is synonymous with low bandwidth. We have unique
> capabilities but it's with low bandwidth like 1200 baud, 9600 baud,
> 100K ID1's and hopefully soon UDRX at 56K+.
>
> BBHN (Broadband hamnet, was HSMM) is generally more interested with
> connectivity than performance. Unfortunately too many experimenters
> there are new and not familiar with the lessons of 145.01 or 144.39...
> Even implemented with good RF design the MESH ad-hoc based system has
> compromises. I tried streaming the next episode of Torchwood from
> Amazon a couple nights ago and my NW-MESH (based on HSMM-MESH) home
> system wouldn't do it. I don't think that's even HD. :(
>
Precisely.
I think it is fine for radio hams to experiment with attaching some cool
new experimental toy to the backbone, for whatever they want to do with it!
Play with it and and have fun - that's what any hobby is for, and ham
radio not the least..
But people really need to remember old the days of digipeaters on a single
simplex frequency and make sure we don't return there, or at the very least
Ubiquiti M2/M3/M5 dual-chain AirMax nanobridges et al running on the ham
bands are the new jesus.
Steve
> Message: 1
> Date: Fri, 31 Jan 2014 15:33:41 -0800
> From: Bill Vodall <wa7nwp(a)gmail.com>
> To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> Subject: Re: [44net] 44Net Digest, Vol 3, Issue 19
<snip>
> BBHN (Broadband hamnet, was HSMM) is generally more interested with
> connectivity than performance. Unfortunately too many experimenters
> there are new and not familiar with the lessons of 145.01 or 144.39...
> Even implemented with good RF design the MESH ad-hoc based system has
> compromises. I tried streaming the next episode of Torchwood from
> Amazon a couple nights ago and my NW-MESH (based on HSMM-MESH) home
> system wouldn't do it. I don't think that's even HD. :(
Here in Green Bay, WI a few of us have been messing with point to
point 802.11 since 1999. Sadly there isn't enough interest (mostly
due to the average ham club members age I suspect), for it to advance
much beyond that... so far.
Although I have finally pulled some strings for commercial tower space
come spring. Without one end up high (above the average 100 foot
trees), you need amplifiers to go anywhere, or a MESH node every
couple miles?
So far I have not done anything with Mesh, and it sort of makes sense
for the distance/propagation delima.. Till I think, wait a second,
802.11 is still half duplex, so when you make a (metric) hop using a
mesh topology, aren't you effectively cutting your bandwidth in half?
So there is more to this than throw a bunch of nodes out there.
(bandwidth and hidden transmitter stuff), there is just no easy way
around a decently designed network.. backbones! Then there is the oh,
well we want to expand the network this way (something not in the
original plan), and how to make the subnet and routes all work, short
of re-addressing everything.
I watched the HamWAN DCC video.. and I have often thought about 5 GHz
Mikrotik Groove as they way I'd go if I were to invest in equipment
again. More so, if bouncing off say a water tower actually is doable.
Steve, KB9MWR
On 1/29/14 2:05 PM, Steve Wright wrote:
> This mesh crap really needs to be binned, or at the very least not try and
> do anything important over it, such as route an entire /16. If you want to
> connect a /24 with it to make a neat local play toy then go for it, but
> using it as an enterprise routing tool is absurd at the very least, and at
> it's WORST, it's very likely to just completely stop anyone from trying to
> build anything new over it because it's connectivity and throughput sucks.
This.
So this is how I'd see it work, I need to write up a proposal for it.
You have regional BGP routers that route subnets to the internet. These could
then tunnel the subnets to end users via GRE. End users could route via an
IGP over this tunnel to the regional speaker(s). Multiple tunnels would give
redundancy.
The regional speakers would have a tunnel between them.
In the event of an outage the other BGP speakers would route subnets.
Multiple links from end users to other BGP speakers (or non-speakers that are
aggravation routers) would provide redundancy to the end users.
Of course nothing prevents having a direct BGP speaker with an RF link to end
users, most data centers will not have roof rights however.
We could setup redistribution that would pull announcements from BGP if end
nodes went down.
Each BGP speaker could announce the subnets it knows about and a /8 providing
we have a mesh of the backbone bgp speakers.
Thoughts?
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
We've had a year of people putting things in, only to be told it isn't live yet. Damped annoying. If the thing is not live and if any entries made now will not be put in, then please, please take the darn link off the website until it IS ready.
Michael
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: Chris <chris(a)g1fef.co.uk>
Date:01/20/2014 12:49 PM (GMT-08:00)
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] DNS records 44.131.56.0/24
(Please trim inclusions from previous messages)
_______________________________________________
Basically, the DNS portion of the portal is ready and awaiting deployment, we are implementing an email robot to run alongside, much the same as we did for the gateway robot, once it is completed and tested the whole thing can be deployed. The email robot should be ready in about a week.
When it is deployed we will announce the fact on this list at which point any new requests will be processed, any requests sent in prior to the deployment will not be processed.
Regards,
Chris
> On 20 Jan 2014, at 20:34, Nick G4IRX <g4irx.44net(a)nowindows.net> wrote:
>
> (Please trim inclusions from previous messages)
> _______________________________________________
> Thanks for clarifying Chris. Presumably my requests will sit there until it becomes active?
>
> Nick.
>
>> On 20/01/2014 20:20, Chris wrote:
>> (Please trim inclusions from previous messages)
>> _______________________________________________
>> The DNS section of the portal is not active yet
>
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
First, apologies for this email not being a valid reply. Finally got around
to getting on the mailing list, so I haven't gotten the previous thread to
reply to.
I've adjusted our scripting that generates our AMPR tunnels on the HamWAN
edge routers to disable neighbor discovery for those interfaces, and the
change should now be in effect.
Thanks,
Nigel
K7NVH
