Snort alert not reproducable

digidax · Dec 3, 2013, 8:45 AM

Hello,

I'm running Snort 2.9.4.6 pkg v. 2.6.1 on pfsense 2.1-RELEASE (amd64).

In the alert log are two events as an example for this issue:

User 1:

12/02/13-19:19:09.269122 ,141,1,1,"(IMAP) Unknown IMAP4 command",TCP,89.246.187.xxx,34341,94.100.75.xxx,143,61184,Generic Protocol Command Decode,3,

and User 2:

12/02/13-19:49:14.271898 ,141,1,1,"(IMAP) Unknown IMAP4 command",TCP,77.235.190.xxx,34413,94.100.75.xxx,143,39138,Generic Protocol Command Decode,3,

Only User 2 can work with the IMAP ressource. Clients are on both sides Android 4.1.2 and Win7proSP1 with Thunderbird 24.1.1. If I change the clients between the locations the result will be the same. The mainly difference is the ISP.
As I can see in pfsense Alert Log, the SID 141 is displayed. If I follow http://snort.org/search/sid/141, why did it works on one IP but not on the other?
The same problem is with SMTP, only User 2 can work with it.

best regards
Frank

bmeeks · Dec 3, 2013, 5:58 PM

@digidax:

Hello,

I'm running Snort 2.9.4.6 pkg v. 2.6.1 on pfsense 2.1-RELEASE (amd64).

In the alert log are two events as an example for this issue:

User 1:
12/02/13-19:19:09.269122 ,141,1,1,"(IMAP) Unknown IMAP4 command",TCP,89.246.187.xxx,34341,94.100.75.xxx,143,61184,Generic Protocol Command Decode,3,
and User 2:
12/02/13-19:49:14.271898 ,141,1,1,"(IMAP) Unknown IMAP4 command",TCP,77.235.190.xxx,34413,94.100.75.xxx,143,39138,Generic Protocol Command Decode,3,
Only User 2 can work with the IMAP ressource. Clients are on both sides Android 4.1.2 and Win7proSP1 with Thunderbird 24.1.1. If I change the clients between the locations the result will be the same. The mainly difference is the ISP.
As I can see in pfsense Alert Log, the SID 141 is displayed. If I follow http://snort.org/search/sid/141, why did it works on one IP but not on the other?
The same problem is with SMTP, only User 2 can work with it.

best regards
Frank

Frank:

Your question is a bit hard to follow, but I believe you are saying one user (User #2) has no problems with the connection and the other user (User #1) does have a problem. Is that correct? I'm not sure I fully understand the problem. Can you try restating it again?

These are preprocessor alerts. You can stop them by disabling the associated preprocessor, or you can add Suppress List entries to stop alerts from the events. Suppress List entries are the preferred method for dealing with unwanted alerts.

Bill

digidax · Dec 3, 2013, 7:04 PM

Sorry Bill,

yes you understood right: User 2 can work, User 1 not. I have disabled the IMAP preprocessor and User 2 can work now. Where can I see, which IMAP commands are known in the IMAP preprocessor setup?
In snort.conf I know where I can edit the preprocessor setup for e.g. FTP.
But the IMAP part has no variables für the IMAP commands.

best regards
Frank

bmeeks · Dec 3, 2013, 9:17 PM

@digidax:

Where can I see, which IMAP commands are known in the IMAP preprocessor setup?
In snort.conf I know where I can edit the preprocessor setup for e.g. FTP.
But the IMAP part has no variables für the IMAP commands.

best regards
Frank

There are no configurable commands for IMAP according to the Snort documentation. Attached is the README file for the IMAP preprocessor, and it does not mention any configurable settings for IMAP commands.

Bill

README.imap.txt

digidax · Dec 4, 2013, 6:56 AM

So, after sniffing with tcpdump I can reproduce the problem now:
There is a bug in the IMAP preprocessor during handling TLS communication:
http://seclists.org/snort/2013/q3/453
Is there a bug tracker where I can see the status of this reported bug?

I my case, User 1 has a bad DSL-Line. If during the TLS session snort gets a hiccup, the mail server gets a broken TLS login and so it's close the session.

Until this bug is not fixed, there are two ways: disable the IMAP preprocessor OR switch of TLS for IMAP auth.

best regards
Frank

A Former User · Dec 4, 2013, 10:43 PM

You can also use a suppress rule for that, and it's this:

#(IMAP) Unknown IMAP4 command
suppress gen_id 141, sig_id 1

bmeeks · Dec 5, 2013, 12:57 AM

@digidax:

So, after sniffing with tcpdump I can reproduce the problem now:
There is a bug in the IMAP preprocessor during handling TLS communication:
http://seclists.org/snort/2013/q3/453
Is there a bug tracker where I can see the status of this reported bug?

I my case, User 1 has a bad DSL-Line. If during the TLS session snort gets a hiccup, the mail server gets a broken TLS login and so it's close the session.

Until this bug is not fixed, there are two ways: disable the IMAP preprocessor OR switch of TLS for IMAP auth.

best regards
Frank

I have a new Snort package based on the 2.9.5.5 binary that is being reviewed by the pfSense Core Team now. Hopefully they approve and merge it soon. I believe some TLS fixes are in the new binary.

Bill