Odd security log entries daily

[SkyMonkey]

What's going on here? I've been getting these entries occasionally in my security log for a while now. It doesn't happen everyday, and doesn't seem to correlate with anything I'm doing with the NAS.

I have snapshots set for daily to keep two weeks and weekly to keep two months on media, so I think the first entry dealing with the snapshot from the 17th is the deletion of it, but I'm not sure why the rest are showing up or what really any of the other lines mean given that some of my other datasets have identical snapshot settings and do not appear anywhere in this message.

Code:

freenas.local changes in mounted filesystems:
--- /var/log/mount.today        2013-07-30 03:01:01.000000000 -0700
+++ /tmp/security.LBgWb4OD      2013-07-31 03:01:01.000000000 -0700
@@ -9,7 +9,6 @@
bluemesa/jail          /mnt/bluemesa/jail      zfs    rw,noatime,nfsv4acls    0 0
bluemesa/logs          /mnt/bluemesa/logs      zfs    rw,noatime,nfsv4acls    0 0
bluemesa/media        /mnt/bluemesa/media    zfs    rw,noatime,nfsv4acls    0 0
-bluemesa/media@auto-20130717.0000-2w /mnt/bluemesa/media/.zfs/snapshot/auto-20130717.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
bluemesa/media@auto-20130718.0000-2w /mnt/bluemesa/media/.zfs/snapshot/auto-20130718.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
bluemesa/media@auto-20130719.0000-2w /mnt/bluemesa/media/.zfs/snapshot/auto-20130719.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
bluemesa/media@auto-20130720.0000-2w /mnt/bluemesa/media/.zfs/snapshot/auto-20130720.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
 
Checking for uids of 0:
root 0
 
Checking for passwordless accounts:
 
Checking login.conf permissions:
 
Checking for ports with mismatched checksums:
 
freenas.local login failures:
 
freenas.local refused connections:
 
-- End of security output --

Here is another one from a while ago when some other datasets showed up in the daily run.

Code:

freenas.local changes in mounted filesystems:
--- /var/log/mount.today        2013-06-22 03:01:01.000000000 -0700
+++ /tmp/security.Zrx5GPe3      2013-06-23 03:01:01.000000000 -0700
@@ -5,7 +5,6 @@
/dev/ufs/FreeNASs4    /data                  ufs    rw,noatime      2 2
bluemesa              /mnt/bluemesa          zfs    rw,nfsv4acls    0 0
bluemesa/games        /mnt/bluemesa/games    zfs    rw,noatime,nfsv4acls    0 0
-bluemesa/games@auto-20130609.0000-2w /mnt/bluemesa/games/.zfs/snapshot/auto-20130609.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
bluemesa/games@auto-20130610.0000-2w /mnt/bluemesa/games/.zfs/snapshot/auto-20130610.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
bluemesa/games@auto-20130611.0000-2w /mnt/bluemesa/games/.zfs/snapshot/auto-20130611.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
bluemesa/games@auto-20130612.0000-2w /mnt/bluemesa/games/.zfs/snapshot/auto-20130612.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
@@ -21,7 +20,6 @@
bluemesa/gents        /mnt/bluemesa/gents    zfs    rw,noatime,nfsv4acls    0 0
bluemesa/logs          /mnt/bluemesa/logs      zfs    rw,noatime,nfsv4acls    0 0
bluemesa/media        /mnt/bluemesa/media    zfs    rw,noatime,nfsv4acls    0 0
-bluemesa/media@auto-20130609.0000-2w /mnt/bluemesa/media/.zfs/snapshot/auto-20130609.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
bluemesa/media@auto-20130610.0000-2w /mnt/bluemesa/media/.zfs/snapshot/auto-20130610.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
bluemesa/media@auto-20130611.0000-2w /mnt/bluemesa/media/.zfs/snapshot/auto-20130611.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
bluemesa/media@auto-20130612.0000-2w /mnt/bluemesa/media/.zfs/snapshot/auto-20130612.0000-2w zfs      ro,nosuid,noatime,nfsv4acls    0 0
 
Checking for uids of 0:
root 0
 
Checking for passwordless accounts:
 
Checking login.conf permissions:
 
Checking for ports with mismatched checksums:
 
freenas.local login failures:
 
freenas.local refused connections:
 
-- End of security output --

I suppose this could be expected behavior of some kind that I'm unable to understand...

 

[fracai]

I've only ever seen this behavior when I restore a file by copying it from the hidden .zfs/snapshot directory structure. My assumption is that accessing the snapshots in this way mounts them and they stay that way until they are pruned. I imagine there's some command that would unmount them sooner, but I've never cared to investigate it that far.

 

[SkyMonkey]

Hmm, I didn't restore anything via that method.

I have cloned a snapshot of media (which then showed up in the root of the media directory and the associated CIFS share), restored some files, and then deleted the clone. I probably also have restored files via the "Previous Versions" dialog in Windows (which for some reason only shows a limited amount of entries, which aren't timestamped correctly, but are titled with the snapshot date/time).

 

[mikeyr]

I've got the same kind of thing going on. I've been ignoring it, but recently had some FreeNAS issues developed because of something else (unrelated) that I ignored for too long... so I'm "once bitten, twice shy" about "just ignoring" things I don't understand...

Anyone out there have any ideas about the "Freenas.local changes in mounted filesystem" message -- why does it appear sometimes, what does it mean, what is it *supposed* to mean?

Thanks

 

[Dusan]

Anyone out there have any ideas about the "Freenas.local changes in mounted filesystem" message -- why does it appear sometimes, what does it mean, what is it *supposed* to mean?

It means exactly that -- mounted filesystems changed :). This happens when you create/delete a dataset/pool, clone a snapshot, access a snapshot via shadow copies, ..

 

[fracai]

It means exactly that -- mounted filesystems changed :). This happens when you create/delete a dataset/pool, clone a snapshot, access a snapshot via shadow copies, ..

Is there a way to unmount these shadow copies manually?

 

[mikeyr]

Well I guess I'm confused about what exactly constitutes a "change"... and a "change" since when?

Does writing or changing a data file within a mounted filesystem constitute a "change" in the filesystem?
Is it a change to the data in a mounted filesystem or a change to the configuration of the mounted filesystems that registers as a "change"?

I have automatic snapshots set up and a daily replication task to another backup server. Other than that I am not mounting/unmounting anything or accessing any snapshots or shadow copies or anything like that. Does adding a snapshot qualify as a "change"? I can't see that replicating should qualify as a "change"...

And the big question: why is this reported in the security log? Am I supposed to be looking for intruders who have changed my filesystems in unexpected ways; or what am I looking for that is security related that the "change in mounted filesystems" that is being reported...?

Thanks for your help!

 

[fracai]

It's "changes in mounted filesystems". It's meant to read as "the list of mounted filesystems has changed".

I presume that the security angle relates to available files. Plus, an attacker could mount their own files on top of system files and wait for their malicious copies to be executed. I don't know if that's the reason it's in the security section, but it's a possible attack, if not feasible.

 

[Dusan]

Is there a way to unmount these shadow copies manually?

Yes, just run umount snapshot_name (mount -v will show you all that are mounted).

Well I guess I'm confused about what exactly constitutes a "change"... and a "change" since when?

fracai is correct, the list of mounted filesystems changed -- something got mounted or unmounted. As to since when: since the last security e-mail.

I have automatic snapshots set up and a daily replication task to another backup server. Other than that I am not mounting/unmounting anything or accessing any snapshots or shadow copies or anything like that. Does adding a snapshot qualify as a "change"? I can't see that replicating should qualify as a "change"...

I think if you even once accessed a shadow copy, samba (or something) will keep mounting the new snapshots as they are taken.

 

[fracai]

Yes, just run umount snapshot_name (mount -v will show you all that are mounted).

Excellent, this always drives me crazy when I start seeing those reports.

 

[Dusan]

Excellent, this always drives me crazy when I start seeing those reports.

You won't see them in 9.2.1 ;): https://bugs.freenas.org/projects/f...ions/aa62b11bd6d694536fdd7b93a032a780fafda3a8

 

[fracai]

Awesome!