Watch out for IPTables and order of execution of rules

I recently need to block Barracuda network ips from accessing my mail server, MailWizz. I did the typical

iptables -A INPUT -s 64.235.144.0/20 -j DROP

iptables -A INPUT -s 209.222.80.0/21 -j DROP

iptables -A INPUT -s 35.176.92.96/27 -j DROP

iptables -A INPUT -s 35.157.190.224/27 -j DROP

iptables -A INPUT -s 5.188.211.0/24 -j DROP

iptables -A INPUT -s 204.101.161.159 -j DROP

iptables -A INPUT -s 207.102.138.158 -j DROP

then

service iptables save

service iptables end

the problem with this setup is that those rules end up getting appended to the end and never get blocked. It’s better to go into the iptables directly. ON Centos 7, that is located in /etc/sysconfig/iptables. I added these lines directly before any of the rules were executed.

-A INPUT -s 64.235.144.0/20 -j DROP
-A INPUT -s 209.222.80.0/21 -j DROP
-A INPUT -s 35.176.92.96/27 -j DROP
-A INPUT -s 35.157.190.224/27 -j DROP
-A INPUT -s 5.188.211.0/24 -j DROP
-A INPUT -s 204.101.161.159/32 -j DROP
-A INPUT -s 207.102.138.158/32 -j DROP

I’m also putting in a post on how to block Amazon Bots.  However you’ll need to redo the above after running these commands in Centos 7

yum install git

git clone https://github.com/corbanworks/aws-blocker.git

yum install jq

cd aws-blocker

bash aws-blocker

iptables-save | sudo tee /etc/sysconfig/iptables

service iptables save

service iptables restart

Then add the above manually and you’ll have both AWS and Barracuda blocked.

VisualChron Fails SSIS Task

I recently had a project with SQL Server 2014 utilizing the Visual Studio 2015 shell for a Sql Server Integration Project. I tried to run the SSIS task in Visual Chron and kept getting errors. After exhaustive research I discovered that I had to make sure to go into the project properties and choose SQL Server 2014 as your TargetServerVersion. Once I did this and recompiled one of my scripts, it worked.

 

Fixing SQL Logins after Migration

I recently migrated a SQL Server 2008 R2 database to SQL Server 2014.  We host with Rackspace, so I had them restore our databases from backup to the new server. I was left with database users that weren’t linked to SQL Server Users.  Even after I added the users they were still not linked together and the system wouldn’t offer me the option. The following SQL allowed me to fix the problem.

  1. Assign ownership of the database to a current user on the new server Alter authorization on database::[DATABASENAME] to [DOMAIN\USERNAME]
  2. Find the users that aren’t associated with their SQL Login with Exec sp_change_users_login ‘Report’
  3. Autofix the logins to link the SQL Server Database User to the SQL Server Login User exec sp_change_users_Login ‘Auto_Fix’,’USERNAME’

The new database clearly won’t have the SQL Server Login Users until you add them so add them manually before you run the above routines.