I know this has been done many times, in many different ways. One thing that I believe is always consistent, is that in order to do so, you must pass a plain text password. Attached is an executable that will allow you to avoid just that.

I know this could cause some "Well if you are worried about plain test in a file, then you have larger concerns" flame fest. Just know that this is not an option in my world. There can never be any plain text passwords in any flat file on out network (Well none that we own )

Description:

ProxyBan.exe is called from your EventHandlers.vbs whenever some criteria is met which warrants a ban. It takes a simple command syntax, which then calls the "Interop.hMailServer.dll" which is included in your installation. The offending IP address is now banned for 1 day.

In order to avoid passing plain text from script, ProxyBan.exe is designed to use a "secret". If the secret is correct, it will accept a ban request, and on-the-fly decrypt your hmailserver password and ban the IP that you passed.

e.g. a command line syntax for a ban would be: "C:\Program Files (x86)\hMailServer\Bin\ProxyBan.exe" -secret=mySecret 1.1.1.1

Edit your hMailServer.INI file with the following ([Security]should already be there):

[Security]
secretWord=mySecret

Note: mySecret should be whatever you want your secret word to be

You now need to setup you encrypted password. In order to do this, you will need to key in your real Hmailserver's Administrator password. This is a one time thing so that it can proxy the password moving forward

After you do this, a new line will be created in your hMailServer.INI:
proxyPass=<obscurepassword>

That's it. You are now sending your password to Hmailserver without having to hard code your password in plain text.

So here's how i use it:

I use this with RvdH's fantastic OnClientConnect(oClient) spamrats checker. If you don't know what that is, look here. It allows you to ban a known spammer before they even pass data. Of course, you can call this ban proxy for whatever you want.

I came to realize that hard coding just a 1 day ban will be a little too limited for most peoples standards. I added the ability to accept a day parameter as well. If nothing is passed, it will default to 1 day.

Thanks. For me, the purpose is singular. I needed to be able to ban without having a password in plain text. I also do not like the scripting dependencies on the front end of the server. e.g. script hangs, and thread locks. This is where the interop comes in for me 2 full. I am much more proficient in c#, and I can control script failure much easier by just passing the task off to an executable that does the job for me. Failure or success does not harm hmail.

Being that it is using the interop, its very easily adaptable to do any other function by just adding command line variables(I make quite a few other calls to interop for other reasons as well). The dilema that I ran into is that i'm not entirely sure that I could just pass auth, and then hand it back to vbs to continue. If you are interested, i can strip down the executable just to handle auth and you can try it out.

Anyway, feel free to give that a try. I'm still trying to figure out if this would work. I was assuming that if you pass auth to hmail, that you would have to do it in the same session that you are calling a function from. If not, then this would be a great addition to any hardened server (IMO).

I dont think you will have any luck. I have made several attempts, and it didnt work (As expected). The only way i think this will work is if the VB script were to open a socket and receive a buffer value.

Hmm. I dabbled a little. I was able to create a listener that would accept connections on a port and accept the "secret string". If the secret string is correct, then the listener will return the unencrypted password.

So that works... Problem is that i am beating my head against the wall trying to create ANYTHING vbs based that is capable of connecting, passing a string and receiving the output. I really hate vbs

I'm not entirely sure that its possible without winsock.

Anyway. I can successfully telnet to 127.0.0.1 <port>

and pass mySecret

I receive the correct password back. So if you can create some sort of TCP connection with vbs, i can make this work easy.

Ive been reading with interest but would like to ask a question. Im not doubting anything but would like to know in simple terms:

Whats the difference in having the official password that lets you do anything with Hmailserver (in the INI and and vbs scripts) coded and visible to any user that has been given access to do so
to
having the official 'secret string' that lets you do anything with Hmailserver (in the INI and and vbs scripts) coded and visible to any user that has been given access to do so?

Im seeing "dont open the door with the key under the mat, use the one out the plant pot".

Passwords in plain text are an open invite for brute force and dumb luck. In my experience, i find that most all breaches happen from poor admin decisions which lead to someone simply turning the key that they left in the front door. Not from elaborate, and intelligent hacks at process. Security by obscurity is always my front line of defense.

So my example is this:

plain text:
Box is compromised. Hacker has browse access. "Hacker" looks around for a bit and finds scripts. "Hey, look, the password is in plain text. Lets go take a look."

encoded text:
Box is compromised. Hacker has browse access. "Hacker" looks around a bit and finds scripts. Hacker finds encoded lines seem like passwords. The hacker is now posed with questions and has to choose a direction.
1. Passwords to what?
2. How are they used?
3. What do they give them access too?
4. Syntax?
Is it worth their time?

Don't get me wrong. It's not really hard. But are they willing to spend the time to learn the process, crack the executable, and then do their 0 day damage to your server? In my experience, no. They will move onto the guy the left the keys in the lock.

I've also been known to explain it as such: If someone peels the first layer of an onion in a small room, are you interested in sticking around for them to peel the second layer? Is it worth it?

This is why i'm also a fan of not allowing the script to call for just auth and then to continue on. It makes it much more "insecure", in comparison to passing off just a single function to another application. Granted, not by much. It's just another layer. That said, my curiosity really wants to see if i can pull it off..

Here is my question to this whole thing: Who is going to want to hack an hmail server? I wonder what those responses would look like.

jimimaseye wrote:Ive been reading with interest but would like to ask a question. Im not doubting anything but would like to know in simple terms:

Whats the difference in having the official password that lets you do anything with Hmailserver (in the INI and and vbs scripts) coded and visible to any user that has been given access to do so
to
having the official 'secret string' that lets you do anything with Hmailserver (in the INI and and vbs scripts) coded and visible to any user that has been given access to do so?

Im seeing "dont open the door with the key under the mat, use the one out the plant pot".

Seems a moot point when this is added to "C:\Program Files (x86)\hMailServer\Bin\"

TBH, as well as jimimaseye's, comment of 'What's the difference ...', I'm also wondering WHO would download an .exe, that you can't see the source of, and run it on their system, and whether or not this .exe could be leaking my admin password to someone outside of my control...

insomniac2k2 wrote:Here is my question to this whole thing: Who is going to want to hack an hmail server?

From the outside of my network, many people try, normally more than a dozen attempts each day.
Their success is limited, due to their only access really being username + password, or perhaps a flaw in the phpwebadmin module, and admin access via that.

Someone with access to my administrator password, perhaps gained by a leak caused by an untrustworthy .exe, could easily do stuff to my server / send mail from my server / high jack other programs on my server (webserver, DNS ??).

My logs show that attackers are ever more crafty, just last week I had someone sniffing my SSL cipher protocols from across the world. Most of my attacks are not port 25 SMTP any more (because I block AUTH on port 25), now many more try to gain user credentials via IMAP or POP3 connections, even via ports 993 and 995. My wordpress websites each get about 5 attempts each day to guess my passwords. There are a number of hacking programs freely available on the internet, and stuff like SPARTA can tell what mailserver I run behind my firewall, and even finds this on custom (not standard) ports.

So now the who?
-script kiddies for sure (I get an increase in traffic in northern hemisphere summer holidays)
-Bored wanna-be computer gurus, who don't have full time work, and are looking at showing their skills (and aside from the hacking aspect, this is someone like me I guess)
-Governments of foreign nations (This is very real, and the USA is a foreign government to me, not that they are the only ones)
-Governments of your own country. Many counties including my country (Australia) have legislation that prevents government employees from hacking businesses or homes in their own country, but if you host on an overseas saerver...
-your business opposition (I've seen my business opposition change account details to my domain Registrar account, trying to steal my domains, and therefore my business. Very nearly got away with it. I've changed domain Registrar a couple of times since.)
-criminal gangs / organised crime. Selling drugs on the street corner is so 1990. These days they sell them from web sites, and from email links, and post the product to you (and sometimes keep charging your credit card for repeats, whether you get the repeats or not)
-people with a political agenda. Don't like religion, don't like conservative views on same sex marriage, don't like gay rights, don't like abortions, don't like guns, do like guns, etc (you get the picture)
-SPAMMERS. These people will do anything to upload malware, and send millions of emails to unsuspecting people who will give over their credit card details. These are often related to the organised crime above...Sometimes SPAMMERS will pretend to be nice software engineers offering their trojan horse via some .exe pretending to offer better security, but in reality being part of the problem. Anyone ever used a registry cleaner app and then get LESS spam. I my experience these apps always increase the spam received.

So my question to you is, how do we know that you are NOT trying to compromise our hmailservers?

Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

The exe, as well the ini that it reads can go anywhere. I only put them there for ease of use whilst calling the interop. I shared the exe and what it did to spawn the idea. And to gauge if anyone would have use for it. If you have use for it, ask for the source. If you don't, then don't.

I disagree with it being moot, when its sole function is to ban IP addresses when called (We have talked about expanding this, but maybe its a good reason to limit it to specific calls.). By providing your password in plain text, you are giving everyone that has access to the box full control, as well as anyone that "hacks" the box. When the password is decrypted, it is passed to the interop via com. IMO, that's a hell of a lot more secure than having it sit unencrypted at rest in file and passed in plain text thousands of times a day. I could be wrong i suppose..

In any case, I can just bow out and use it for my purposes.

mattg wrote:

insomniac2k2 wrote:3. What do they give them access too?

Seems a moot point when this is added to "C:\Program Files (x86)\hMailServer\Bin\"

TBH, as well as jimimaseye's, comment of 'What's the difference ...', I'm also wondering WHO would download an .exe, that you can't see the source of, and run it on their system, and whether or not this .exe could be leaking my admin password to someone outside of my control...

insomniac2k2 wrote:Here is my question to this whole thing: Who is going to want to hack an hmail server?

From the outside of my network, many people try, normally more than a dozen attempts each day.
Their success is limited, due to their only access really being username + password, or perhaps a flaw in the phpwebadmin module, and admin access via that.

Someone with access to my administrator password, perhaps gained by a leak caused by an untrustworthy .exe, could easily do stuff to my server / send mail from my server / high jack other programs on my server (webserver, DNS ??).

My logs show that attackers are ever more crafty, just last week I had someone sniffing my SSL cipher protocols from across the world. Most of my attacks are not port 25 SMTP any more (because I block AUTH on port 25), now many more try to gain user credentials via IMAP or POP3 connections, even via ports 993 and 995. My wordpress websites each get about 5 attempts each day to guess my passwords. There are a number of hacking programs freely available on the internet, and stuff like SPARTA can tell what mailserver I run behind my firewall, and even finds this on custom (not standard) ports.

So now the who?
-script kiddies for sure (I get an increase in traffic in northern hemisphere summer holidays)
-Bored wanna-be computer gurus, who don't have full time work, and are looking at showing their skills (and aside from the hacking aspect, this is someone like me I guess)
-Governments of foreign nations (This is very real, and the USA is a foreign government to me, not that they are the only ones)
-Governments of your own country. Many counties including my country (Australia) have legislation that prevents government employees from hacking businesses or homes in their own country, but if you host on an overseas saerver...
-your business opposition (I've seen my business opposition change account details to my domain Registrar account, trying to steal my domains, and therefore my business. Very nearly got away with it. I've changed domain Registrar a couple of times since.)
-criminal gangs / organised crime. Selling drugs on the street corner is so 1990. These days they sell them from web sites, and from email links, and post the product to you (and sometimes keep charging your credit card for repeats, whether you get the repeats or not)
-people with a political agenda. Don't like religion, don't like conservative views on same sex marriage, don't like gay rights, don't like abortions, don't like guns, do like guns, etc (you get the picture)
-SPAMMERS. These people will do anything to upload malware, and send millions of emails to unsuspecting people who will give over their credit card details. These are often related to the organised crime above...Sometimes SPAMMERS will pretend to be nice software engineers offering their trojan horse via some .exe pretending to offer better security, but in reality being part of the problem. Anyone ever used a registry cleaner app and then get LESS spam. I my experience these apps always increase the spam received.

So my question to you is, how do we know that you are NOT trying to compromise our hmailservers?

insomniac2k2 wrote:In any case, I can just bow out and use it for my purposes.

Please don't

Sharing is great, and alternate opinions and ideas are what makes open source software work.

insomniac2k2 wrote: If you have use for it, ask for the source. If you don't, then don't.

Great answer...

Whilst I think that anyone having even just read only access to scripts is likely to lead to bigger issues, I certainly see a point in not including passwords (and usernames) in them.
Your idea of an .exe that requires a 'secret' and does just one thing is a plausible solution, and I don't know of many solutions...

FWIW you've certainly made me think about the security of my PHPwebAdmin, among other things

Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

Sooo. Curiosity got the best of me. I decided to run with Rvdh's suggestion/comment on opening up the Proxy to multiple tasks. So while attempting to preserve the original purpose of the Proxy in the first place, I decided to add Auto-Whitelisting w/ auto purging as a POC. Not only that, but i decided to rewrite the argument syntax to a more standard Microsoft structure.

So in order to replace most of the whitelist code and use ProxyAuth instead. It would look like this:

'--------------------------------------------------------
' Auto Whitelist recipients from auth'd senders
'--------------------------------------------------------
If oClient.Port = 25 Then ' set your smtp sending port number here
If oClient.Username <> "" Then
Dim oRecipient
Set oShell = CreateObject("WScript.Shell")
For oRecipient = 0 to oMessage.Recipients.Count-1
If Not oMessage.Recipients(oRecipient).IsLocalUser Then
For oWhitelistAddress = 0 to oWhitelistAddresses.Count-1
oShell.Run """C:\Program Files (x86)\hMailServer\Bin\ProxyAuth.exe"" -secret mySecret -whitelist " & oClient.IPAddress & " -purge 180" 'user will add if not in list already. List will be read and old users will be purged.
Exit For
End If
End If
End If

Of course you could do whatever you want. It doesnt matter how you call ProxyAuth. It will ban or whitelist whatever you tell it to

'--------------------------------------------------------
' Auto Whitelist recipients from auth'd senders
'--------------------------------------------------------
If oClient.Port = 25 Then ' set your smtp sending port number here
If oClient.Username <> "" Then
Dim oRecipient, oShell
Set oShell = CreateObject("WScript.Shell")
For oRecipient = 0 to oMessage.Recipients.Count-1
If Not oMessage.Recipients(oRecipient).IsLocalUser Then
'user will add if not in list already. List will be read and old users will be purged.
oShell.Run """C:\Program Files (x86)\hMailServer\Bin\ProxyAuth.exe"" -secret mySecret -whitelist " & oMessage.Recipients(oRecipient).Address & " -purge 180"
End If
Next
End If
End If

And yes, this would need to be part of probably be OnAcceptMessage sub.

Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

'--------------------------------------------------------
' Auto Whitelist recipients from auth'd senders
'--------------------------------------------------------
If oClient.Port = 25 Then ' set your smtp sending port number here
If oClient.Username <> "" Then
Dim oRecipient, oShell
Set oShell = CreateObject("WScript.Shell")
For oRecipient = 0 to oMessage.Recipients.Count-1
If Not oMessage.Recipients(oRecipient).IsLocalUser Then
'user will add if not in list already. List will be read and old users will be purged.
oShell.Run """C:\Program Files (x86)\hMailServer\Bin\ProxyAuth.exe"" -secret mySecret -whitelist " & oMessage.Recipients(oRecipient).Address & " -purge 180"
End If
Next
End If
End If

And yes, this would need to be part of probably be OnAcceptMessage sub.

I still get viruses from friends that never should have been given access to electronic equipment. If I whitelist them ... Geezzzuss ... That is the main reason I gave up on Percepts' old script from 2013 doing the same as your binary Whitelist thingy. Original script dates back to 2008.viewtopic.php?p=155530#p155530

Whitelisted addresses are NOT virus/spam checked... Just saying...

I favor using the Whitelist in Greylisting to allow known servers immediate access as an alternative.

Eg. like this ... BTW, "LockFile" is used as a kind of record lock since VBS do not natively support record locking. I experience quite often 5-10 concurrent connections from spammers and unless I control the sequence in which things are done, I get errors.

"Sub ExpireGreyList" is included here but I actually run it from a separate script via Windows Scheduler.

I wont be using it either, i just wanted to see how easy it would be to add it as an interop function. Needless to say, it would be pretty easy to add anything to this if you were motivated. I also think that its very important to scan all emails. Especially from my friends

SorenR wrote:I still get viruses from friends that never should have been given access to electronic equipment. If I whitelist them ... Geezzzuss ... That is the main reason I gave up on Percepts' old script from 2013 doing the same as your binary Whitelist thingy. Original script dates back to 2008.viewtopic.php?p=155530#p155530

Whitelisted addresses are NOT virus/spam checked... Just saying...

I favor using the Whitelist in Greylisting to allow known servers immediate access as an alternative.

Eg. like this ... BTW, "LockFile" is used as a kind of record lock since VBS do not natively support record locking. I experience quite often 5-10 concurrent connections from spammers and unless I control the sequence in which things are done, I get errors.

"Sub ExpireGreyList" is included here but I actually run it from a separate script via Windows Scheduler.

Ok, thanks for clarification. I'll do some reading, but if you read this, feel free to beat me to the answer. I'm running 5.6.5-B2367. I'm guessing that OnHelo a burned-in unsupported feature in my version? I know i've seen an OnHelo thread, so i will go take a look as well.

I've already added the code to add greywhitelist to ProxyPass, and at first glance it looks like it will work without issue. I just have to test the call real fast to verify.

Thanks for the code snips. It helps with some ideas on how to clamp things down a bit

SorenR wrote:

insomniac2k2 wrote:I notice in your script that you are using OnHELO. As far as i understand, this is superseded by OnClientConnect, correct?

I want to give the greywhitelist a go but just wanted to verify before i start testing.

They are two different things...

OnClientConnect will only give you the IP address and IP Port.

ALL initial connections do a EHLO/HELO to identify themselves regardless of protocol. This "greeting" is used by many to filter out SPAM and bots, as do I, and it is also used to identify the sender.

I COULD do the GreyWhitelist by doing IP lookups and dissect the SPF information for each server - but it's a TON of work and not that easy to do. Filtering on EHLO/HELO is so much easier

This is what I do... Not the complete code, but you'll get the idea

PS. My IDS code is using a local SQLite database, not the hMailServer database.

insomniac2k2 wrote:Ok, thanks for clarification. I'll do some reading, but if you read this, feel free to beat me to the answer. I'm running 5.6.5-B2367. I'm guessing that OnHelo a burned-in unsupported feature in my version? I know i've seen an OnHelo thread, so i will go take a look as well.

You won't find OnHELO in the official code... I've been pushing to get in there - along with many others but so far no luck.

Yes, we have a OnHELO thread that has a life of it's own. RvdH has taken it upon himself to maintain an UN-official release.

Simply install the official (same version) release and replace the executeable and library from RvdH's code and you are set to go. If you go back in the OnHELO thread there are older versions if you prefer. My own version is a local mod of the original 5.4.2 and the OnHELO code originate from this mod. RvdH have added some of his own code and bugfixes - plus some experimental stuff too

I just started reading the thread. Your response saved me a ton of time!! Thank you. I'll give it a try soon.

SorenR wrote:

insomniac2k2 wrote:Ok, thanks for clarification. I'll do some reading, but if you read this, feel free to beat me to the answer. I'm running 5.6.5-B2367. I'm guessing that OnHelo a burned-in unsupported feature in my version? I know i've seen an OnHelo thread, so i will go take a look as well.

You won't find OnHELO in the official code... I've been pushing to get in there - along with many others but so far no luck.

Yes, we have a OnHELO thread that has a life of it's own. RvdH has taken it upon himself to maintain an UN-official release.

Simply install the official (same version) release and replace the executeable and library from RvdH's code and you are set to go. If you go back in the OnHELO thread there are older versions if you prefer. My own version is a local mod of the original 5.4.2 and the OnHELO code originate from this mod. RvdH have added some of his own code and bugfixes - plus some experimental stuff too

You wouldn't need any file locking or checking logic. As this is handled by the interop. If you feel like giving it a try, please feedback your results. Please note that I did not follow anyone's particular naming convention. My naming convention is as follows: "Auto Add IP Address - domain.com - todays date".

When An ip connects that is previously in the list, the description updates for that list item to reflect the days date. Nothing further is needed to be done. So as stated above, you can call ProxyAuth from batch or task to purge whatever record you want for how many days back you want to do it for. (ProxyAuth.exe -secret secretpass -purge GreyWhitelist 180)

PS: I realize that this may very well just be for me, but as this grows into something with a bit more versatility, it may suit a few others needs. I still like this much better than having passwords is plain text

Up until this point, i have not been comfortable with including the source for this application, because the moment the source was available the "crypto" string which was static in the class, would be available for reverse engineering. (Ala, you have source, so you have everyone else's crypto key if they left it default). I didn't want anyone blaming me for this type of exposure.

This is now moot! From this point forward, the application will create its own random "hash" string and inject it into your ini file (or any other path of choice by changing the source.). What this means to you is several things:

You can use the application as it is (right out of the box). The application will set a unique hash that no one else will know.
You can now set your actual password (that gets encrypted) based on this unique hash
You can now set your "secret" right from command line.

Note this has absolutely no effect on your hmail install. Nor does it change your core password. It just allows you to never share it with anyone in plain text. If you run into an issue, then just wipe out the 3 settings in your ini file and start over. You will regenerate all new unique variables.

So here's how you get started:

Copy ProxyAuth to your bin folder
From command line:
ProxyAuth.exe -setpass <your real password to be encrypted>
ProxyAuth.exe -setsecret <your unique secret word that you will use to call ProxyAuth.exe in the future>

That's it. You are now using a unique and pretty damn secure way call your functions without sharing your passwords in plain text.

Note: Your secret phrase muse be in your Hmailserver.ini as secretWord=mySecret for the above command line to work

Q: So what is there to gain by using this approach?
A: A few things:
i. As stated many times. No plain test passwords
ii. Reduction of scripting overhead on hmail threads. Once hmailserver hands off the task to ProxyAuth, the thread gets free'd to move on. It doesn't matter of ProxyAuth fails to complete a task. it will not affect the performance of the core application.
iii. You can confuse the hell out of everyone else trying to figure out what you are doing

Disclaimer: As it stands, everything is known to be bug free. I have some lazy catch code in there that can be improved on, but well, i'm lazy....

Glad you found use for it! Attached is updated source and compiled exe. I fixed a few small bugs and corrected some loops that were making redundant calls. I also added standardized logging for all tasks to write to the hmailserver_events.log file. If the file doesnt exist, it will create and use it.

I also removed the interop dll from the source, as it is redundant to include it. So if you use my code, make sure to move your interop dll over to the source root folder.

Porcupine added some great and necessary changes and was nice enough to share. Attached his his version oh Program.cs. Just overwrite the original program.cs file with this one. They are all great changes. Using the interop's event writer was much smarter than my hackery.

Copy Paste of changes:

"I've made some small tweaks just to program.cs to allow ProxyAuth to run on installations that are not in the default location. ProxyAuth.exe just need to be placed in the \Bin folder and it will automatically find the .ini file and extract the path of the log folder. For debugging, you can set the value of bDebug to True and it will take the hard coded values of the default installation folder, but don't forget to set it to False for release.

I have also changed the way that it logs to the Event Log so that it allows hMailServer to handle it. Everything else is unchanged. I've put comments around my changes to make it more visible."

Thanks Alex!

I have some other small tweaks that i'm testing. I will wrap in these changes with mine in a future release.