Aug 03, 2009 07:03 PM
I consider myself fairly good at regular expressions, which is a way to match specific patterns within a string of text; however, today, I learned a new little nugget of information regarding pattern matching.
We needed to match any filename that ended in html or php, but didn’t start with the word “form”. The regex syntax that I learned today was the Zero-width negative lookahead assertion which follows the form (?!pattern). This matches only if the subexpression denoted by the parenthesis does not match at this position on the right. Therefore (?!form) would match as long as form wasn’t at the specified position.
The whole regular expression was: ^(?!form).*\.(php|html)$
The first carot ^ denotes the start of the string, then our negative lookahead makes sure it doesn’t start with the word “form”. After that the dot star matches anything until it finds a period (the backslash or escape character makes it look for a period instead of it’s default “any character”. Then it looks for php or html (the pipe or | represents the boolean OR), and finally the $ indicates the end of the string. It does a lot in just a few characters.
Incidentally, (?=pattern) is a zero-width positive lookahead, which means that it must match that pattern at the position indicated in the overall regular expression. (?!pattern) is the zero-width negative lookahead. (?<=pattern) is a zero-width positive lookbehind assertion, and (? pattern) is a nonbacktracking subexpression or so called greedy subexpression. So far, I haven’t needed to make things specifically greedy, usually it’s the opposite, I’m forcing it to not be greedy. What that means is that it’ll match the largest part of the string that it can; For example, if you used the regex /*.\.txt/ and the string was some.txt.txt, a greedy expression would return “some.txt.txt”, while an ungreedy expression would return “some.txt”. It’s a minor detail that can really throw you off on occasion.
Aug 03, 2009 07:01 PM
My secure and messages log files were getting really big, and after analyzing them to see if there was a reason, I decided to clear them out.
To do so, I first typed: cat > messages, then typed a couple of blank lines, and hit control-c to quit. I did the same for the secure log file. This cleared the file, but no new messages were being added to the logs. After kicking myself for being stupid, I searched around and found two important things.
First, it’s easier to clear a file by simply typing “> filename”, and second, the syslog daemon is reponsible for writing to those files. Restarting it restores its ability to write to the file. I restarted it by going to /etc/init.d and running ./syslogd restart
Aug 03, 2009 06:59 PM
Over the past week, there have been 10 separate attempts to do a brute force attack on my server. Each day, I’d check my logs and manually ban the IP address responsible for the attempted crack. They’ve been attempting to break in through SSH and FTP.
While they didn’t succeed in breaking in, they did succeed in slowing down the server to the point that it was unresponsive for a few minutes during each attack.
Fortunately, IPTables has a cool feature that checks for recent connections. You tell it how many connection attempts from a particular IP address for a length of time, and if that amount succeeds, that IP address is banned for the specified amount of time.
It consists of 2 easy commands. The first one sets up the recent table:
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
In this case, it’s looking for connections on port 22 (SSH). Do the same for any other port that you want to limit like this such as your ftp ports.
The next command tells it to drop packets that exceed your specifications:
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 -j DROP
This tells iptables to drop the 3rd connection from a particular IP address if it happens within 60 seconds of the previous 2. You’ll probably want to set it a little harsher than that such as 3-5 minutes, or if you really want to be strict, set it for an hour or more. The downside is that the longer the timeframe, the greater chance that a legitimate person will get blocked because they mistyped their password a couple of times.
I’ve found that a range of 3-5 minutes is enough. My logs show a couple of attempts, 5 minutes later, a couple more, 5 minutes later a couple more. The rest are just dropped. My server doesn’t show down in the slightest with this kind of load, and I believe it’ll take the crackers a few hundred years to break a password at 2 attempts every 3-5 minutes.
brute force | server security | ssh | ftp
Aug 03, 2009 06:56 PM
At home, I run Windows XP x64, and I’ve had a tough time finding an antivirus program that will work on this operating system. I waited a year for McAfee or Symantec to come out with a version for this OS, but as of yet, neither of them had one that I could find on their unuser-friendly websites.
After searching around, I found Avast, which is free for non-commercial home use. I installed it and ran a full scan, and it found a couple of dormant virus files. It has a real-time scanner, which hasn’t noticably affected the speed of my system (something I can’t say for either McAffee or Symantec).
What are your thoughts of Avast and antivirus software in general? I haven’t been too thrilled with McAfee, as their update process has always been a bit unstable and problematic, and all of their products except for VirusScan has been a joke. Symantec has been pretty good to me, up until I got an OS that they don’t seem to support.
At any rate, until Windows can design a user-rights system that’s as good as Linux, we’re stuck with Antivirus software, and Avast is the only thing I’ve found to work on the 64 bit version of XP. It’s free, which is nice, but only time will tell if it actually prevents virus infections.
windows xp | x64 | antivirus
Aug 03, 2009 06:54 PM
Lately, discussions seem to rage about whether to lay out your web pages using tables or divs. One side of the coin suggests all HTML related to laying out a page should use CSS, and thus the use of divs and spans to achieve this. It’s reported to be faster to render divs than tables because the browser can’t render a table until it reads the closing table tag. Using divs also typically makes the webpage’s file size smaller, which allows it to download faster, saves room on your hard drive, and it is rumored that search engines like div style pages better perhaps because of keyword density issues. If the overall html is less then the percentage of content on a page would be more, and some say that this is a benefit when dealing with search engine spiders.
On the practical side though, using divs and CSS to do your entire layout can be kludgy at best. Sure it’s fine for really simple layouts, but most layouts quickly move beyond this simplistic approach. Most of today’s browsers render CSS a little different, which sometimes results in the need for browser specific CSS kludges. Also, with a tableless layout, you often have to resort to odd hacks to make things work that people took for granted with tables such as the so-called faux columns and sliding door hacks. Complicate this with browser differences, and it can quickly end up looking like a nice bowl of spaghetti.
In fairness, CSS layouts can do things that tables cannot. Floating elements are really cool, but come with their own set of problems; For example, try to float 9 different elements with varying heights so that it ends up a 3×3 grid. Tables did this without a second thought. Without tables, you have to add an invisible span so that the next “row” actually drops all the way without getting hung up on a shorter element. Height parameters, in this case, just make a mess because they tend to leave way too much whitespace.
In theory, CSS should be used for all layouts. In practice, it’s sometimes way more of a pain than it should be.
Let me give you another example. I had a set of links sitting next to each other horizontally in a menu bar. I wanted a small form that consisted of a username and password box to sit on that same menu bar so that it all looked nice and level. For 3 hours, I played with tons of different ways to do with CSS, but ran into problem after problem. I tried floating left and right, but it wouldn’t line up with the menu links. I tried using various other html elements like putting both the links and the form into their own divs and using the divs padding, margin, positioning, etc to make them line up, but Firefox and Internet Explorer kept putting the two in different positions so making it look right in IE made Firefox screw up, etc. I could have put conditional CSS code for IE, but I’m stubborn and wanted to make it work without resorting to kludgy CSS. Eventually, I gave up and made a 2 cell table with 1 row and set the form to 0 pixel margin and padding and it worked fine in both browsers. The table solution took me all of 5 minutes. The CSS solution was not resolved after 2-3 hours.
I agree with the purists that all layouts should be rendered using CSS, but CSS isn’t practical for all layout situations yet. Tables, while seemingly archaic, are handled far closer to the same on Firefox and IE, which makes them more appealing in the cases where CSS falls short.
For the time being, I’m going to continue to learn new ways to deal with CSS shortcomings, but I’m not ready to abandon my old friend, the HTML table.
divs | tables | formatting | layouts
Visit www.Vauntium.com for more information.
