Share The Holiday Spirit This Year By Donating Toys For Children

Chronicles of a regular guy's rise to earning a living off the web...

This post is a bit outdated since the hack actually occurred about 8 months ago. But I thought it might be helpful to some folks who find themselves in the same boat I was in.
Back in early February I was hacking around my production Linux server when I happened to stumble upon a bizarre command in my "history" file. It was a removal command for a script I had never heard of... My stomach about fell through the floor. I quickly realized my production server had been hacked!
Quickly I checked my last login history and found that someone had logged in as "root" just a few hours before. According to the logs they were on my server for about 9 minutes. During that time they installed a web-based file system browser and then spent the remainder of their time on my server browsing my web site files. It appeared they were looking for passwords or database connectivity information. They also tried to grab my database, but it didn't seem to work according to the log files.
After 9 minutes they logged off. Then back on again about a half an hour later for just 1-2 minutes. No activity that I could tell other than to maybe remove the web script they left behind.
Aside from being scared to death of what I just witnessed in my log files, I came to the realization that I could not even trust what I was reading in the log files. Anyone who obtained root access could have easily spoofed the log files to make me think they didn't get very far...
I quickly started scanning my security log files to see how the heck they got in. For a few months now I had been noticing a brute force attack on my server. Someone was trying to guess a userid/password via SSH. My firewall was configured to block them by IP if they tried too many times, so I was not too worried about it. Well I should have been more worried. They eventually got in via their brute force attack. They successfully guessed my root password and bingo, the doors opened up. Wow. My worst nightmare.
I quickly changed every password on the box and locked it down. I had previously left a small door open (SSH) so I could remote to my box from anywhere if needed. I didn't want to limit SSH incoming requests from my home IP since I travel a lot. Well this came back to bite me.
So I locked SSH down via my firewall (APF) and came up with an alternative solution involving a 3rd party service to allow me to configure APF safely and have a dynamic IP address. That is all fine and dandy, but I still cannot be 100% sure the hacker didn't leave some other back door programs lying around.
I contacted my ISP to see if they could help me sniff out any potential problems. They checked my box out and said they didn't not see anything, but they agreed that there could still be a hidden trojan and we'd never know it until it was too late.
So we made a big decision to build a completely new server from scratch. We took a back up of our websites and data from before the break-in and used it to restore our websites on the new server. We locked down SSH access via a dynamic dns service, and we made our passwords as random, long and secure as we could.
We learned a hard lesson that month. Never ignore a potential security threat. Never think that your defenses are better than they are. Never underestimate.
I discovered a very interesting problem in the last month or so in regards to something called the "Bogon list". I had never heard of the Bogon list before, but after doing some research, I discovered it is a list of reserved IP ranges not released for public use.
Now from what I read online, many network routers across the internet will by default block request to and from IP address in the Bogon lists. Why? Well apparently spammers and other bad sorts have been known to try and use IP addresses from the range for whatever reason. So as a preventative measure, routers may simply ignore requests from these IP ranges, since they are technically suppose to be reserved and not in use by the public. This also saves on router processing cycles since they can simply discard the packets and move on.
Well on to my problem. I had a few users of my site complaining to me over email that they could no longer get to my site. For weeks they had been trying with no luck. They would get a timeout or page/site not available message.
Initially I tried seeing if their ISP was blocking our site (for whatever reason), and found the ISPs were not blocking it. One ISP however tipped me off that the user in question did have an IP address that was recently released from the Bogon list. The ISP simply gave the user a new IP and they were now able to access my site.
Armed with this information I started talking to my other users who were also unable to get to my site. Surprisingly they were all using IP addresses that were recently (in the last year) released from the Bogon list.
What this tells me is the Bogon system is a broken system. If they can release IP ranges to the public, and up to a year later those IP ranges are still being blocked by routers all over the net, how is anyone suppose to know when a site is really down, or up?
I was pissed because it makes my site look like it is offline, which is bad PR and get get my site a bad reputation in Google search results when users visit my links only to find they can't get to my pages and they go back to Google and clicks some place else.
Now I realize this problem appears to be isolated to a small set of IP ranges that get release periodically, but the the problem is one that is extremely difficult to troubleshoot, and even more difficult to track down and resolve. The "problem" router that might not have their Bogon list updated could be one of a hundred in the path from your site to the user's computer.
Long story short, if you have some users that just can't get to your site and you don't have a clue why, check their IP addresses against the Bogon release lists from the past year. Your users may need to request a new IP to regain access to your site.
This one is kind of obvious once you think about it, but I had overlooked it in my code, so I figured maybe some other webmasters out there may have as well. I found this snippet explaining the tip I want to share from a site called websitedatabases.com:
MySQL also uses indexes for LIKE comparisons if the argument to LIKE is a constant string that doesn't start with a wildcard character. For example, the following SELECT statements use indexes:
SELECT * FROM tbl_name WHERE key_col LIKE 'Patrick%'; SELECT * FROM tbl_name WHERE key_col LIKE 'Pat%_ck%';
In the first statement, only rows with 'Patrick' <= key_col < 'Patricl' are considered. In the second statement, only rows with 'Pat' <= key_col < 'Pau' are considered.
The following SELECT statements will not use indexes:
SELECT * FROM tbl_name WHERE key_col LIKE '%Patrick%'; SELECT * FROM tbl_name WHERE key_col LIKE other_col;
I've been researching whether or not to utilize the "nofollow" attribute on my user-generated links for about a week now.
Javascript function:function goLink(o){var u = o.innerHTML;document.location = u;return;}
Then I simply made a matching style class to have the link appear as a link:[div class="link" onClick="goLink(this);"]http://www.user-added-link.com[/div]
.link {color: blue;cursor: pointer;text-decoration: underline;}
A few weeks back I was reading a forum thread over at DigitalPoint about a webmaster who had added some handy navigation links to his pages that helped him browse through his content more easily. He was talking about how he had initially added the new navigation links to help him keep up with monitoring the content more easily. However after implementing his new links, he found the total pageviews he was getting on his site had jumped up. Users were finding his new links helpful as well.