[Snort-sigs] About the connection in the alert of BackDoor

Joel Esler joel.esler at ...435...
Tue Jan 8 11:02:49 EST 2008


Reply Inline --


On Jan 8, 2008, at 3:55 AM, Sun wrote:

> Hi, Joel,
>
>     Thank you very much for your valuable reply!
>
>     It seems that I still misunderstand the exact meaning of  the  
> flow option. In the snort manual,  the flow option to_server and  
> from_client is with the same explaination. I searched the mailing  
> list, and a message long time before give me the following  
> explaination:
>
> 1. to_client: means that the server is attacking the client;

First off, let's get away from the word attacking.  Because that will  
confuse everyone.  to_client means that the traffic was initiated by  
the client, and to_client means the traffic is coming back FROM the  
server TO the client.  No one is attacking (or may be?) anyone at this  
point, just that the traffic is in the direction of from the server to  
the client.

>
>
> 2. from_server: means that the alert is a response of attacked  
> server to the client;

from_server is the same as to_client essentially.  We are just  
indicating the direction of flow.  Think about the TCP 3 way handshake  
in this case.  (No comments #snort-gui peanut-gallery -- pay no  
attention here Mingming -- inside joke)

Client says to server "SYN"
C  ---> S
Server answers client "SYN-ACK"
C  <--- S
Client answers server "ACK"
C  ---> S

Now Snort, since it was keeping track of that 3 way handshake can now  
say "this is the client from this IP on THIS port and this is the  
server from this IP on THIS port."  So that in rules, Snort keeps  
track of which direction the traffic is flowing order to establish  
wether or not the rule should fire.


>
>
> 3. from_client: means that the alert is a response of an attacked  
> client to the server;

from_client is traffic going to a server.  So it's essentially the  
same as "to_server".

>
>
> 4. to_server: means that the client is attacking the server.
>

to_server.  Traffic going to server.  Get it now?


>    alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"WEB- 
> CLIENT Outlook EML access"; flow:from_client,established;  
> uricontent:".eml"; reference:nessus,10767; classtype:attempted-user;  
> sid:1233; rev:11;)

Okay, so someone on your network connecting to EXTERNAL_NET and the  
flow is from_client.  Again, let's get the word "attack" out of your  
head.  This isn't an attack, it someone checking their email.  But  
it's someone on your network checking their email on a network that is  
not yours.  (Depending on how you have EXTERNAL_NET set.)  "Outlook"  
isn't being "attacked" at all.  Someone on your network (HOME_NET) is  
checking their email on an external server.  Which, depending upon  
your environment, may be against policy.

Hope that helps.

Joel

>
>
>     I think the alert is saying that outlook are trying to access a  
> eml file on a http server.  The description of this alert says that  
> this event may indicate that the http server may be attacked. But I  
> think this alert should indicate that the outlook client may be  
> attacked. Can you tell me the exact meaning of this alert?
>
>        Best wishes and Thank you very much!
>
>        Mingming
>
> Joel Esler  :
>>
>> You have to look at it a couple ways.
>>
>> HOME_NET any -> EXTERNAL_NET any okay, so the connection is taking  
>> place going outbound from my network.
>>
>> to_server -> okay, so the the connection is taking place STARTING  
>> on my network (the initial SYN was sent from my network).
>>
>> So what this looks like to me is that your network has ALREADY been  
>> "infected" with this backdoor, and the machine that is affected is  
>> beconing back home to it's master.
>>
>> What sid is the EML rule?
>>
>> Don't judge "who the attacker is" by the direction of the flow.   
>> You have to take alot of things into consideration.
>>
>> Joel
>>
>>
>> On Mon, Jan 07, 2008 at 02:08:20PM +0800, it looks like Sun sent me:
>>
>>> Hi all,
>>>
>>>    Happy new year!
>>>
>>>    I'm analysing the role of the participants in an alert. I found
>>> there is some difficult in analysing the alerts in class of  
>>> BACKDOOR.
>>> There are commonly a word 'connection' in the alert names, but it  
>>> may
>>> means the attacker connecting to the victim sometime and means the
>>> victim connecting the attacker sometime.
>>>
>>>    I first suppose the snort are protecting the home net, so the
>>> participant in the home net would be the victim. However, I found  
>>> some
>>> specical case.
>>>
>>>    For example, for the alert 'BACKDOOR FsSniffer connection  
>>> attempt',
>>> its rule is :
>>>
>>> alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"BACKDOOR  
>>> FsSniffer
>>> connection attempt"; flow:to_server,established; content:"RemoteNC
>>> Control Password|3A|"; reference:nessus,11854;
>>> classtype:trojan-activity; sid:2271; rev:2;)
>>>
>>>    The flow: to_server seems indicating that an attacker in the  
>>> homenet
>>> are connecting a external victim.
>>>
>>>    So, should I judge the roles by the flow option? Is the flow  
>>> option
>>> accurate enough to support my analysis? I seems to have seen some
>>> inconsistent case about the flow option.
>>>
>>>    By the way, an another related case is the alert 'WEB-CLIENT  
>>> Outlook
>>> EML access'. For the alert, who is the attacker and who is the  
>>> victim?
>>>
>>>    Thank you very much!
>>>
>>>    Best regards!
>>>
>>>
>>>    Mingming
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>
>>
>>> _______________________________________________
>>> Snort-sigs mailing list
>>> Snort-sigs at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>>>
>>
>>
>>
>>
>>
>>
>> -----
>> joel esler
>> 828A A216 6D95 A6BB B386  54F3 ACE3 B833 5F51 4902
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20080108/10e8cf20/attachment.html>


More information about the Snort-sigs mailing list