Category Archives: advice
One of the more useful tools in helping to locate when/where a server was compromised are manual anti-virus scans. Additionally, a great hurdle to put up in front of malicious attackers is a scanner that scans files as they are created/modified to check for malicious content.
In the linux world, there’s not always a great understanding of what options are available, so I’m very briefly going to outline three that I am aware of and/or use.
The three I am going to cover are:
# gdb -p (pid of mysql) -ex "set max_connections=200" -batch
Note, this is the PID of mysql, not mysql_safe.
Very handy for when you need to make that quick adjustment but don’t have permission to restart the database.
If you’re like me, you’re seeing more and more requests to disable plaintext authentication without encryption for POP and IMAP due to the higher number of people going for PCI compliance.
Fortunately, in Dovecot, this is very easy to configure. The setting you want to use is:
disable_plaintext_auth = yes
This can be found in /etc/dovecot/conf.d/10-auth.conf on newer Dovecot installs:
# Disable LOGIN command and all other plaintext authentications unless
# SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP
# matches the local IP (ie. you’re connecting from the same computer), the
# connection is considered secure and plaintext authentication is allowed.
#disable_plaintext_auth = yes
Restart the service after uncommenting the directive out, and you’re golden.
Edit: The conf.d/ folder seems to have appeared with Dovecot 2.x versions. If you’re using Dovecot 1.x, you should be able to plug the line into your /etc/dovecot.conf file without issue.
Just a little useful trick, if you’ve ever had need of it.
If you have files in lsof that are “deleted”, but still being held open by a process, it is actually possible to restore that file.
To show you what I mean, I have created a basic test file:
[darke@pabu ~]$ cat file
this is my test file
In one terminal, I open that file with less. In another, once the file is open in less, I delete the file. If I search lsof for deleted files with that file name:
[darke@pabu ~]$ lsof | grep deleted | grep file
less 8351 darke 4r REG 253,3 22 118 /home/darke/file (deleted)
Now, if I close less, the file will vanish forever. However, as long as less has it open, I can pull the file out of /proc based on the above information. The relevant fields you need are the second and fourth (process ID and file descriptor):
[root@pabu ~]# cp /proc/8351/fd/4 /home/darke/file-restore
[root@pabu ~]# cat /home/darke/file-restore
this is my test file
This is a limited use case, as it depends on the file still being open by something. However, if you’ve ever been stuck trying to figure out what deleted tmp files being held open by apache are (for example), it can be quite useful.
As an update to an older article I once posted, it is now much simpler to enforce a strict password policy on Horde through Plesk.
In 11.5.30 plesk and higher, first make sure you’re current on all microupdates
/usr/local/psa/admin/bin/autoinstaller --select-product-id plesk --select-release-current --reinstall-patch --install-component base
and from there all that is required is to change the “Security Policy” in the Plesk control panel and it will impact Horde’s password functions.
Home> Tools & Settings> Security Policy
Just in case anyone out there is following my old article and noticing that the changes they are making are not being applied, it is because Plesk’s implementation of Horde is now using Plesk’s password policy directly.
I’m usually someone who learns new things because I become irritated with “the way things are”. The following tip is a perfect example. I grew tired of my usb drive going into sleep mode and causing issues with some of the things I use it for, so I decided to see if I could tell it to never go to sleep.
Turns out? You can.
yum install sdparm
sudo aptitude install sdparm
Once that is installed, you can point it at your USB device. In my case, it was /dev/sdc. If you’re unsure what device it has been labeled as, consult the output of “dmesg” and find it.
So, point sdparm to it with the command: sdparm -a
[root@pinja ~]# sdparm -a /dev/sdc
/dev/sdc: Seagate FreeAgentDesktop 100F
Power condition mode page:
PM_BG 0 [cha: n, def: 0, sav: 0]
STANDBY_Y 0 [cha: n, def: 0, sav: 0]
IDLE_C 0 [cha: n, def: 0, sav: 0]
IDLE_B 0 [cha: n, def: 0, sav: 0]
IDLE 0 [cha: n, def: 0, sav: 0]
STANDBY 1 [cha: y, def: 1, sav: 1]
ICT 0 [cha: n, def: 0, sav: 0]
SCT 9000 [cha: y, def:9000, sav:9000]
Power consumption mode page:
ps_id 0 [cha: n, def: 0, sav: 0]
SAT ATA Power condition mode page:
APMP 0 [cha: n, def: 0, sav: 0]
APM 0 [cha: n, def: 0, sav: 0]
Notice STANDBY_Y has a 0 beside it? That means standby is disabled (because I shut it off earlier). The actual flag can change a bit from drive to drive (some just say STANDBY, for example) so just pay attention to what is listed there. If you find it has a 1, you will need to run the commands:
sdparm --command=start /dev/sdc
sdparm --clear STANDBY_Y -6 /dev/sdc
sdparm -save -6 /dev/sdc
Another “sdparm -a /dev/sdc” should then show you the cleared value and we’ve saved it so it will persist through a reboot.
If you’ve ever had a system drift pretty wide on the time, you are aware that ntp can’t update the time after a certain amount of drift. I’ve found this to be a particular problem on some systems from a reboot, where the time never gets manually set and so it stays off kilter and just keeps drifting more and more.
On “Redhat” flavor boxes, you can edit
OPTIONS=”-u ntp:ntp -p /var/run/ntpd.pid”
OPTIONS=”-x -u ntp:ntp -p /var/run/ntpd.pid”
That -x is a very tiny change, but a huge effect. What this does is when you stop/start ntp (or it starts on a reboot of your system), it does the equivelent of
ntpdate -u time.server.of.choice
ie, forcing the manual update against your chosen time server. No more manually fixing drift that has gotten too wide. From a reboot the time is set to a value that ntp then can automatically update and keep updated moving forward.
service ntpd restart
and you’ll see it do the manual time update.
# service ntpd restart
Shutting down ntpd: [ OK ]
ntpd: Synchronizing with time server: [ OK ]
Syncing hardware clock to system time [ OK ]
Starting ntpd: [ OK ]
I realize that you are operating a business. I realize that keeping costs low is the name of the game. Honest, I do.
That being said? You need to understand something. Black Friday/Cyber Monday is not a surprise holiday that was announced 2 days ago. You’ve known this day was coming for months. You know it and I know it. So when you call me 24 hours before Black Friday, desperate to scale out your solution NOW NOW NOW because your site is going to tank otherwise?
Well, you have no one to blame but yourself. Sure, I’m going to do my best to help you. That’s what I do, but you need to understand how many clients I have. How many clients I have that think just like you do, all of whom are calling me 24 hours before Black Friday to make everything better.
In your own best business interests, plan to scale out your configuration 2-3 weeks before Black Friday and take it back down 2 weeks or so after NYE. Just put that in your budget every year. Understand that it is the name of the game. Because when you and thousands of others push administrators like me to rush scale out your configurations in a 24 hour window of time with no real opportunity to test?
Well, you’re just inviting trouble when the traffic begins to flood in.
Scale early, test often.
Just some friendly advice from a guy who has watched companies like yours make the same mistake year after year after year.