#!/bin/bash if [ -e alldomains ] then rm alldomains fi alldomains=( $(find /etc/httpd/conf.vhosts/ -name *.conf) ) for domain in ${alldomains[*]} do cat $domain | egrep "ServerName|ServerAlias" | egrep -v "#" | sed -e 's|ServerName||' -e 's|ServerAlias||' -e 's|www.||' -e 's|:80||' | tr -s ' ' '\n' | tr -d ' ' | sed -e '/^\s*$/d' >> alldomains done sort alldomains | uniq | sort -o alldomains
This gets all of the domains from ServerName and ServerAlias lines, takes out all of the white space and empty lines, and creates a file with just a list of the unique domain names.
This accounts for subdomains that use ‘www’ or have port :80 on the end.
For instance, www.somedomain.com and somedomain.com are the same, so the script takes out the ‘www.’ which leaves to copies of somedomain.com, which it then deletes one of them in the final output to the file. The same for ‘:80’.
]]>
So initially, this was quite confusing. All of a sudden people would have their IP blocked. I checked the different sites, and seemed to have no problem. Then when I logged in to the back end, BAM, blocked as well. We have Shorewall running, so doing:
shorewall show dynamic
Showed all of the IPs that Shorewall had blocked. This could also be done by using iptables
iptables -nL --line-numbers
Sure enough, my IP had been blocked. I unblocked my IP with:
shorewall allow ip.ad.dr.es
Or could also do
iptables -D INPUT 2
where INPUT is the position or section of the firewall chain, and “2” is the line number containing my IP address.
Then I checked with other web applications on that server. Where they also causing an issue? I logged in to an Omeka install. No problems.
OK. I know OSSEC is to blame some how. It’s an awesome HIDS (Host Intrusion Detection Software) that actively responds to issues on the server based on scanning through the system logs and various rules.
OSSEC keeps itself chroot’ed to /var/ossec/, so all of the ossec logs are located in /var/ossec/logs/.
I first looked in the /var/ossec/logs/active-responses.log. Sure enough, a couple of lines like this show my IP being completely blocked to the server.
Fri Jun 14 06:50:47 EDT 2013 /var/ossec/active-response/bin/host-deny.sh add - XXX.XX.XX.XX 1371207047.5913585 20101 Fri Jun 14 06:50:47 EDT 2013 /var/ossec/active-response/bin/firewall-drop.sh add - XXX.XX.XX.XX 1371207047.5913585 20101
So, there we are. OSSEC blocking the IP for some reason. Now why is it blocking the IP?
Taking a look in the /var/ossec/logs/alerts/alerts.log file to see why it thinks it needs to block the IP…
** Alert 1371206381.5698606: - ids, 2013 Jun 14 06:39:41 (server1) 127.0.0.1->/var/log/messages Rule: 20101 (level 6) -> 'IDS event.' Src IP: XXX.XX.XX.XX Jun 14 06:39:40 server1 suhosin[18563]: ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker 'XXX.XX.XX.XX', file '/var/html/wp-admin/admin.php', line 109)
There were other lines in there with my IP, but nothing would/should have caused blocking, like a WordPress login event, or an SSH login event. Also, the error above is categorized as an IDS event with level 6, which by default OSSEC rules means it gets blocked.
As a quick fix, I changed the “suhosin.memory_limit” option in /etc/php.d/suhosin.ini to 256M, and the “memory_limit” in /etc/php.ini to 256M so that no error would be generated.
Now came the hard part of finding out how to fix it for real. OSSEC is a pretty big beast to tackle, so I turned to my friendly web search engine to help out.
To fix the issue, I would need to write a decoder or new rule to ignore the suhosin rule causing the problem. OSSEC has descent documentation to get you started, but fortunately the blog linked above had the solution already. https://www.atomicorp.com/forum/viewtopic.php?f=3&t=5612
From user ‘faris’ in the forum linked above:
Add the following lines the the /var/ossec/etc/rules.d/local_rules.xml file.
<group name="local,ids,"> <!-- First Time Suhosin event rule --> <rule id="101006" level="14"> <if_sid>20100</if_sid> <decoded_as>suhosin</decoded_as> <description>First Time Suhosin Event</description> </rule> <!-- Generic Suhosin event rule --> <rule id="101007" level="12"> <if_sid>20101</if_sid> <decoded_as>suhosin</decoded_as> <description>Suhosin Event</description> </rule> <!-- Specific Suhosin event rule --> <rule id="101008" level="5"> <if_sid>101006,101007</if_sid> <match>script tried to increase memory</match> <description>Suhosin Memory Increase Event</description> </rule> </group>
What these new rules do is change the level of the default rules that were tagged/decoded as being suhosin errors. In the first rule, if the default error is 20100, and is decoded (or tagged, or matches) as suhosin, then set the level to 14 instead of the default 8.
The second rule detects if the default error 20101 is decoded as coming from suhosin and sets the level to 12 instead of the default 6.
The third new rule looks at any error tagged as suhosin and if the error has the matching text in it, then it sets the error level to 5 (below the limit for firing an active response).
So, just add that group of rules to the local_rules.xml file and restart the OSSEC service. BA-DA-BING! no more blocking the IP when logging in to WordPress.
]]>I was updating one server to use CentOS 6, and ran into this issue of setting up the iDRAC for remote console use. In previous versions, I would add a line to the /etc/inittab file. This is now unused. RedHat is favoring the “Upstart” system developed by and for Ubuntu. It starts services on request, rather than all at once.
So here is how I set up my Dell PowerEdge R510 with CentOS 6 to use the iDRAC6.
Info was taken from the RedHat manual, the Dell iDRAC manual, and probably a bunch of other sites that I googled for.
These steps are by no means comprehensive or detailed. I barely even know what’s going on myself, but it seems to work. It’s kind of cool to see a system boot up in your terminal. It’s like your terminal turns into a monitor connected to the server.
F2
to enter the BIOS setup utility during POST.<Enter>
.serial communication....On with serial redirection via com2
serial port address....Serial device1 = com1, serial device2 = com2
external serial connector....Serial device 1
failsafe baud rate....57600
remote terminal type....vt100/vt220
redirection after boot....Enabled
<Ctrl><E>
when prompted during POST. If your operating system begins to load before you press <Ctrl><E>
, allow the system to finish booting, and then restart your system and try again.<Enter>
. NIC Selection is displayed.<Enter>
.<Esc>
.<Esc>
./boot/grub/grub.conf
file as follows:cp /boot/grub/grub.conf /boot/grub/grub.conf.orig
/boot/grub/grub.conf
file as follows:serial --unit=0 --speed=57600
terminal --timeout=10 serial console
kernel ............. console=ttyS1,57600 console=tty1
/boot/grub/grub.conf
/etc/init/serial-ttyS1.conf
file.Sample File: /etc/inittab
/etc/securetty
/etc/securetty
file as follows:cp /etc/securetty /etc/securetty.orig
/etc/securetty
as follows:Add a new line with the name of the serial tty for COM2:ttyS1
Sample File: /etc/securetty
To connect to the managed system text console, open an iDRAC6 command prompt (displayed through an SSH session):
and type:
console com2
Only one console com2
client is supported at a time. The console -h com2
command displays the contents of the serial history buffer before waiting for input from the keyboard or new characters from the serial port.
To exit the console type these three keys: <Ctrl ><Shift >\
The default (and maximum) size of the history buffer is 8192 characters. You can set this number to a smaller value using the command:
racadm config -g cfgSerial -o cfgSerialHistorySize < number >
The first thing to do is update to the latest version. This ensures that if you need to turn this back into a dynamic site, it should hopefully be compatible with whatever the latest version is at that time.
Next, we’ll need to make it public to guests, so that wget has access to the pages.
Go to the Admin->Features and Options page and check the “Allow guests to browse the forum” box, then click save. Now we have to change the permissions on each board separately. Or with a bit of MySQL magic, we can change them all at once using the CONCAT operator. Open of phpMyAdmin, or something else of your choice. Before we mess with the data, make a copy of the table, just in case we totally hose it.
Browse to the ‘boards’ table, and then to the SQL tab. We’re going to enter an SQL command that will pre-pend (that’s append but onto the front rather than the end) some data.
UPDATE boards SET member_groups=CONCAT('-1,', member_groups) WHERE 1
This will add a -1, to the beginning of each field, which makes the board viewable by guests. No need to log in, which means wget can scrape the pages and turn them into HTML.
Now we get to play around with the theme files to get rid of forum specific items that we won’t need, like links to member info, the login, help, and search links, and anything else that we don’t want.
Here are some items to delete or alter, and the files I found them in for our home-made theme based off of an old default theme.
As it stands, SMF has some pretty ugly URLs. There are a couple of mods that I could never get to work. But editing a file and adding an .htaccess file seems to do the trick.
Open the Sources/QueryString.php file and look for the line like this:
$scripturl = $boardurl . '/index.php';
and get rid of the /index.php
Now create a .htaccess file in the root of the forum (in the same folder as the Settings.php file). It should look similar to this:
RewriteEngine On RewriteBase /7tah/forum/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /7tah/forum/index.php [L]
Now we run wget on the command line to grab the pages.
wget --mirror -P static-forum -nH -np -p -k -E --cut-dirs=2 http://domain.com/path/forum/
All of the static HTML files will now be located in a directory called static-forum.
Some filenames will be a bit broken. Specifically the style.css has an extra “?fin11” in the html files where the file is called. Also, it get’s name that way. So fix that by changing the name of the file to just style.css (it’s in your Theme directory). Then run this one-line command to search and replace throughout all of the static html files (run the command when you are in the static-forum directory.
find . -name '*.html' -type f -exec perl -pi -e 's/style.css%3Ffin11/style.css/g' {} \;
This will look for all of the references to the style.css%3Ffin11 file and change them to style.css. Then the pretty colors and formatting will work. Just for clarification, the %3F is code for a question mark. It shows up as such in the HTML source when viewing from a browser, but is displayed as such in the actual code.
Don’t forget to change the the actual name of the css file to style.css.
Depending on your needs, you may want to password protect your new static forum with an htaccess account. The good peoples at Dynamic Drive have an helpful tool for making the two files necessary to make this happen. Just plug in your desired user name, password, and location of the htpasswd file, and then it’s copy and paste into those files on the server.
I change the last line of the htaccess file to require user username
so that it works only with the given user, not any valid. But since it only pulls from the specified htpasswd file, it’s kind of pointless.
It’s a good idea to make a backup of the database and site files before getting rid of them. I just make a mysqldump of the database, throw it in the forum folder, and then make a tar or zip file of that and put the file in the new static forum folder for safe keeping.
Sit back and relax. Your forum is interactive no longer.
]]>