I had a client recently that had their browsers hijacked. Everything they typed in the browser ended up redirecting them to some test_s.php file at “www.fes.sk”.  (Don’t open that, or you might end up with a virus!  I just wanted people to find this in case it might help clean this bug off!)

Not sure what this virus was, but it disable Microsoft Security Essentials and blocked even MalwareBytes and SuperAntispyware from detecting it.  I couldn’t find it and I was almost to the point of just reloading the computer because in this case it would have been faster to just copy the docs of and reload Windows XP.

I thought, let’s search that URL?  This was key, because it brought up some forum posts and someone mentioned HitMan PRO.  www.surfright.nl/en/hitmanpro

Never heard of this program, but thought since it had a 30 day trial I’d give it a quick shot.  I was very impressed, it scanned in litterally a few minutes. (like 2 or 3!)  It found a “Rootkit”, nothing more than that though, in a file called “ipsec.sys” in the system32/drivers directory.  Then it said, “Reboot to clean.” 

My client was very pleased to see it reboot, do another very quick scan, and he was able to browse the web again.

Hitman Pro was free for 30 days, but you had to activate it.  I believe it has a subscription price of just under $30/year for 3 PC’s. (as of 02/09/2010)  That’s not too bad I think.  Keep in mind though, this looks like a “remover” , not a real-time antivirus protection program.  You’ll still want Norton, NOD32, MSSE, whatever you like, for that.

Now, I have to ask… because all my clients are starting to ask… why do they need this when they already have MSSE, Norton, etc?  Why doesn’t the AV real-time protection actually protect them in the first place?  Well, I can’t answer that one.  But it drives me nuts, and it make it worthless to pay for a subscription to Norton or McAfee (or any other) when all they do is get subverted and taken down, even if it’s the clients fault.  Because of this I will only suggest a free product for now, at least until I start seeing the “for pay” products doing what they were paid to do.  And if I see a Rootkit or Trojan that I can’t easily clean off, I’ll recommend HitmanPro for now.  If that can quickly remove bugs for my clients every time I use it, I’ll tell them (my clients) to use it and even purchase it as a quick cleaning tool in addition to MSSE.

I have Windows 7 Ultimate x64, but I think this might be problem in any version. I keep having issues with MsMpEng.exe hogging the cpu.  Basically, using a large amount of resources, like 100%!  It’s eating the CPU time and a lot of memory.  The system will work just fine, even after running for hours, when suddenly the system slows to a crawl, almost to the point I have to reset the system.  I finally narrowed the culprit to MsMpEng.exe, the scanner for MSSE (Microsoft Security Essentials).

Good news is, I think the cpu hog problem is solved! I found a link on a Google search about adding exclusions, which I suspected would be a problem for things like my backup programs.  I added Crashplan and Syncback programs already, but what I found in that Google search was that you need to add the MSSE directories in C:\ProgramData to the exclusion list.  WHAT!!???  Are you kidding me?  MSSE doesn’t already exclude itself?  Come on MS!!  I really like MSSE,  but that’s pretty stupid.

I went ahead and added these to MSSE exclusions:

C:\ProgramData\Microsoft\Microsoft Antimalware

C:\ProgramData\Microsoft\Microsoft Security Essentials

C:\Program Files\Microsoft Security Essentials

Now, for a couple days, I have had no more issues!!!  We’ll see in a week if it really fixes it.  That’s an easy fix, but completely annoying!  I still like MSSE regardless.  It’s not perfect, but I’d rather have it than anything else.

I am curious to know if anyone else found this fix to work?

Note:  I do recommend people run a manual scan with MalwareBytes and SuperAntispyware once in a while, along with the real time scanner in MSSE.  MSSE didn’t catch a recent trojan at one of my clients, same one was blocking MalwareBytes too.  Only SuperAntispyware cleaned the system properly.

EDIT 02/10/2010:

It’s been about a week and a half, still working fine! It appears that this fixed the problem!

This is just another one of those things that didn’t make any sense and only partially does now. At least NOW I know there is more at play here than the simple solutions in Samba using create mask and create directory mask. In Linux, that’s how I would get around the issues of Windows directory permissions running on a Linux SMB share.

Now, I am learning to do things the OpenSolaris way. I am loving OpenSolaris and ZFS! However, coming from a Linux and Windows “way of life”, there are some differences that just aren’t clear. What kills me is, I try the RTFM thing, and somehow completely miss that one little thing that makes it all work. Off topic, but an example, coming from Linux, I would just type “su” and get root access. In OpenSolaris, that won’t work. Neither will “pfexec su”, nor “sudo su”. Then one day, after dealing with it for a week or so, I stumble upon a post where someone in an unrelated sample script typed “pfexec su – root”. There ya go! Argh!

Anyway, back on the ZFS/CIFS/ACL thing. It was driving me nuts that I couldn’t figure it out. I wanted a folder with this setup:
/pool/sharefs – owner:greg – group:domusers
greg and domusers should have full control and all folders under “sharefs” should inherit that.

So under linux/samba, that’s where I would do like “create mask = 770″ or simlar, and “force create group = domusers”. Something like that, can’t remember exactly. made it simple actually. It always wrote files with the right perms and ownership and other people in that group could read/write just fine.

Problem is, you can’t get very specific about who get’s what, where, and you can’t use more than one group. Well, sure enough, there’s a thing called “ACL” that handles that stuff now. It’s been around for a while now, but I never even heard of it until I started using OpenSolaris. I like how it seems to be more compatible with the way Windows handles ACL’s. What I don’t like is, it’s confusing. I get the NTFS/Share perms in Windows, been doing that a long time now. The CIFS/ZFS ACL thing kind of makes sense, and it will “click” at some point the more I use it.

After spending hours on this, I reached a point where I had to figure it out. Here’s what I did.

On the ZFS file system, create it normally for SMB access. Then I changed some properties for aclinherit and aclmode. Change those to “passthrough”:
zfs set -o aclinherit=passthrough -o aclmode=passthrough pool/sharefs

Then chmod/chown. OH! That’s another thing. You need to use /bin/chmod and /bin/ls! Not just type: chmod … That wont work. In OpenSolaris the default path points to /usr/gnu/bin/chmod, which doesn’t have the “A” or “V” options to set/view ACL’s. That was another thing that DROVE ME CRAZY!!! I read the man pages and manuals and docs online and I didn’t catch anything that said, “Hey, there are different versions of chmod and ls here!” I can’t believe the time wasting here! Back to the point, do this to put your own default perms on:

/bin/chmod 2774 /pool/sharefs
(I actually am not positive that is needed, but I think it set group as inheritable)

/bin/chmod -R A- /pool/sharefs
(that will wipe out the current perms)

/bin/chmod -R A=owner@:full_set:fd:allow /pool/sharefs
(resets perms with only that acl)

/bin/chmod -R A+group@:full_set:fd:allow /pool/sharefs
(that appends the group perms, full control)

/bin/chmod -R A+everyone@:read_set:fd:allow /pool/sharefs
(above appends everyone read access)

In all the above that will preset INHERITABLE permissions for the subdirectories.  Notice above there is one with “A=” on it?  That will reset the perms and set only that perm.  So I guess you may not even need the previous line for “A-” to reset.  (I am just learning here ya know!)

It looks as if that makes a little sense now.  You can view the current ACL’s like so:  ”/bin/ls -V /pool/sharefs”

In my case, I might want to add another user or group:

/bin/chmod -R A+user:stacy:full_set:fd:allow /pool/sharefs
/bin/chmod -R A+group:othergroup:full_set:fd:allow /pool/sharefs
/bin/chmod -R A+group:yetanothergroup:read_set:fd:allow /pool/sharefs

So with this setup I can now open the share on the server and create a file or folder with inherited permissions.  It does, however, save my username as a new owner, so keep that in mind.  But if the group stays in there with “domusers” as full read/write access, I am happy.

Well, now I get it just a little and it makes more sense compared to Windows ACL’s.  I didn’t go over any share specifics and authentication issues, this was just ACL’s!  I still have to RTFM my way around that for a while.  Next project, join OpenSolaris to a Windows domain.  (Which, BTW, does not work in NT Domain style connections, you have to use Active Directory.)

Before I get going, please comment on this. I am wanting more information, so please share.

I was wondering, though, why use a vpn to tunnel a terminal server connection? Isn’t terminal server encrypted already? Here’s a couple things that I *think* are important:

1. The vpn connection is no more secure than the terminal server. Why, if a trogan program runs on your remote client, what difference is it that you have a vpn to cover your terminal server? The attacker has access to the remote client, they now can get into your network with either system.
2. The vpn connection opens up a whole mess of insecurity if your remote client is compromised. (of course, it does with terminal server as well)
3. The data is never on the client if you use a terminal server, but with vpn, you open up your network. OUCH!
4. This is the one that really get’s me… with a vpn, if your remote client gets a nasty virus, your whole corporate network will probably now have it too once that vpn connection is opened. Not so with terminal server.
5. At least with terminal server, you can totally restrict apps and printing and such, so nothing is ever on the client, it only receives the screen shot of the server.
6. Brute forcing usernames and passwords are vulnerable on both.
7. If you were really worried about security… YOU WOULDNT RUN ANYTHING ON THE INTERNET! You wouldnt run IIS, Email, or anything else that communicates on the internet, expecially remote access services!

So from where I sit, I can’t understand how using vpn to tunnel terminal server will make my remote access more secure, in fact, possibly less secure. Please tell me if I am missing something though.

Thanks.

Greg

———————————–
Edit: 3/28/05

I have been talking about this issue with friends on forums, and I wanted to share more thoughts based on some of my posts. And just so you keep this in mind, I am basing these thoughts in the context of a small business with less than 50 users which might not even have an IT staff. A company like this typically will not spend $10-$15 thousand dollars on a VPN solution, leaving us with only the built in Microsoft technologies (or linux).

— from a post on 3/21/05 —

I dont think that vpn is less secure really, its got a great security model. What I think is less secure, is using vpn with TS. I dont believe it offers any additional protection. Why encrypt an encrypted connection? Why give access to the whole network and all the servers, if you only want them to access a few apps on 1 server? And why I think it’s less secure to run it this way? That is because the reason you run Terminal Server is to allow the user access to certain apps that would not otherwise run on a vpn, AND to isolate the use of those apps and their data. You cant isolate the processing of data and its transmissions on a vpn. The vpn essentially extends the internal network to a remote system over a public network, right? Well a TS client does not do that. It only extends the keyboard, mouse and graphics. So the data never leaves the network, it cant even be printed remotely or cut&pasted on the remote client (if you set that up of course).

So it’s not that I think vpn is less secure, implemented properly, it’s great, but only for the right purposes. For my systems, vpn wont work. I have to run apps that just wont run over a vpn, or they will but be so damn slow it just isnt practical. I installed vpn originally aboot 5 years ago at my largest client. We ran into many hurdles running our main apps. I basically determined that unless you have at least a 10 Mbit connection, dont bother. That’s not to say that apps cant work on vpn, it just depends on if they were written for it for one thing, and if not, how their execution and data is transfered. I have ran several apps that are so called ‘network’ apps, and all they do is put on a short cut to a large exe that is downloaded locally and then executed. That just wont work on vpn. It’s WAYYY too slow! Try running a 100mb + ms access mdb from remote vpn client, that then connects to a 3Gb + sql server db. Even on the fastest broadband connections, it just isnt feasible. Terminal Server solves that problem.

Now, also keep in mind, mostly why I have the ts’s is to do remote admin. Some companies have this setup: 2 servers, both are AD servers. One runs Exchange and IIS, and has MS ISA firewall on the server to vpn into and proxy out. (I didnt set that up, nor do I maintain it, I would have set it up way differently) The other server is behind that firewall and runs only a sql server internally. In this scenario, they didnt setup a dedicated firewall, and consequently are vulnerable from other sources that would put the domain controller at risk. This is because, it’s way more likely that IF an attempt were to be made to crack that server, it would be most open to attack on the IIS services, or Exchange. Once in, the firewall is useless. So… why put in the vpn here? There are so many WAY more insecure elements involved. This is why I mention in the blog… “if you’re worried about security, dont get online.” I mean, obviously your not THAT worried, or you wouldnt setup the systems that way. And if you’re not THAT worried, why use the VPN?

If I were to make the network more secure for remote admin I think I’d have to do this: Run a TS in a DMZ with admin rights to TS denied. (have to be a restricted use user acct.) Then, from the TS session, open another TS session to the specific server you want to administer. Your firewall can be set to allow communication on TS traffic to and from the dmz computer only. This way, no data is ever really sent to the remote pc, and the remote pc has not direct access to any internal system, but does have access to *view* information.

The insecurity I see, with both TS or VPN, is the client use and it’s vulnerabilities. They both suffer from the fact that IF some trojan is somehow executed and allows an unauth user remote control of the pc, that user could see all the data your company user can see. The advantage to TS in this situation, is that at least that ‘hacker’ would not have direct access to the whole network right from start. They could obviously run a keylogger and then log into that TS themselves, or from the remote pc. Same with the vpn. In my situation, the remote users use their own systems to remote into the company. They wont spend the money, nor do they have the administrative capability to maintain stringent policies and systems.

— Posted from 3/23/05 —

I found out that TS can be brute force attacked! (via password crack) (OH NO! VPN IS NEEDED!!) BUT!!!! Then I did a little more research and discovered that with my setup at my different clients, it aint gonna happen.

There is a program out there that can “dictionary attack” a Terminal Server. Not Brute Force it. There’s a difference. Dictionary attack uses a dictionary of words to test, brute force checks every letter combinatoin. That program must rely on the fact that the local “administrator” account always has local accees to the TS. And since it uses only a dictionary attack, dont use words for a password, it wont crack it. And since it relies on the admin account, rename the administrator to something else, problem solved.

Use of an 8 or more character password is also all that is needed to deter an actual brute force attack. Along with account lockout policies when logons fail, you can pretty much bet that you wont get brute force cracked. I read somewhere, that if you use 12 character passwords, and if they are only lower and uppercase, there are almost 400 BILLION BILLION combinations. And even if you could do 1 million attempts per second, it would take millions of years to crack! I am sure someone good at math can figure the details out. And this is all for just the password, YOU NEED A USERNAME TOO! Add lockouts to the mix, and it aint happening! Do some research on brute force cracking and you will see what I mean.

I read a post by someone who cracked a 6 character password with special characters in it, it was cracking something on the local machine (not networked then) and it took a day and a half to do it. Try doing that on network systems, where, if properly setup, will not allow millions of connection attempts like that.

I used to fear the “brute force” thing. Not now. And it’s not that it isnt possible, but properly configured networks/systems simply make it way too long to attempt it using current proccessing technology. that’s why higher bit encrytion is better. It takes way too much time to crack the encrypted key at 128 bits. By the time you did, the key would have changed.

Dictionary attacks are another thing, they can get a crack in minutes. But if you dont use dictionary words as passwords, then you are safe.

this all leads me to the essential wisdom of work, why do things the hard way. A hacker isnt going to try and crack something that is hard to get into, they will try the easiest route. TS and VPN are not easy to get into. They will look into which services provide the most exploits that are available to them. VPN and TS have very little exploits. (at least it was tough finding any) Try looking up exploits on your mail server or web server! I bet they’ll try getting in there way before an attempt on TS.

The amount of time involved to make these kind of attacks are huge. Script Kiddies or whatever arent going to spend that kind of time. The only way someone would do it is for money. And most likely a compititor might want the information and pay for the hacker, but holy cow, is that likely? I dont think so. It would be way easier to do some “social engineering” to infultrate the company and then get into the network.

Simple precautions on the TS are all that is needed. As with any service. 1. dont show the last user logged on. 2. restrict access to only certain users, not domain admins. 3. lockout failed login attempts. 4. long passwords 5. Change the admin name.

So I am still back to my original thought, vpn would not make ts more secure. It would only add more maintenance and head ache. But, if I already had a good vpn solution, I would utilize it.

However, I have a new thought, I guess. VPN, in certain situations that dont have stringent policies and procedures, would make remote access less secure than TS. This is because that encrypted tunnel does not get filtered by a firewall or IDS and a virus or attacker can use that connection to directly affect the entire network. With TS it is at least not possible. That’s why you have to have IT setup the remote computer and on it, restrict user actions as well. This makes VPN unattractive to me.

— and another post on 3/23/05 —

So when adding a vpn to tunnel a TS, what you are saying is, “I have a vpn, I need to tunnel it through another vpn to be more secure.” That’s like saying, “I need 2 firewalls to double up on the packet filtering.”

The only thing I think a vpn will do, and only if I had a nice hardware appliance type one, is give me device authentication. If I use MS software based vpn, especially using pptp protocol, I am no better off. I would still need to authenticate in either system (ts or vpn) and the hardware solution probably allows for IP or other device authentication. Also, I think that to really be secure you would need to use a certificate or something of that sort to authenticate. TS cant do that, so I would see that as an advantage in vpn.

If I put in a vpn, I open my whole network up. And with no real IT staff to monitor it or the client machine, that opens a whole mess of problems. At least with TS I prevent any openning of the network, only that port on that server. (no data is transfered, just user IO)

—————————————-

In my situations, as in small businesses remote administration, I do believe VPN is openning a hole in the network and making it a little less secure than to provide straight access to Terminal Services. So far I have not seen any evidence to tell me otherwise, but if anyone out there can give me specific reasons to give me some evidence, please do.