how to know ip address of packets which matched by content option in snort? - ip

i am using snort-2.9.7.0 and i inspect packet by this simple code:
alert tcp any any -> $HOME_NET any (msg:"FB found in packet content!!!"; content:"FB"; sid:10000; )
i want to know where packet is comes from and store it. guide me.
Thanks and Regards.

You should adjust the output format of the alerts; to do that add this line in your config file:
output alert_fast: <full path to output file>/snort.log
as you here this will print Snort alert messages with full packet headers that contains the source and destination IP addresses and will be saved in snort.log file.
EDIT: The log file can be in any place you like and it's name can be determined by you. for example:
output alert_fast: ~/Desktop/my_snort_log.txt

Related

File Name in Send Port with PGP Encryption

The File Name in the Send Port should be set with the mask like ABC.txt.pgp. Since I have used the PGP Encryption Component it is generating the File name like ABC.pgp.txt.pgp. But what I need is just the ABC.txt.pgp. How can be this be done. Any help is greatly appreciated.
Thanks
What you are seeing is the expected behavior. If you are referring to this:
https://code.msdn.microsoft.com/windowsdesktop/BizTalk-Sample-PGP-ebcbc8b2
or one of it's derivatives, it will internally modify FILE.ReceivedFileName to append .pgp if that property is set.
So, if you use just %SourceFileName%, you will likely get the desired result. Otherwise, you will have to explicitly set FILE.ReceivedFileName to ABC.txt somewhere before the PGP component.
You can also modify the source code to remove this behavior.
(Same Answer)
Thanks Johns-305. I included the Message assignment shape before the send shape and used the
SendMessage(FILE.ReceivedFileName) = "ABC.txt";
In the Send Port I used Filename as "%SourceFileName%". Now I get the filename as ABC.txt.pgp in the Send Port

get a "raw" request\response from MITM Proxy

i', scripting mitm proxy (http://mitmproxy.org/index.html) to write HTTP and HTTPS request and responses to a file according to their IP (each client can then access it's own requests\responses) for unit tests for mobile.
As far as i can see for now i can't just use str(Flow.request) or repr(Flow.request) to get a "raw" print of the response\request like i get in fiddler, i need to reconstruct it from the internal data of the Request and Response objects.
anyone knows of a better way ? i'm using :
def response(ScriptContext, Flow):
Flow.request....
Flow.response....
To access the request or response being intercepted, i'm not changing anything, just observing.
For now the proxy is on 8080, later on it's to be transparent proxy on 80 and 443.
If anyone has done it before i'll be happy if you can share some info.
For those people who want to copy request/response data to clipboard while end up here:
## export the current request/response as curl/httpie/raw/request/response to clipboard
# press colon : and input one of commands and enter
export.clip curl #focus
export.clip httpie #focus
export.clip raw #focus
export.clip raw_request #focus
export.clip raw_response #focus
Mitmproxy: 5.0.1
Source code
couple of things.
first youcan build the raw response yourself using str(flow.request.headers) and request.httpversion and the like.
however it seems that _assemble() and _assemble_headers() do the trick just fine.
so basically:
def request(context, flow):
req = flow.request;
try:
print("Request: -----------------");
print(req._assemble());
print("--------------------------");
except Exception as ee:
print(str(ee));
def response(context, flow):
res = flow.response;
try:
print("Response: -----------------");
print(res._assemble());
if res.content:
size = len(res.content);
size = min(size, 20);
if res.content[0:size] != res.get_decoded_content()[0:size]:
print("\n\n");
print(res.get_decoded_content());
print("--------------------------");
except Exception as ee:
print(str(ee));
as you can see if the decoded body is not similar to the non decoded one (i can check for gzip content type though) i'm printing the decoded message as well.
This should be saved to files according to current dates and each file is named after the client ip taken from request\response.client_conn object. This pretty much solved my problem.
Some check with fiddler shows that the request are reproducable later on which is just what i needed.

Postfix rewrites my return-path header

I have noticed that although I pass a custom return-path header in mails going through my postfix server, the header gets re-written. I would like to pass my own header or at least construct a header dynamically. This is cause I want to get bounced emails on a specific email address (hence I need to pass in the return-path).
Is this possible?
You have to override message_drop_headers to not include the return-path.
message_drop_headers = "bcc, content-length"
http://www.postfix.org/postconf.5.html#message_drop_headers
Have you set envelope sender address?
[-fcommand line option for sendmail look alike provided by postfix]
Many MTAs copy envelope sender address into (overwritten) Return-Path: header.

Sending files through connect direct from UNIX to MAINFRAME

I am sending a file from UNIX to MAINFRAME server via connect direct. I am able to upload the file successfully.At the destination host, when the file is received it is not readable and not in the same format as I sent from the UNIX server.
Below is the transmission job
Direct> Enter a ';' at the end of a command to submit it. Type 'quit;' to exit CLI.
submit maxdelay=unlimited TINIRS process snode=b1ap005
TRANSMIT copy from (file=myFile.txt
pnode
sysopts=":datatype=text"
)
ckpt=1k
to (file=myFile.txt(+1)
snode
DCB=(DSORG=PS,RECFM=VB,LRECL=1500)
disp=(new)
)
pend ;
Please let me know the DCB values needs to be updated. The file I am sending has 3 records of variable length and the maximum length of record is 1500.
Actually, that looks almost right. But if your maximum record length is 1500 characters (exclusive of the NL at the end of the line), your LRECL should be at least 1504. But don't skimp on the maximum - there's no cost or penalty to larger values (up to 32767). And NealB's correct - if this is a text file, you may need to specify a character-set translation - but I don't know how to do that in CONNECT:Direct.
C:D automatically converts ascii to EBCDIC when DATATYPE=TEXT is used. To be positive, you may want to use ":datatype=text:xlate=yes:".

How the "OK" message looks like?

I have a device that sends data to a server.
Data
[ Client ] == > [ Server ]
After the validation on the server I want to return a message:
OK
[ Client ] < == [ Server ]
Is there a standard "OK" message to return? And an "ERROR" message? How does it looks like? (e.g. ":0011", ":110F")
You've got to design an application-level protocol. TCP is a byte stream, so even the definition of "Data" in your client->server piece needs some protocol so that the receiver can know what bytes make up the data (when to stop reading).
A couple of common types of protocols are...
Length-delimited chunks. Every message starts with a 16 or 32-bit length prefix. Then that many bytes follow. The length needs to be in a defined byte order (see htons, ntohs, etc). Everyone who uses this protocol knows to read the length prefix then read that many bytes. Having defined that "chunk" on the network, you might put a header on the contents of the chunk. Maybe a message type (ACK, NAK, Data, etc) followed by some contents.
ASCII newline delimited. Each message is a line of ASCII (or UTF8, etc) text. It ends at a newline. Newline endings for the lines play the same role as the length prefix for the chunks above. You then define what's in each line (like space or comma-delimited ASCII/UTF8/whatever fields). Somewhere in that you'd define what data looks like, ACK, etc.
I'm sure you could come up with other ideas, but that's the basic job: defining your application-level protocol on top of TCP's byte stream.

Resources