How I got my hands into this.

Well, the step by step on how I met this new challenge. You may find the general info here (https://derekdemuro.me/blog/server-downtime-due-network-outage(link is external)), don’t get me wrong, the solution is not that big deal, yet it can get a bit tricky if you have a complicated network with our limitations.

You may find our network diagram on the site.

Well, everything started while I was working. On one of the networks, I noticed a constant 120 KByte/s, so I head up to the server and started trying to filter its source from the logs, thankfully. As I began using Munin, we were logging the queries on the Bind Server. After “tail -f /var/log/bind” I noticed many questions for isc.org, strangely asking for all the records on that domain.

So to that moment, I thought, Research TIME!.

Well yeah, so the attack is old as time itself, but I did not know as it never happened to us, so we never cared to follow this kind of threat.

Well going over this we found:?

After this happened, we started noticing this has been going for a while, as you can see at the blog post, so here’s the fix!.

Depending on your scenario here are some options:

1.On windows (Turn off recursive queries).

On Linux (two ways).

First:

As some may know, iptables are extensive and a robust way to protect a standard server without external help, so adding these two lines to your INPUT chains should get it fixed right away.

iptables -A INPUT -p udp -m string –hex-string “|03697363036f726700|” –algo bm –to 65535 -j DROP

That should match (isc.org) another way is:

iptables -A INPUT -p udp -m string –string “isc?org?” –algo bm –to 65535 -j DROP

Remember, if another attack appears, check the packets with Wireshark or similar.

Second:

Turn off recursive queries for networks outside your own with ACL’s.

Example:

On Bind 9

/etc/bind/named.conf

acl vpn_nets {
10.8.0.0/24;
10.9.0.0/24;
};
acl external_nets {
any;
vpn_nets;
};
acl local_nets {
192.168.5.0/24;
127.0.0.1;
};

Add this at the beginning of the configuration file.

This should not happen anymore, and you should be outside the red zone.

Keep in mind the following process is to make sure a user is SAFELY removed from the system, if you want to remove the user, jump to “To delete user account called [user], enter:”

The following is the recommended procedure to delete a user from the Linux server. First, lock a user account, enter:

passwd -l username

Backup files from /home/user to /backup:

tar -zcvf /backup/account/deleted/[user].$uid.$now.tar.gz /home/[user]/

Please replace $uid, $now with actual UID and date/time. userdel command will not allow you to remove an account if the user is currently logged in. You must kill any running processes which belong to an account that you are deleting, enter:

pgrep -u [user]
ps -fp $(pgrep -u [user])
killall -KILL -u [user]

To delete user account called [user], enter:

userdel -r [user]

Delete at jobs, enter

find /var/spool/at/ -name "[^.]*" -type f -user [user] -delete

To remove cron jobs, enter:

crontab -r -u [user]

To remove print jobs, enter:

lprm [user]

To find all files owned by user [user], enter:

find / -user [user] -print

You can find file owned by a user called [user] and change its ownership as follows:

find / -user [user] -exec chown newUserName:newGroupName {} \;