Hello,
The error in question is simply because some program other than one
furnished by Bacula or using the Bacula protocol has tried to connect to
Bacula. Bacula reports that and in my view what is reports is very
clear (at least for a technical person).
To alleviate your concerns, I cannot imagine that such probes other than
producing an error message (good practice) could in any way cause
another Job to fail. Each job is totally separate, and just because
there is an invalid probe will not affect the jobs that connect correctly.
Best regards,
Kern
On 03/05/2018 10:23 PM, Josip Deanovic wrote:
On Monday 2018-03-05 14:38:07 Dimitri Maziuk wrote:
On 03/05/2018 02:27 PM, Josip Deanovic wrote:
On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
That's not an error if a security op's workstation is also a backup
client.
Yes, and I would like to know if that was the case.
I tend to have a blanket iptables rule allowing local subnet traffic.
Our security nazis live in a separate subnet so their scans get blocked
by that. If I were running portscans from inside my netblock I expect
I'd get the same log entries. That's anther other option for it being
legit.
I have additional backup interfaces and completely separated backup
network where no other two backup clients can see or reach each other.
Where there is no additional network card available there is a VLAN.
But all of that is not important here.
What is important is the case where if you can reach bacula services
you could potentially break backup jobs and thus effectively produce
a bacula denial of service.
If I understood correctly that's what happened to Shawn.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
