ColdFusion Job Openings - Alive and Well
Yes it's true! CF Webtools is looking yet again for qualified advanced developers. I know seeing my plaintive cry for developers might get old for long time readers. I would beg the courts indulgence and only ask that you remember my constant nagging for you to send me your resume when the lean years come (as they almost always do). Remember, our jobs are full time, telecommute with competitive salary and benefits. We have a talented engaging staff, interesting work and a chance to stretch your skill set. If you are an advanced or aspiring advanced ColdFusion programmer we might be a great fit for you! Here is the rest of the Muse' blurb:
Here's what we are looking for. If you:
- Take ownership of a problem.
- Think around all angles of a problem for all possible solutions
- Love the tech community as a place to engage and learn.
- Have evolved skills in an eclectic mix of technologies and like to learn new ones.
- Can explain technical concepts to non-technical folks.
- Know how to honor non-technical people for their own skills and expertise.
- Can laugh, chortle, guffaw and otherwise split a gut with a group of insanely funny people - without the need to put anyone down.
- Are anxious to be a part of a close knit team who encourages and believes in you.
Frequently Asked Questions
- Do you allow telecommuting? Yes all our development positions are full-time remote positions.
- What sort of dev environment can I expect? We are en eclipse shop and rely on SVN, Jenkins, and an agile like approach to development. Having said that, as an outsource development company we frequently integrate with external teams. That means you can't always predict everything about the approach for the project you are working on.
- What Industries are you working in? We have sites we develop and maintain in the Financial sector (stocks, options, commodities, retirement planning and management etc.), Insurance, Medical, Pharmaceutical, retail sales, real estate, etc. We have a very broad client list.
- Will I get to meet the Muse? Yes of course... you'll be sick of me inside of two weeks.
- Do you use frameworks? Yes - all of them all the way back to Fusebox 2. We work on new projects in common frameworks like FW/1 or DI/1, but we also support a host of legacy applications done on custom frameworks or with no framework at all.
As stated above, our positions are full-time remote telecommute. On rare occasions they might require some travel. We pay a competitive salary and benefits. CF Webtools maintains sites on virtually all ColdFusion and Database platforms. Our work is challenging, invigorating, sometimes poke-your-eyes-out frustrating, but never boring. Our development group is full of witty, interesting and extremely talented developers. It's a true mentoring community. If that sounds like a place you would like to work (and you meet our high skill-set standards) send your resume to jobs@cfwebtools.com - or contact the Muse directly if you like. Tweet me @cfwebtools or use the "Ask a Muse" link on this blog (I'm easy to find). You can also call 402 408 3733 and ask for Mark or Jason - we'll be thrilled to speak with you about our opportunity. The official job posting may be found on our corporate site at the Job Openings page.
Always Check on the Last Thing You Changed
If you can sing this with a sort of smarmy accent like Eric Idle it makes it really pop to the tune of "Always Look on the Bright Side of Life".
Your server's feeling bad,
It can really Make you mad,
JRUN maxed can make you swear and Curse,
When your chewing CFGristle,
Don't Grumble, Give a Whistle
And this will help things turn out for the best
Always check on the last thing you changed
(whistle cheerfully here)
Always check on the last thing you changed.
If CF's being Rotten,
There's something you've forgotten
And that's to check the freaking SVN,
For anything that's newish
Roll it back, don't be bluish
Just pucker up and whistle, that's the thing
Always check on the last thing you changed
(whistle cheerfully here)
Always check on the last thing you changed.
...I'm not sure what was in that mimosa...
Protecting the CFIDE directory in IIS
Yesterday I had a server with IIS and a few hundred sites on it. Some, though not all, of the sites had an unprotected CFIDE directory mapped. So my task was to protect these directories by denying all IPs from access except a specific IP range. Before I describe the task and my trick let me remind you that this is not time to tout Linux or Apache or bash Microsoft in the comments. The muse welcomes comments but enjoys variety. We all know about Apache and its manifest benefits. We don't need you to remind us in spite of your excellent credentials and biting wit. IIS is fine platform with many strong points too and there are folks who need this information. They should not feel like they are sneaking into the adult section of the video store to get it. Now back to the Muse' usual good humor. Here's the scoop....
Read MoreThat Pesky CFIDE Directory
If you are CF community connected (and if not why not?) you know about the latest "sub-zero" exploit to ColdFusion that once again targets the Administrator or adminapi directory under the CFIDE directory. It leverages tags that work with files from within these directories to place code on your server which can then be leveraged to do other things. Basically it can function as a hostile takeover of your server. See this entry titled 0-Day Exploit for ColdFusion by the awesome folks at Edge web hosting for more information. It will point you to the Adobe Docs. The exploit targets CF 9 and 8 if I'm reading the source correctly.
The lockdown guide will give you a few dozen steps some of which will have you pulling out your hair unless you have carefully built your server. But the main "fix" for this exploit is fairly simple. Do not allow arbitrary access to the CFIDE/Administrator and CFIDE/adminapi folders from the web. This seems to be pretty head scratchingly obvious but you'd be surprised how many folks say "But don't you need a password to get into the administrator?". Yes, and you need a key to get into your house too, but an "exploit" is rather like a brick through the window. To really secure your house you need a security system, good locks, good lighting, and a Rottweiler the size of a pony.
Why is it there in the first place?
This is a question I get sometimes. "I don't remember adding that virtual directory. How did it get there?" No you did not fugue off while adding web sites - unless you see one for a Ukrainian tether ball team or something - then probably yes you did fugue off. The real story is that when you install ColdFusion using selecting the "configure all websites" option during the install the CFIDE is mapped on all the sites on your web server as a physical (for the default site) or virtual (for everything else) directory. That's how it seems to "show up" everywhere. In addition the "connector" scripts - the ones you run to "remove all" and "add all" will add it as well. If you are like me you configure each site separately outside of the CF ecosystem. Then you join it to the ColdFusion engine using wsconfig. My servers use the multi-server config and I use the built in web-server (at ports 830X) to admin them from inside the network. When a new site is needed I add it in IIS or apache, then I use wsconfig to connect it to the ColdFusion instance I want. Yes it's extra steps and yes it requires more knowledge, but it's the way I like it. And I'm worth it. Doing it this way does not add the CFIDE directory by default - which is why if I need the scripts directory I use an alias or virtual and alter the setting within the admin.
But what I notice from time to time is that there actually is a CFIDE directory that shows up on some of my sites. How can this be? I've been so careful. Here's what happens. A team member - a developer - is assigned to a site for the first time. Perhaps this is the first site they have set up on their local environment, or perhaps they are sys admin challenged and don't know how to create an alias or virtual directory. For whatever reason the CFIDE physical directory is installed and is living in the root directory of the site. Then at some point the developer remembers (through the prodding of his project manager) that he needs to do regular updates of our subversion repository as a part of his task list. Suddenly (with apologies to Emeril if he's still alive and has not exploded) BAM! the CFIDE directory itself is now part of the source code. Our Jenkins CI server ignores this directory and does not deploy it to either staging or production but usually the initial site setup is not done by Jenkins. So one thing leads to another and the directory is deployed to staging (small yikes) or production (big yikes and a shudder).
Of course this is bad in more than one way. For one thing this directory has the vulnerabilities in question in the form of CF Scripts. For another it is likely not being used to admin the server - which means that updates in the form of hot fixes and security patches will never make it into this code. It might also end up being the wrong version of admin as the site code is transitioned from version to version. I'm not sure if that last is bad or good - but it is another thing to worry about.
In conclusion get out there and secure those directories (and other things). Let's make sure we are on top of this before it get's out of hand. :)
Sites to Watch
Aggregators
RSS
