Muir Main – 2015/11/22

Had a reasonable ride on Sunday, gpx trace below (in blue)… basically through Blueberry flats and up Muir Main. The red trace is from don’s adventure travel (Hidden alligator lake ride #3), and was part of the logic behind this particular route. (Green traces are other days, some of them later.)

Continue reading “Muir Main – 2015/11/22”

windsurfing in victoria, location notes.

Elk Lake.

Not a bad place to be in a good westerly, if you don’t want to deal with the rough water at Clover Point. Skip it completely in a Northerly though. (It’ll be dead calm. See Island view instead).

I don’t have enough experience with summer conditions to know what the thermal pattern is. Always seemed to be “some” wind during the summer, but rarely anything significant.

Island View.

I’ve had a couple good days at Island view on relatively light North winds. e.g. yesterday Kelp reef was reporting 13/15 knots and at least with the 10m sail I pretty much had my hands full. At least on an Ebb tide, the water is pretty darn flat…

I _have_ seen wind against tide pile up here. And if you can’t go to windward very well, you might have to walk back up the beach to your ride… It hasn’t been an issue for me on the long board, but I’ve seen more experienced riders on the wider boards walking their gear farther down the beach than I’d like to do at the end of a long day.

tom_at_islandviewLousy webcam shot at IslandView… but the best of the bunch.

Clover Point.

Every time I’ve been down there when there is any wind, there’s usually a pretty big swell. So I tend to avoid it. That means I don’t really have anywhere to go on a South Easter though. Cadboro Bay and Willows beach become options, but the swell is just as bad, and the wind can be fluky.

Links. is pretty good, I just have trouble finding info on it. . Hhmm, looks like the ‘sailing guide’ under the ‘wiki’ menu item is the links for the location pages… but it is hit and miss. Some are great, others are basically blank… and having three pages for Cook St, Clover Point, and Ross Bay (all within 1/2 mile) doesn’t help.

Going to windward.

Going to windward. Was thinking about this yesterday. My background is sailboats, with quite a bit of racing. In sailboats it is all about speed to windward. Anyone can go fast off the wind, but the guys who can make distance going to windward will consistently kick everyone else in racing. Windsurfing might actually be a good training environment as the feedback is so obvious and immediate. Of course, slogging to windward on a windsurfer is comparatively boring to shooting off on a reach. But the obvious points are the same as for a 50 foot yacht. Waves slow you down, and you do want to keep your speed up. So reach off a bit to get your speed back, then put the nose back up… that’s really all there is to it. It’s just much more obvious on a lightweight sailboard than it was on a 4000 pound thunderbird.

It seems the old style longboards probably handle a bit of chop better than the modern wide boards. Only makes sense… the narrow board cuts through a smaller part of the wave and the longer length reduces the pitch change. Seems to me like shorter wide boards would be fine on a big swell, but are going to suffer in the short chop you get in 10-20 mph winds… but I’ve never ridden one (yet).


more wordpress brute forcing…

(originally written april 9th.)

OK. so the wordpress password guessing game changed this morning. We started getting hit fast and hard. I’ve seen everything from 180 guesses in 23 seconds to 2000 in 120 seconds. And then there are (still?) the stealth scanners… 43 guesses in 10 hours.

I don’t see any easy fixes. I’m not even sure how many IPs we are seeing in different log files, which would give us an idea of the total attacking population. TODO: Guess I better produce those numbers. Not much point in blocking IPs if they never come back, nor if they aren’t seen on other servers.

Anyhow, having a cron job periodically scan the access logs for bad behaviour isn’t really going to cut it. Looks like I may need to modify weblogger to log some subset of requests to a single file that another tool(s) can monitor. fail2ban is well placed/designed to handle the immediate block… e.g. truncate that run of 200 guesses that was only in flight for 23 seconds. But we currently don’t have any method of sustaining a block on port 80. Perhaps we need to roll that out… If we added an element of persistent blocking to fail2ban that would do the trick nicely… but of course we need to figure out a way to share the info (dns zone transfer?) and speed up the updates.

Not like I have the time or desire to write such a system just now. But it would solve some headaches for us. I wonder how hard it would be to setup something like this as a sniffer… That would be more functional, as you could see bad stuff in input requests that way… instead of just the log of pages accessed.

What would we need? Seems to me the “agents” on the webservers would need to both receive and send updates to the central node. The central node would need to keep a list of all the agents listening (subscriptions). The agents need to be able to start up, send in reports of suspicious activity and get a list of blocked IP/service pairs back. They need to be able to install that list of blocks… hhmm, that implies short-term (local) blocks, and persistent (shared) blocks. I like it. Of course, I need to spend lots more time on fail2ban looking for things like that stealth threat. I _know_ those are out there in the pop world.

hhmm, I’m wondering if it is time for another syslog channel, log all the suspicious stuff there? Food for thought, time for a run.


wordpress brute forcing :(

Looks like a fair number of wordpress installations are being brute-forced… SUCCESSFULLY :(

I guess the fix is going to have to be to automate the installation of something like the Limit Login Attempts plugin … but I believe we also need a script to reset admin passwords, certainly for compromised accounts both things need to be done.

Breaking in is no big deal for system administrators with database access, but to be able to change the admin password we need to know what format wordpress stores it as… looks like wordpress can use more than one format, and a straight md5 hash is acceptable… let’s test it!

yes, it does work… but you have to be careful not to include the \n in your hash… e.g. use the -n parameter to echo (no newline).

[root@eleven /var/lib/mysql/tbrowndb]# echo -n 5fHGZX | md5sum
1a5225f15301983e3b962e76a5c2163b  –

mysql -e “update wp_users set user_pass=’1a5225f15301983e3b962e76a5c2163b’ where user_login=’admin'” tbrowndb

That works (sets the admin password to 5fHGZX) … not sure what the default $P$ prefix indicates for a format, should read the code but too busy/lazy. OK, I have written a script to encapsulate this… wp.set.adminpw

So, that leaves figuring out what changes are required to install the limit login attempts plugin… but I don’t _have_ to have that for now… just to scale things, and to fix the installer…