We've signed up with KnowBe4 and are currently running phishing campaigns against a small group of test users (basically the IT department). Since folks have been marking the messages as spam (which is good), SpamAssassin has learned this and is now starting to automatically catch the phishing campaign emails and direct them to the user's Junk folder.

I threw together a basic rule to help reduce the message score. Here is the rule:

header AH_KNOWBE4   Received=~ /phishtest\.knowbe4\.com/
score AH_KNOWBE4    score -10.0
describe AH_KNOWBE4 Prevents KnowBe4 campaign emails from falling into users Junk folders

The rule is being triggered. However, instead of applying the score of -10, a score of 1 is applied. I'm not sure why.

For what it's worth we're running Zimbra 8.6.0

What am I doing wrong?

Just kidding, of course.

From what I've been reading regarding TempDB in a RAM disk is that it's not recommended these days. The way the MSSQL engine works (if configured properly) is it uses all the RAM of the server (gets complicated after 64 GB RAM if you're using the Standard edition, but even then it can use more). So, in theory, TempDB should be in RAM as much as the server allows. It will only "spill" to disk if there is not enough RAM to complete whatever TempDB operation is happening at the time.

From what I'm reading, the recommendation these days is to put TempDB on a local SSD and/or beef up the amount of RAM the MSSQL server has.

https://www.brentozar.com/archive/2014/12/sql-server-2012-standard-edition-max-server-memory-mb/

Well, I guess I did invite the conversation myself by asking if I should rely on UTM features instead of limiting outbound traffic. D'oh!

@dafyre said in Linux RAID Question - Software or "Hardware" ?:

@marcinozga said in Linux RAID Question - Software or "Hardware" ?:

My money is on fake RAID you got there. So use md.

@marcinozga said in Linux RAID Question - Software or "Hardware" ?:

My money is on fake RAID you got there. So use md.

Also because you already use MD.

You know what, I can even move the two disks to my new workstation and not have to transfer any data.

I think the answer may have been found...

@momurda Huh.

lvextend -l +100%FREE -r /dev/mapper/centos-root

Seems to have done it.

I swear I ran the command multiple times. I suspect I was missing the "+" on "+100%FREE". I wonder what the difference is?

As I'm working through redacting stuff from this log sample, I'm noticing that most of the auths are coming via IMAP. I'm wondering if I can just disable IMAP externally (block the port at my firewall. Anyone who uses mail outside of our network connects via Exchange (we have Zimbra licensing) or the web interface. At least that's how they should be connecting at any rate. I'll have to talk to my boss. Hmm...

@storageninja said in Malicious Logins To Zimbra Mail Server:

Lastly, who still uses Zimbra? We used to own it, but now just use O365 (and have Microsoft's billion dollars of security spending and IDS in front of it).

Obviously you have no need to be in this thread, then. I'm looking for suggestions on mitigating my existing services from the current threat. Not, "who uses this crap these days?"

@dafyre said in Malicious Logins To Zimbra Mail Server:

@scottalanmiller said in Malicious Logins To Zimbra Mail Server:

@dafyre said in Malicious Logins To Zimbra Mail Server:

I'm going to echo @StorageNinja's comments about POP3 and / or IMAP -- disable them and force folks to use the ActiveSync setup and/or the Webmail.

Does that solve anything? Same issues.

...(how long does it take them to switch from IMAP/POP to ActiveSync?).

I will be able to tell you soon.

Hey All,

I would like to write a script to dynamically handle adding/removing users to a security group in Active Directory.

Basically, if a user's E-mail attribute matches a certain pattern (*@domain.org), I want to add them as a member of a group (Group X). If it doesn't match, I want to remove them from the group if they are a member.

So I'm thinking the script (or possibly two separate scripts) would need to work as follows:

Grab a list of current members of the group. Check each member for pattern that makes them eligible for said group. If no match, remove them from the group.

Grab a list of users that aren't a member of the group. Check each user for pattern that makes them eligible for said group. If matched, add them to the group.

I haven't had the privilege of scripting anything related to Active Directory. I'm assuming PowerShell will be the way to go. However, I'm still learning/researching beyond that. Any tips/tricks/suggestions would be greatly appreciated.

Thanks!

EDIT: A link to what I've come up with: https://pastebin.com/0JvUrzQU

I think I found what may be the culprit!

Yeah, I still have a XenServer 6.5 pool. Planning to upgrade to 7.2 in the near future, but until then...

Last night I got an alert from this XenServer pool about an SR having "No space left on device" due to "Run out of space while coalescing." Turns out the SR in question is one I have set up specifically for our Zimbra instance.

It's got two virtual disks: a 20 GB disk for the OS, and a 1 TB disk for the Zimbra install.

There are no snapshots on the VM. However, the SR claims to be just about full.

I've tried running the Storage > Reclaim Free Space in XenCenter, but that results in no change.

As a result, I cannot perform any snapshot based backups of the VM.

Any ideas on what I can try to get this cleaned up?

Here is the output from xapi-explore-sr

Zimbra_Vol1 (3 VDIs)
└─┬ base copy - c52a7680-b3fa-4ffd-8e73-a472067eb710 - 85.97 Gi
└─┬ base copy - 00c565b0-ab40-4e6d-886e-41c51f62992a - 1024.79 Gi
└── mail.domain.org 1 - 586e7cc3-3fbc-4aa1-89bc-6974454aee7d - 1026.01 Gi

I restored our production Zimbra server (CentOS 7) from backup to use as a testing environment for upgrading from Zimbra 8.6.0 to current (8.8.6 as of this writing).

Restore was fine. Gave the host an IP on a separate network. Followed a Zimbra wiki article on changing the server's hostname which worked no problem (from what I can tell). Fired up the services and Zimbra 8.6.0 came up hunky dory.

I do a yum update and install all pending updates (not many since I try to keep prod as current as possible), reboot the test server to verify Zimbra is still happy. Everything is good.

I download the 8.8.6 installer and current hotfix and stage them. I then snapshot the VM.

I run the 8.8.6 installer and it completes without complaint.

Where the problems begin. I cannot get to the Zimbra user interface. Management (7071) works fine. This points to a proxy issue.

I check and the proxy service is not running. I fire it up manually using zmproxyctl start and wait a minute. I eventually get the following error:

Starting proxy...nginx: [emerg] invalid URL prefix in /opt/zimbra/conf/nginx/includes/nginx.conf.zmlookup:3

I edit the file in question and, sure enough, the production IP is listed.

zm_lookup_handlers [PROD-IP]:7072/service/extension/nginx-lookup;

So I change it to the IP of the test VM (also tried 127.0.0.1 for the heck of it). However, this did not resolve the problem. Attempting to start the proxy service results in the same error.

So I test by telnetting to [TEST-IP]:7072 and it works. I try browsing to the path as shown in the config via a web browser and I get (from Chrome):

[TEST-IP] didn’t send any data. ERR_EMPTY_RESPONSE

Though I don't know if that indicates if there is an issue or not with whatever service is listening on 7072.

Any ideas?

This would be a bit more work to set up initially as it would probably mean moving away from FreeNAS, but might be worth considering. Of course, you'd need somewhere to stage your 200TB of data which would be a huge feat in itself. But, jussst in case you might be in the market to build a new box....

I've been considering XFS + duperemove (https://github.com/markfasheh/duperemove) for some of my storage needs.

Duperemove is a simple tool for finding duplicated extents and submitting them for deduplication. When given a list of files it will hash their contents on a block by block basis and compare those hashes to each other, finding and categorizing blocks that match each other. When given the -d option, duperemove will submit those extents for deduplication using the Linux kernel extent-same ioctl.

Duperemove can store the hashes it computes in a 'hashfile'. If given an existing hashfile, duperemove will only compute hashes for those files which have changed since the last run. Thus you can run duperemove repeatedly on your data as it changes, without having to re-checksum unchanged data.

What's nice about duperemove is that it's an "out of band" process so to speak. So you can run it during off-peak utilization and start/stop the process at will. It doesn't require RAM like ZFS.

Another revision.

Added logic for when "lastlogontimestamp" does not exist. This indicates the account has never logged in. So now if "lastlogontimestamp" doesn't exist it checks the account's creation date and disables the account if the creation date is past the expiration threshold.

Also added basic email reporting.

param (
    [string]$group,
    [string]$days = 30,
    [string]$test = "y"
)

# This script will search AD for eligible accounts to disable if they have either
# 1) never logged in and are older than the expration, or 2) if the last login is older than the expiration.

$emailAddrTo = "[email protected]"
$emailAddrFrom = "[email protected]"
$emailSMTP = "mail.domain.org"

$logStart = get-date -format g
$hostName = $env:COMPUTERNAME
$scriptPath = split-path -parent $MyInvocation.MyCommand.Definition
$scriptName = $MyInvocation.MyCommand.Name
$log = "$scriptPath\$scriptName.log"
$delimitedList = "$scriptPath\$scriptName.delimited.txt"

# If the group parameter is not specified, throw an error and short script usage example.

if ( -not ($group)) {
    echo "Group parameter missing."
    echo "Script usage: $scriptName -group `'AD Group`' -days 30 -test NO"
    echo "If `"-days`" isn't specified the default is 30."
    echo "If `"-test NO`" isn't specified, no changes will be made."
    exit
}

echo "Disabling accounts in group $group that have no logged in for more than $days day(s)."
if ( $test -ne "NO") { echo "Running in **TEST** mode.  No changes will be made!" }

import-module activedirectory

# Select AD accounts based on group parameter

if ( $group -eq "All") {
    echo "Group All specified, grabbing all Active Directory users"
    $disableList = @(get-aduser -filter * | select -expandproperty SamAccountName)
}
else {
    echo "Grabbing Active Directory users that are a member of $group"
    $disableList = @(get-adgroupmember $group | select -expandproperty SamAccountName)
}

# Set expiration threshold based on days parameter

$expiration = (get-date).adddays(-$days)

# Define arrays to log eligible accounts

$noLogons = @()
$expiredLogons = @()

# Loop through accounts

foreach ($acct in $disableList) {

    # Reset $lastLogonTS to accomodate for null results.

    $lastLogonTS = ''

    echo "Processing account $acct"

    # Get user's distinguished name

    $acctDN = get-aduser $acct -properties distinguishedname | select -expandproperty distinguishedname

    # Check if account is disabled.  If disabled, skip account.

    $isEnabled = get-aduser $acct -properties enabled | select -expandproperty enabled

    if ( $isEnabled -eq $false) {
        echo "$acct is already disabled, skipping."
    }
    else {

        # Get the last logon timestamp for user.  If user has no timestamp, this will error (which means user has never logged in)
    
        $lastLogonTS = get-aduser $acct -properties lastlogontimestamp | select -expandproperty lastlogontimestamp -ErrorAction SilentlyContinue
    
        # If last logon timestamp does not exist, check when the account was created.  If the account is older than the threshold, disable.
    
        if (!$lastLogonTS) {
            $acctCreation = get-aduser $acct -properties whencreated | select -expandproperty whencreated
            if ( $acctCreation -lt $expiration) {
                echo "$acct has no recorded login and was created more than $days ago (created $acctCreation) which makes it eligible for deactivation."
                if ($test -eq "NO") {
                    disable-adaccount -identity $acct
                    echo "$acct disabled"
                    $noLogons += "$acct | $acctDN | Created: $acctCreation"
                }
                else {
                    $noLogons += "$acct | $acctDN | Created: $acctCreation | TEST ONLY"
                }
            }
        }
        else {
    
            # Convert last logon timestamp from file time to date time     
        
            $lastLogon = [datetime]::FromFileTime($lastLogonTS)
        
            # If last logon timestamp is older than the threshold, disable account.
        
            if ($lastLogon -lt $expiration) {
                echo "$acct's last logon was more than $days days ago ($lastLogon) and is eligible for deactivation."
                if ($test -eq "NO") {
                    disable-adaccount -identity $acct
                    echo "$acct disabled"
                    $expiredLogons += "$acct | $acctDN | Last Logon: $lastLogon"
                }
                else {
                    $expiredLogons += "$acct | $acctDN | Last Logon: $lastLogon | TEST ONLY"
                }
         
            }
        }
    }
}

# Compile report

    # Start log file
    $logEnd = get-date -format g
    write-output "Log for $scriptName`r`nExecuted on $hostName`r`nScript started $logStart`r`nScript ended $logEnd`r`n" | out-file $log

    # Generate list of users removed from group, if any.
    if (!$noLogons) {
        write-output "Accounts older than $days days with no logon were not found (this is good!).`r`n" | out-file -append $log
        }
    else
        {
        write-output "The following accounts have been disabled because they are older than $days days and have never been used:" | out-file -append $log
        write-output $noLogons | out-file -append $log
        write-output "" | out-file -append $log
        }

    # Generate list of users added to the group, if any.
    if (!$expiredLogons) {
        write-output "Accounts with the last logon older than $days days were not found (yay!)." | out-file -append $log
        }
    else
        {
        write-output "The following accounts have been disabled because their last logon was more than $days days ago:" | out-file -append $log
        write-output $expiredLogons | out-file -append $log
        }

    # Dump account information to text file to be attached to the email.

    write-output $noLogons | out-file $delimitedList
    write-output $expiredLogons | out-file -append $delimitedList


    # Send log to $emailAddr if variable is set.
    if (!$emailAddrTo) {
        write-output "`r`nNo email address specified, no report sent." | out-file -append $log
        }
    else {
        $emailBody = get-content -path $log | out-string
        send-mailmessage -from "$hostName <$emailAddrFrom>" -to $emailAddrTo -subject "$scriptName Report" -body $emailBody -smtpserver $emailSMTP -attachments $delimitedList
        }

I'm working on a simple PowerShell script that'll spit out all the users that have a Home Directory currently configured. I'm playing with Get-ADUser and it's not behaving the way I'd expect. I started with the following command:

Get-ADUser -Filter 'HomeDirectory -like "*"' -Property SamAccountName,HomeDirectory,HomeDrive | export-csv -path (Join-Path $pwd HomeDirs.csv) -encoding ascii -NoTypeInformation

However, this seems to only return 26 25 accounts. I know for a fact I have WAY more than 26 25 accounts with Home Directories. So, I took a step back by trying the following:

Get-ADUser -Filter * -Property SamAccountName,HomeDirectory,HomeDrive | export-csv -path (Join-Path $pwd HomeDirs.csv) -encoding ascii -NoTypeInformation

This returns what looks like all users in AD. However, many users that have a Home Directory configured have an empty/null HomeDirectory property.

I am baffled as to why this is happening. Does anyone have any suggestions?

EDIT: Changed record count from 26 to 25...forgot to account for the CSV header.

A quick update for y'all that are watching/participating in this thread (thank you, by the way!).

Late Friday I realized where the lockouts where coming from. We have a Windows VM that has a suite of applications that folks need to use every blue moon or so, and they access the VM via RDP. Of course, users don't log out, they just close the RDP client (I am going to fix this). The user in question had an old logon session on this VM. Killing the user's session (I just rebooted the VM) seems to have done the trick.

Now the goal is to better position myself for the next time this happens. I also figure it's probably not a bad idea to have more visibility on account lockouts and where they are coming from in general.

Sounds like a pretty awesome project! I would love to be involved in a project like that.

I've never been big on the whole "VPN" subscription thing, but this may make me consider it. I'm already paying my ISP (AT&T) $60 /month for service...now you're going to sell my browsing history and make even more money off me. I doubt service would improve and/or become less expensive...