hMailServer forum

mats wrote: ↑

2018-12-18 20:39

I see two repeating patterns on my mailserver of spammers trying to use on of my domains.
They try to send a Mail and when they get a PW request they quit the connection.

"SMTPD" 2316 1668 "2018-12-18 18:34:56.751" "190.236.239.220" "SENT: 530 SMTP authentication is required."
"DEBUG" 2316 "2018-12-18 18:34:56.751" "AWStats::LogDeliveryFailure"
"DEBUG" 2240 "2018-12-18 18:35:04.249" "The read operation failed. Bytes transferred: 0 Remote IP: 190.236.239.220, Session: 1668, Code: 10054, Message: An existing connection was forcibly closed by the remote host"

"SMTPD" 2316 1669 "2018-12-18 18:40:16.798" "185.171.235.253" "SENT: 530 SMTP authentication is required."
"DEBUG" 2316 "2018-12-18 18:40:16.798" "AWStats::LogDeliveryFailure"
"SMTPD" 2240 1669 "2018-12-18 18:40:20.232" "185.171.235.253" "RECEIVED: QUIT"

Since they never ever sends an incorrect password autoban won't block them.
Therefore I would like to know if there is a way to use a script to generate autoban rules for these patterns.
they are annoying me

SorenR wrote: ↑

2018-12-19 01:14

My own IDS system is only doing 2/3 of the above... Maybe it's time to upgrade

SorenR wrote: ↑

2018-12-19 00:58

mats wrote: ↑

2018-12-18 20:39

I see two repeating patterns on my mailserver of spammers trying to use on of my domains.
They try to send a Mail and when they get a PW request they quit the connection.

"SMTPD" 2316 1668 "2018-12-18 18:34:56.751" "190.236.239.220" "SENT: 530 SMTP authentication is required."
"DEBUG" 2316 "2018-12-18 18:34:56.751" "AWStats::LogDeliveryFailure"
"DEBUG" 2240 "2018-12-18 18:35:04.249" "The read operation failed. Bytes transferred: 0 Remote IP: 190.236.239.220, Session: 1668, Code: 10054, Message: An existing connection was forcibly closed by the remote host"

"SMTPD" 2316 1669 "2018-12-18 18:40:16.798" "185.171.235.253" "SENT: 530 SMTP authentication is required."
"DEBUG" 2316 "2018-12-18 18:40:16.798" "AWStats::LogDeliveryFailure"
"SMTPD" 2240 1669 "2018-12-18 18:40:20.232" "185.171.235.253" "RECEIVED: QUIT"

Since they never ever sends an incorrect password autoban won't block them.
Therefore I would like to know if there is a way to use a script to generate autoban rules for these patterns.
they are annoying me

Are the requests recurring from the same IP or are they "from all over"? How frequent are they if recurring?

mats wrote: ↑

2018-12-19 20:53

SorenR wrote: ↑

2018-12-19 00:58

mats wrote: ↑

2018-12-18 20:39

I see two repeating patterns on my mailserver of spammers trying to use on of my domains.
They try to send a Mail and when they get a PW request they quit the connection.

"SMTPD" 2316 1668 "2018-12-18 18:34:56.751" "190.236.239.220" "SENT: 530 SMTP authentication is required."
"DEBUG" 2316 "2018-12-18 18:34:56.751" "AWStats::LogDeliveryFailure"
"DEBUG" 2240 "2018-12-18 18:35:04.249" "The read operation failed. Bytes transferred: 0 Remote IP: 190.236.239.220, Session: 1668, Code: 10054, Message: An existing connection was forcibly closed by the remote host"

"SMTPD" 2316 1669 "2018-12-18 18:40:16.798" "185.171.235.253" "SENT: 530 SMTP authentication is required."
"DEBUG" 2316 "2018-12-18 18:40:16.798" "AWStats::LogDeliveryFailure"
"SMTPD" 2240 1669 "2018-12-18 18:40:20.232" "185.171.235.253" "RECEIVED: QUIT"

Since they never ever sends an incorrect password autoban won't block them.
Therefore I would like to know if there is a way to use a script to generate autoban rules for these patterns.
they are annoying me

Are the requests recurring from the same IP or are they "from all over"? How frequent are they if recurring?

They are from all over so a simple block of one or a few IP:s won't help.
the freq. varies too from one attempt and never try again to two-three attempts with 10 sec between.
Another pattern is one attempt every 12 hour.

[settings]

DisableAUTHList=25
; Setting DisableAUTHList allows you to specify a comma-separated list of SMTP ports which authentication should not be enabled for.
; This is useful when working with legacy systems with malfunctioning SMTP support.

mats wrote: ↑

2018-12-20 21:48

Seems to be 25 only.

I have 5.6.6 installed.
Does DisableAUTHList work with that?
Found an older thread that indicated that a special build was required

mats wrote: ↑

2018-12-22 22:32

updated. Missed one parameter

Code: Select all

Sub OnClientConnect(oClient)
'Variables
	ClientIp				= oClient.IpAddress			'Connecting remote IP address
	WhiteList				= "127.0.0.1,172.16.1.1-172.16.255.255,1.2.3.4"		'Variable array for whitelisted IP addresses to exclude, localhost, maybe your servers IP address, your WebClient IP address whatever. Now supports ranges
	
	PercentageReject		= "5"
	PercentageWarn			= "2"
	PercentageInform	    = "0"
	AutobanDays				= "2"
	AdminPassword			= "Password"
	
	
'Check if connecting client is whitelisted
	If CheckWhitelisted(WhiteList,ClientIp) Then
	  EventLog.Write "Whitelisted IP: " & ClientIp
	else
	  Percentage 				= "0"					'Default value
	  Percentage			= CheckAbuseIPDBConfidence(ClientIP)

'Process reported percentage		
		If Percentage >= PercentageReject then
			Result.Value 		= 1
			EventLog.Write ("AbuseIPDB: IP Address " & ClientIp & " rejected: Confidence of Abuse: " & Percentage & "%.")
			AutobanIP ClientIp,AutobanDays,"AbuseIPDB: IP Address " & ClientIp & " rejected: Confidence of Abuse: " & Percentage & "%.",AdminPassword
		ElseIf Percentage >= PercentageWarn then
			Result.Value 		= 0
			EventLog.Write ("AbuseIPDB: IP Address " & ClientIp & " warning: Confidence of Abuse: " & Percentage & "%.")
		ElseIf Percentage >= PercentageInform Then 'changed logic so that Percentage 0 gets logged
			Result.Value 		= 0
			EventLog.Write ("AbuseIPDB: IP Address " & ClientIp & " notification: Confidence of Abuse: " & Percentage & "%.")
		End If
	End If
End Sub




  
function CheckWhitelisted(List,ClientIp)
  
  CheckWhitelisted=false
  arrIpranges=Split(list,",")
  For Each Iprange In arrIpranges
    If InStr(Iprange,"-") Then
      If ClientIp>=Left(Iprange,InStr(Iprange,"-")) And ClientIP<=mid(Iprange,InStr(Iprange,"-")+1) then
		CheckWhitelisted=true
	  End if	  
    Else
      If ClientIp=Iprange Then
        CheckWhitelisted=true
	  End if
	End if
  next
End Function

Public Function CheckAbuseIPDBConfidence(IPAddress)
	CheckAbuseIPDBConfidence		= "0"
	Set objXMLHTTP				= CreateObject("msxml2.xmlhttp.6.0")
		objXMLHTTP.Open "GET", "https://www.abuseipdb.com/check/" & IPAddress, False
		objXMLHTTP.Send ""
		ResponseText			= objXMLHTTP.responseText
		ResponseArray			= Split(ResponseText, VbLf)
		For Each ResponseLine in ResponseArray
			If Left(ResponseLine, 6) = "<span>" And Right(ResponseLine, 8) = "%</span>" Then
				CheckAbuseIPDBConfidence 	= Mid(ResponseLine,7, Len(ResponseLine)-14)
				Exit For
			End If
		Next	
	Set objXMLHTTP 				= Nothing
End Function	

Sub AutobanIP(IPAddress, NumberOfDays, ReasonForBan,AdminPassword)
	
	Dim oApp
	Set oApp = CreateObject("hMailServer.Application")
	Call oApp.Authenticate("Administrator",AdminPassword)

	Dim i
	For i = 0 To oApp.Settings.SecurityRanges.Count -1
		If IPAddress = oApp.Settings.SecurityRanges.Item(i).LowerIP Then Exit sub
	Next

	oApp.Settings.SecurityRanges.Refresh
	With oApp.Settings.SecurityRanges.Add()
		.lowerip = ipaddress
		.upperip = ipaddress
		.priority = 20
		.allowdeliveryfromlocaltolocal = False
		.allowdeliveryfromlocaltoremote = False
		.allowdeliveryfromremotetolocal = False
		.allowdeliveryfromremotetoremote = False
		.allowimapconnections = False
		.allowsmtpconnections = False
		.allowpop3connections = False
		.expires = True
		.ExpiresTime = DateAdd("d", NumberOfDays, Now())
		.name = ReasonForBan & " - banned for " & NumberOfDays & " days - " & ipaddress
		On Error Resume Next
		.save
		If (Err.Number = 0) Then
			EventLog.Write "Autoban IP range saved for IP Address " & IPAddress & " with Reason-" & reasonforban
		ElseIf (Err.Number <> 0) Then
			
			EventLog.Write"Error       : " & Err.Number
			EventLog.Write"ERROR: EventHandlers.vbs : Function LockFile""Source      : " & Err.Source
			EventLog.Write"ERROR: EventHandlers.vbs : Function LockFile""Description : " & Err.Description
			Err.Clear
		End If
		On Error Goto 0
	End With
End Sub

mats wrote: ↑

2018-12-26 14:46

One way of solving the password problem is to store the PW in an external file.
That file should then be encrypted with EFS (you must be logged on as the account that is running the Hmailserver service to do this).

Cons:
An external file reference.
You need a windows version with EFS

Pro:s
Crypto key stored in the user profile for that user. IE you have to have access to that account to get the PW.
By using a dedicated PW file you can still change the script with your regular admin user.

insomniac2k2 wrote: ↑

2018-12-27 02:41

You mean like this:
viewtopic.php?f=20&t=31874

I started using this as a banning solution and ended up adapting it to use it as an auth function for multiple things interop based. The source is there, so you can adapt it to whatever you need.

mats wrote: ↑

2018-12-26 14:46

One way of solving the password problem is to store the PW in an external file.
That file should then be encrypted with EFS (you must be logged on as the account that is running the Hmailserver service to do this).

Cons:
An external file reference.
You need a windows version with EFS

Pro:s
Crypto key stored in the user profile for that user. IE you have to have access to that account to get the PW.
By using a dedicated PW file you can still change the script with your regular admin user.

mats wrote: ↑

2018-12-27 12:31

insomniac2k2 wrote: ↑

2018-12-27 02:41

You mean like this:
viewtopic.php?f=20&t=31874

I started using this as a banning solution and ended up adapting it to use it as an auth function for multiple things interop based. The source is there, so you can adapt it to whatever you need.

mats wrote: ↑

2018-12-26 14:46

One way of solving the password problem is to store the PW in an external file.
That file should then be encrypted with EFS (you must be logged on as the account that is running the Hmailserver service to do this).

Cons:
An external file reference.
You need a windows version with EFS

Pro:s
Crypto key stored in the user profile for that user. IE you have to have access to that account to get the PW.
By using a dedicated PW file you can still change the script with your regular admin user.

Well, sort of
there are two major differences
1. I do want to limit the access to a user and that user only.
2. I want the solution to be available for all uses.

But your code actually gave me an idea how it might be done.

mats wrote: ↑

2018-12-30 22:23

Making more progress.

Been playing around with com objects and passing and returning an object as a parameter to a com object.
The nice thing is that we can call objects byref IE we can modify the object externally and continue to use it after that.
That makes it possible to do an external auth function and we can return the authenticated object to the script

in my DLL i have

Code: Select all

Public Sub secureauth(ByRef HmailserverObject As Object, strusername As String)
        Dim strpassword = ""
        decode(strpassword)
        HmailserverObject.authenticate(strusername, strpassword)
    End Sub

Private Sub decode(ByRef outdata As String)
        Dim Protectedbytes As Byte()
        Protectedbytes = System.IO.File.ReadAllBytes(Environment.GetEnvironmentVariable("appdata") & "\Hmailextender.txt")
        Dim clearTextbytes As Byte() = ProtectedData.Unprotect(Protectedbytes, Nothing, DataProtectionScope.CurrentUser)
        outdata = System.Text.Encoding.Unicode.GetString(clearTextbytes)
    End Sub

In my script i got

Code: Select all

Set objApp = CreateObject("hMailServer.Application")
   set MySecurity = CreateObject("HmailExtender.security")
   MySecurity.secureauth objApp, "Username"
   

The result is an objapp object that is authenticated

mats wrote: ↑

2018-12-28 21:18

Simply to prevent someone from doing msgbox "here is the secret password" and that's the part where I'm going to bluntly steal some code

RvdH wrote: ↑

2019-01-04 12:33

mats wrote: ↑

2018-12-28 21:18

Simply to prevent someone from doing msgbox "here is the secret password" and that's the part where I'm going to bluntly steal some code

And how exactly does your solution prevent the msgbox "here is the secret password" example you referred to yourself earlier? (Not saying MsgBox "here is the secret password" is possible in the first place!)

RvdH wrote: ↑

2019-01-04 12:33

Fake security, with only extra overhead as result if you ask me

SorenR wrote: ↑

2019-01-04 23:21

Why not use vbsedit to convert vbs to an exe file ...

mats wrote: ↑

2018-12-28 21:18

it's simple to do a msgbox of the password when it is stored in cleartext in the script, I don't believe we have to discuss that further

RvdH wrote: ↑

2019-01-05 03:49

mats wrote: ↑

2018-12-28 21:18

it's simple to do a msgbox of the password when it is stored in cleartext in the script, I don't believe we have to discuss that further

Please show me how, i could not do it....and i doubt you can do it either,
Sure, if you stored the password in a CONST you could, but then again simply do not do that!

The point in general is, if an unauthorized person has physical access to the server it is probably a (skilled) hacker, who has no problems defeating your additional protection as well, any debugger will have discovered your encrypted password just as easy by putting a breakpoint on the Application object Authenticate(string Username, string Password) which is still submitted through to your COM object and then is passed to to original object in plain text. I know, i earlier have said i liked the idea insomniac2k2 suggested, but in reality i have never used it


But hey, i like to be surprised....please prove me otherwise

Const sAdminPassword = "<ADMINISTRATORPASSWORD>"

Dim oApp
Set oApp = CreateObject("hMailServer.Application")

' Authenticate the client.
Call oApp.Authenticate ("Administrator", sAdminPassword)

Call oApp.BackupManager.StartBackup()

mats wrote: ↑

2019-01-05 13:51

With the password in script all the attacker needs is notepad or cmd .......

mattg wrote: ↑

2019-01-05 00:07

SorenR wrote: ↑

2019-01-04 23:21

Why not use vbsedit to convert vbs to an exe file ...

Now that is an interesting thought

Convert Into Executable

VbsEdit lets you convert your scripts into standalone applications. Unlike the older versions of VbsEdit, the script will now be executed directly within the executable. The original script will no longer be extracted into a temporary folder.

Once converted, the source of your script will be nearly impossible to be viewed by other users.

Built-in WScript object

The application uses a built-in WScript object.

• Create a new script with only one line: WScript.Echo WScript.ScriptFullname
• Convert the script into an executable and run it. The ScriptFullname property is now the application's path!

UAC Execution Level

VbsEdit adds an application manifest to the program that tells the operating system what the application needs. The possible requested execution level values are:

• asInvoker: The application will run with the same permissions as the process that started it. The application can be elevated to a higher permission level by selecting Run as Administrator.
• highestAvailable: The application will run with the highest permission level that it can. If the user who starts the application is a member of the Administrators group, this option is the same as requireAdministrator. If the highest available permission level is higher than the level of the opening process, the system will prompt for credentials.
• requireAdministrator: The application will run with administrator permissions. The user who starts the application must be a member of the Administrators group. If the opening process is not running with administrative permissions, the system will prompt for credentials.

How does VbsEdit pre-populate fields and options?

Vbsedit now stores parameters into an xml file. To get the path of this xml file, just add "2exe" to the path of the script file. If the path of your script is c:\myfolder\myscript.vbs, then the xml file is c:\myfolder\myscript.vbs2exe.

Command-line option

To automate the creation of the executable, start Vbsedit with the /convert2exe option.
Examples:
Vbsedit.exe /convert2exe c:\myfolder\myscript.vbs
Vbsedit.exe /convert2exe:c:\myxmlfile.vbs2exe c:\myfolder\myscript.vbs


Digital signature

Code signing is the process of digitally signing executables to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed.

If you want to buy a code signing certificate, visit K Software [http://codesigning.ksoftware.net/] (we are not affiliated with them in any way, but they have reasonable prices).

Alternate User Account and Password

It allows a user to run the executable under a different username to the one that was used to logon to a computer interactively. It is similar to the runas command.
For example, it could allow a user to run a task as admin even if he does not have administrator permissions himself.

mattg wrote: ↑

2019-01-05 15:47

mats wrote: ↑

2019-01-05 13:51

With the password in script all the attacker needs is notepad or cmd .......

Don't they also need access to your file system?

SorenR wrote: ↑

2019-01-05 15:55

mattg wrote: ↑

2019-01-05 00:07

SorenR wrote: ↑

2019-01-04 23:21

Why not use vbsedit to convert vbs to an exe file ...

Now that is an interesting thought

From HELP file...

Convert Into Executable

VbsEdit lets you convert your scripts into standalone applications. Unlike the older versions of VbsEdit, the script will now be executed directly within the executable. The original script will no longer be extracted into a temporary folder.

Once converted, the source of your script will be nearly impossible to be viewed by other users.

Built-in WScript object

The application uses a built-in WScript object.

• Create a new script with only one line: WScript.Echo WScript.ScriptFullname
• Convert the script into an executable and run it. The ScriptFullname property is now the application's path!

UAC Execution Level

VbsEdit adds an application manifest to the program that tells the operating system what the application needs. The possible requested execution level values are:

• asInvoker: The application will run with the same permissions as the process that started it. The application can be elevated to a higher permission level by selecting Run as Administrator.
• highestAvailable: The application will run with the highest permission level that it can. If the user who starts the application is a member of the Administrators group, this option is the same as requireAdministrator. If the highest available permission level is higher than the level of the opening process, the system will prompt for credentials.
• requireAdministrator: The application will run with administrator permissions. The user who starts the application must be a member of the Administrators group. If the opening process is not running with administrative permissions, the system will prompt for credentials.

How does VbsEdit pre-populate fields and options?

Vbsedit now stores parameters into an xml file. To get the path of this xml file, just add "2exe" to the path of the script file. If the path of your script is c:\myfolder\myscript.vbs, then the xml file is c:\myfolder\myscript.vbs2exe.

Command-line option

To automate the creation of the executable, start Vbsedit with the /convert2exe option.
Examples:
Vbsedit.exe /convert2exe c:\myfolder\myscript.vbs
Vbsedit.exe /convert2exe:c:\myxmlfile.vbs2exe c:\myfolder\myscript.vbs


Digital signature

Code signing is the process of digitally signing executables to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed.

If you want to buy a code signing certificate, visit K Software [http://codesigning.ksoftware.net/] (we are not affiliated with them in any way, but they have reasonable prices).

Alternate User Account and Password

It allows a user to run the executable under a different username to the one that was used to logon to a computer interactively. It is similar to the runas command.
For example, it could allow a user to run a task as admin even if he does not have administrator permissions himself.

mats wrote: ↑

2019-01-05 13:51

RvdH wrote: ↑

2019-01-05 03:49

mats wrote: ↑

2018-12-28 21:18

it's simple to do a msgbox of the password when it is stored in cleartext in the script, I don't believe we have to discuss that further

Please show me how, i could not do it....and i doubt you can do it either,
Sure, if you stored the password in a CONST you could, but then again simply do not do that!

The point in general is, if an unauthorized person has physical access to the server it is probably a (skilled) hacker, who has no problems defeating your additional protection as well, any debugger will have discovered your encrypted password just as easy by putting a breakpoint on the Application object Authenticate(string Username, string Password) which is still submitted through to your COM object and then is passed to to original object in plain text. I know, i earlier have said i liked the idea insomniac2k2 suggested, but in reality i have never used it


But hey, i like to be surprised....please prove me otherwise

Code: Select all

Const sAdminPassword = "<ADMINISTRATORPASSWORD>"

Dim oApp
Set oApp = CreateObject("hMailServer.Application")

' Authenticate the client.
Call oApp.Authenticate ("Administrator", sAdminPassword)

Call oApp.BackupManager.StartBackup()

The included backup script in Hmailserver.
Just add a msgbox sAdminPassword and you are done,. That is the current security level.

But since you say that we shouldn't do that please show a script that does authenticate and doesn't have the password in cleartext then.

with physical access to a server without an encrypted harddrive, then you are always f-cked. I usually need 3-5 mins to have system privs on that kind of box using 100% signed Microsoft code.
One guy thought that they where safe using applocker - Well they wasn't. The way to handle that is with drive encryption, locked doors and if possible armed guards.

My main concerns are not the superhacker. I'm a lot more worried about script kiddies and automated attacks targeting software issues like buffer and stack overflows because they are remotely exploitable.
That's why my first step was to switch from system to a ordinary user account (an account that can't log on interactively or over network either)
If the service is compromised it will not have more than user privs, therefore you can't do a net user /add or attach a debugger.

The next thing I'm worried about is usernames and passwords in cleartext since people tends to reuse them regardless of how many times you tell them not to.
With the password in script all the attacker needs is notepad or cmd .......

mats wrote: ↑

2019-01-05 13:51

Code: Select all

Const sAdminPassword = "<ADMINISTRATORPASSWORD>"

The included backup script in Hmailserver.
Just add a msgbox sAdminPassword and you are done,. That is the current security level.

RvdH wrote: ↑

2019-01-11 00:46

mats wrote: ↑

2019-01-05 13:51

Code: Select all

Const sAdminPassword = "<ADMINISTRATORPASSWORD>"

The included backup script in Hmailserver.
Just add a msgbox sAdminPassword and you are done,. That is the current security level.

That is exactly why i said with password stored in a CONST you could, but then again simply do not do that!

jimimaseye wrote: ↑

2019-01-12 20:46

How about strict security to stop unauthorised persons looking at random script files on your server in the first place?

I'm pretty sure that if anyone had gained access to your system and shouldn't be there, the last thing they will be looking at is some unknown script file in a 3rd party software on your system (to read a password it uses). Worse case scenario is they then go and lookup on the internet what hmailserver is and how it works, write a script to suit it and work out a way of uploading it back to your events directory, restart the service, and try to then use it to send out some spam. (... eventually).

Or maybe they rub their hands together, ignore the little known hmailserver software and embark on exploiting known global windows exploits that they already know and start to spread viruses.

Just a thought.

[Entered by mobile. Excuse my spelling.]