Re: [Bacula-users] Packet size too big errors

[Kern Sibbald]

Hmm.  The fact that the error message is reported with JobId 113 is 
actually a bug in new code that I implemented in version 9.0.x.  I 
didn't notice it in my first response, so must admit that yes it is 
confusing.  The reason for this problem is that error messages are 
reported by any currently running job because a communications illegal 
probe as you experienced has no job associated with it and thus has no 
connection from the daemon to a running job that can log error 
messages.  This was an attempt to fix the problem of the message being 
discarded but in fact it lead to a misleading error message.


The fix to the problem is a bit invasive and much more important than I 
had originally planned so it will come in a future release, where all 
error messages will be properly reported and each daemon will have its 
own separate log so that daemon messages (those generated with no 
running job such as connections) can be logged in the appropriate daemon 
log (a new concept to Bacula).


Actually, I would appreciate it if you would submit a but report on this 
indicating that a network connection failure is reported under an 
incorrect jobid.  This will ensure that the problem really is corrected 
and then properly reported.


Best regards,

Kern


On 03/05/2018 11:19 PM, Shawn Rappaport wrote:

On 3/5/18, 2:37 PM, "Josip Deanovic"  wrote:

 Josip DeanovicOn Monday 2018-03-05 22:23:08  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.
>
> Actually Shawn didn't say that the backup failed.
> He just said that when he manually started the backup job the next day,
> it finished successfully, without errors.
>
   >  Shawn, can you confirm that both backups were successfully completed?
   >

Despite seeing those errors in the log, the catalog backup appears to have been 
successful. So, yes, both the scheduled and manual backup of my catalog 
completed successfully.  Here is what the full log looks like from March 3rd:

xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: shell command: run BeforeJob 
"/etc/bacula/make_catalog_backup.pl MyCatalog"
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Start Backup JobId 
113, Job=BackupCatalog.2018-03-03_23.10.00_10
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=50331667 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Using Device 
"FileChgr1-Dev2" to write.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 Malformed 
message: bsock.c:819 Packet size=50331667 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Volume 

Re: [Bacula-users] Packet size too big errors

[Kern Sibbald]

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

Re: [Bacula-users] Packet size too big errors

[Martin Simmons]

> On Mon, 5 Mar 2018 22:19:14 +, Shawn Rappaport said:
> Content-ID: 
> 
> On 3/5/18, 2:37 PM, "Josip Deanovic"  wrote:
> 
> Josip DeanovicOn Monday 2018-03-05 22:23:08  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.
>> 
>> Actually Shawn didn't say that the backup failed.
>> He just said that when he manually started the backup job the next day,
>> it finished successfully, without errors.
>> 
>   >  Shawn, can you confirm that both backups were successfully completed?
>   >  
> 
> Despite seeing those errors in the log, the catalog backup appears to have 
> been successful. So, yes, both the scheduled and manual backup of my catalog 
> completed successfully.  Here is what the full log looks like from March 3rd:
> 
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: shell command: run 
> BeforeJob "/etc/bacula/make_catalog_backup.pl MyCatalog"
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Start Backup JobId 
> 113, Job=BackupCatalog.2018-03-03_23.10.00_10
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=121984032 too big from 
> "client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=138759248 too big from 
> "client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=50331667 too big from 
> "client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Using Device 
> "FileChgr1-Dev2" to write.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=121984032 too big from 
> "client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=138759248 too big from 
> "client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
> Malformed message: bsock.c:819 Packet size=50331667 too big from 
> "client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
> xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Volume "daily-0" 
> previously written, moving to end of data.
> xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Elapsed 
> time=00:00:02, Transfer rate=11.07 M Bytes/second
> xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Sending spooled attrs 
> to the Director. Despooling 225 bytes ...
> xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Bacula 
> xbacdirector01-lv.internal.shutterfly.com-dir 9.0.6 (20Nov17):
>   Build OS:   x86_64-pc-linux-gnu redhat (Core)
>   JobId:  113
>   Job:BackupCatalog.2018-03-03_23.10.00_10
>   Backup Level:   Full
>   Client: "xbacdirector01-lv.internal.shutterfly.com-fd" 
> 9.0.6 (20Nov17) x86_64-pc-linux-gnu,redhat,(Core)
>   FileSet:"Catalog" 2018-02-08 23:10:00
>   Pool:   "Daily" (From Job resource)
>   Catalog:"MyCatalog" (From Client resource)
>   Storage:"File1" (From Pool resource)
>   Scheduled time: 03-Mar-2018 23:10:00
>   Start time: 03-Mar-2018 

Re: [Bacula-users] Packet size too big errors

[Josip Deanovic]

On Monday 2018-03-05 22:19:14 Shawn Rappaport wrote:
> On 3/5/18, 2:37 PM, "Josip Deanovic"  wrote:
> > Actually Shawn didn't say that the backup failed.
> > He just said that when he manually started the backup job the next
> > day, it finished successfully, without errors.
> > 
> >  Shawn, can you confirm that both backups were successfully
> > completed?
> 
> Despite seeing those errors in the log, the catalog backup appears to
> have been successful. So, yes, both the scheduled and manual backup of
> my catalog completed successfully.  Here is what the full log looks
> like from March 3rd:


In that case everything is in order.

Thank you.

-- 
Josip Deanovic

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

Re: [Bacula-users] Packet size too big errors

[Shawn Rappaport]

On 3/5/18, 2:37 PM, "Josip Deanovic"  wrote:

Josip DeanovicOn Monday 2018-03-05 22:23:08  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.
   > 
   > Actually Shawn didn't say that the backup failed.
   > He just said that when he manually started the backup job the next day,
   > it finished successfully, without errors.
   > 
  >  Shawn, can you confirm that both backups were successfully completed?
  >  

Despite seeing those errors in the log, the catalog backup appears to have been 
successful. So, yes, both the scheduled and manual backup of my catalog 
completed successfully.  Here is what the full log looks like from March 3rd:

xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: shell command: run 
BeforeJob "/etc/bacula/make_catalog_backup.pl MyCatalog"
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Start Backup JobId 
113, Job=BackupCatalog.2018-03-03_23.10.00_10
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=50331667 too big from 
"client:10.32.12.18:9103". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Using Device 
"FileChgr1-Dev2" to write.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Error: getmsg.c:209 
Malformed message: bsock.c:819 Packet size=50331667 too big from 
"client:10.32.12.18:9102". Maximum permitted 100. Terminating connection.
xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Volume "daily-0" 
previously written, moving to end of data.
xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Elapsed time=00:00:02, 
Transfer rate=11.07 M Bytes/second
xbacdirector01-lv.internal.shutterfly.com-sd JobId 113: Sending spooled attrs 
to the Director. Despooling 225 bytes ...
xbacdirector01-lv.internal.shutterfly.com-dir JobId 113: Bacula 
xbacdirector01-lv.internal.shutterfly.com-dir 9.0.6 (20Nov17):
  Build OS:   x86_64-pc-linux-gnu redhat (Core)
  JobId:  113
  Job:BackupCatalog.2018-03-03_23.10.00_10
  Backup Level:   Full
  Client: "xbacdirector01-lv.internal.shutterfly.com-fd" 9.0.6 
(20Nov17) x86_64-pc-linux-gnu,redhat,(Core)
  FileSet:"Catalog" 2018-02-08 23:10:00
  Pool:   "Daily" (From Job resource)
  Catalog:"MyCatalog" (From Client resource)
  Storage:"File1" (From Pool resource)
  Scheduled time: 03-Mar-2018 23:10:00
  Start time: 03-Mar-2018 23:10:03
  End time:   03-Mar-2018 23:10:05
  Elapsed time:   2 secs
  Priority:   11
  FD Files Written:   1
  SD Files Written:   1
  FD Bytes Written:   22,147,958 (22.14 MB)
  SD Bytes Written:   22,148,071 (22.14 MB)
  Rate:   11074.0 KB/s
  

Re: [Bacula-users] Packet size too big errors

[Dimitri Maziuk]

On 03/05/2018 03:35 PM, Josip Deanovic wrote:

> Shawn, can you confirm that both backups were successfully completed?

Yes, if an unsuccessful connection attempt kills a running backup, that
would be unpleasant. The log doesn't look like it, though, it seems to
log a "jobid 0" for just the connection attempt: hopefully a misleading
message is all it is.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bacula-users] Packet size too big errors

[Josip Deanovic]

Josip DeanovicOn Monday 2018-03-05 22:23:08  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.

Actually Shawn didn't say that the backup failed.
He just said that when he manually started the backup job the next day,
it finished successfully, without errors.

Shawn, can you confirm that both backups were successfully completed?

Thank you in advance.

-- 
Josip Deanovic

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

Re: [Bacula-users] Packet size too big errors

[Josip Deanovic]

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.

-- 
Josip Deanovic

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

Re: [Bacula-users] Packet size too big errors

[Josip Deanovic]

On Monday 2018-03-05 19:41:45 Shawn Rappaport wrote:
> No, 10.32.12.18 is not the IP of the client to be backed up. I’m
> guessing that was the IP of the Nessus scanner.

In that case everything is ok except I don't understand why the
backup failed because some other server tried to open a connection
to the bacula service during the backup.

I don't think that should happen.

-- 
Josip Deanovic

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

Re: [Bacula-users] Packet size too big errors

[Dimitri Maziuk]

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.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bacula-users] Packet size too big errors

[Josip Deanovic]

On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
> On 03/05/2018 12:45 PM, Josip Deanovic wrote:
> > The question is: is the IP 10.32.12.18 the IP of the client that had
> > to be backed up?
> >
> > 
> >
> > If yes then the vulnerability scan overtook the client's IP.
> 
> 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.

-- 
Josip Deanovic

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

Re: [Bacula-users] Packet size too big errors

[Dimitri Maziuk]

On 03/05/2018 12:45 PM, Josip Deanovic wrote:

> The question is: is the IP 10.32.12.18 the IP of the client that had
> to be backed up?
> 
> If yes then the vulnerability scan overtook the client's IP.

That's not an error if a security op's workstation is also a backup client.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bacula-users] Packet size too big errors

[Shawn Rappaport]

No, 10.32.12.18 is not the IP of the client to be backed up. I’m guessing that 
was the IP of the Nessus scanner.

--Shawn

On 3/5/18, 11:48 AM, "Josip Deanovic"  wrote:

On Monday 2018-03-05 12:32:50 Dimitri Maziuk wrote:
> On 03/05/2018 12:00 PM, Josip Deanovic wrote:
> > On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
> >> Thank you, Patti! You were correct. It turns out there was a
> >> vulnerability scan run against that network at that time.
> > 
> > Did you configure your bacula to use SSL/TLS connection?
> > I wonder if that would help in your case.
> 
> I'd expect to still see "invalid HELO" logged. Firewalling the port
> would work if the scanner and bacula clients live in different subnets.

But the log says: UA Hello from client:10.32.12.18:9101
The same IP was mentioned several times in the logs Shawn provided.

The question is: is the IP 10.32.12.18 the IP of the client that had
to be backed up?

If yes then the vulnerability scan overtook the client's IP.

-- 
Josip Deanovic


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot=DwICAg=sy2pFYeXOTBQJUPqadkFIXq5lzPIgQxhI8DCCAdSjYc=N3_BTL1Tt2ryeleRqn2wc-R4w3v0TnI7dlgnwdQ7zE8=wPBX6OgHHj7MV7gxOQnY5082cQ6UQimXGy_zUId9AEk=t6x_0Qp-42lkZWidsQ1GprGuNjHMqy03eQf7EY3q4QY=
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_bacula-2Dusers=DwICAg=sy2pFYeXOTBQJUPqadkFIXq5lzPIgQxhI8DCCAdSjYc=N3_BTL1Tt2ryeleRqn2wc-R4w3v0TnI7dlgnwdQ7zE8=wPBX6OgHHj7MV7gxOQnY5082cQ6UQimXGy_zUId9AEk=KpPQj-PVt6jtDqYpxWXzkYFL5GRAB4MrFcPCHfMqdTI=


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

Re: [Bacula-users] Packet size too big errors

[Shawn Rappaport]

No, I don’t have that configured on my Bacula server.

--Shawn

On 3/5/18, 11:02 AM, "Josip Deanovic"  wrote:

On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
> Thank you, Patti! You were correct. It turns out there was a
> vulnerability scan run against that network at that time.

Did you configure your bacula to use SSL/TLS connection?
I wonder if that would help in your case.

-- 
Josip Deanovic


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot=DwICAg=sy2pFYeXOTBQJUPqadkFIXq5lzPIgQxhI8DCCAdSjYc=h5HhK7l-Sb7S5EybxFgVhTmfouIJFux6awyOLzFBk_o=OmN0FDVpocexNp-3-HbUpcHB4rVuTnZaMt9HV7yB2ws=3EkvYPiOwkJZoMKVmIYLDHszoZ5gFw_gZ3Sqx48u7iA=
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_bacula-2Dusers=DwICAg=sy2pFYeXOTBQJUPqadkFIXq5lzPIgQxhI8DCCAdSjYc=h5HhK7l-Sb7S5EybxFgVhTmfouIJFux6awyOLzFBk_o=OmN0FDVpocexNp-3-HbUpcHB4rVuTnZaMt9HV7yB2ws=l6JwFmldtJUFrLaECgIfziwSqzsRQ8LR1V6_3_REKBI=


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

Re: [Bacula-users] Packet size too big errors

[Josip Deanovic]

On Monday 2018-03-05 12:32:50 Dimitri Maziuk wrote:
> On 03/05/2018 12:00 PM, Josip Deanovic wrote:
> > On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
> >> Thank you, Patti! You were correct. It turns out there was a
> >> vulnerability scan run against that network at that time.
> > 
> > Did you configure your bacula to use SSL/TLS connection?
> > I wonder if that would help in your case.
> 
> I'd expect to still see "invalid HELO" logged. Firewalling the port
> would work if the scanner and bacula clients live in different subnets.

But the log says: UA Hello from client:10.32.12.18:9101
The same IP was mentioned several times in the logs Shawn provided.

The question is: is the IP 10.32.12.18 the IP of the client that had
to be backed up?

If yes then the vulnerability scan overtook the client's IP.

-- 
Josip Deanovic

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

Re: [Bacula-users] Packet size too big errors

[Dimitri Maziuk]

On 03/05/2018 12:00 PM, Josip Deanovic wrote:
> On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
>> Thank you, Patti! You were correct. It turns out there was a
>> vulnerability scan run against that network at that time.
> 
> Did you configure your bacula to use SSL/TLS connection?
> I wonder if that would help in your case.

I'd expect to still see "invalid HELO" logged. Firewalling the port
would work if the scanner and bacula clients live in different subnets.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bacula-users] Packet size too big errors

[Josip Deanovic]

On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
> Thank you, Patti! You were correct. It turns out there was a
> vulnerability scan run against that network at that time.

Did you configure your bacula to use SSL/TLS connection?
I wonder if that would help in your case.

-- 
Josip Deanovic

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

Re: [Bacula-users] Packet size too big errors

[Shawn Rappaport]

Thank you, Patti! You were correct. It turns out there was a vulnerability scan 
run against that network at that time.

--Shawn

From: "Clark, Patti" <clar...@ornl.gov>
Date: Monday, March 5, 2018 at 8:05 AM
To: Shawn Rappaport <srappap...@shutterfly.com>, 
"bacula-users@lists.sourceforge.net" <bacula-users@lists.sourceforge.net>
Subject: Re: [Bacula-users] Packet size too big errors

Not from your backup.  You have something on the network that is scanning the 
server your director is running on.  Probably Nessus.  I’m sure the client IP 
is a clue.

Patti

From: Shawn Rappaport <srappap...@shutterfly.com>
Date: Sunday, March 4, 2018 at 6:06 PM
To: "bacula-users@lists.sourceforge.net" <bacula-users@lists.sourceforge.net>
Subject: [Bacula-users] Packet size too big errors

I’m running Bacula 9.0.6 on CentOS 7.3. Today I received the following errors 
when my catalog was backing up:

03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=0

03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9101". Maximum permitted 100. Terminating connection.

03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9101". Maximum permitted 100. Terminating connection.

03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=50331667 too big from "client:10.32.12.18:9101". 
Maximum permitted 100. Terminating connection.

I manually ran a backup of my catalog after I received the errors and it was 
successful.

Does anyone know why I would be getting these messages and if it’s something to 
be concerned about?

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

Re: [Bacula-users] Packet size too big errors

[Clark, Patti]

Not from your backup.  You have something on the network that is scanning the 
server your director is running on.  Probably Nessus.  I’m sure the client IP 
is a clue.

Patti

From: Shawn Rappaport 
Date: Sunday, March 4, 2018 at 6:06 PM
To: "bacula-users@lists.sourceforge.net" 
Subject: [Bacula-users] Packet size too big errors

I’m running Bacula 9.0.6 on CentOS 7.3. Today I received the following errors 
when my catalog was backing up:

03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=0

03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=121984032 too big from 
"client:10.32.12.18:9101". Maximum permitted 100. Terminating connection.

03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=138759248 too big from 
"client:10.32.12.18:9101". Maximum permitted 100. Terminating connection.

03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in 
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=-4
03-Mar 12:28 xbacdirector01-lv.internal.shutterfly.com-dir JobId 0: Fatal 
error: bsock.c:819 Packet size=50331667 too big from "client:10.32.12.18:9101". 
Maximum permitted 100. Terminating connection.

I manually ran a backup of my catalog after I received the errors and it was 
successful.

Does anyone know why I would be getting these messages and if it’s something to 
be concerned about?

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