One of my assignments requires me to provide inline comments for the snort rule.
It should look something like:
alert \ (some comment initiator here) comment
any \ (explanation)
any \ (explanation)
and so on...
How would I make inline comments with Snort?
You might want to have a look at the Snort manual. Comments are created in the configuration and rules files with the pound sign, which is pretty typical of UNIX type things:
alert tcp any any -> any 0 (sid:1000000;msg:"Packet to port zero.";) # Example rule with comment
Related
I intend to set the "don't fragment" flag bit in Go, the same thing as this post while it is in C. I checked the constant list but I didn't find this option. So what is the corresponding option in Go?
Thanks in advance!
How to set "don't fragment" flag bit for TCP packet in Go?
First up you should know that TCP really doesn't like IP fragments. Most if not all major implementations avoid fragmentation for TCP segments by using path MTU discovery.
The TL;DR is that the typical IP packet containing a TCP segment has a DF bit set. You can (and should) try this out. Here I am sniffing a few seconds of traffic between my machine and stackoverflow.com:
% tshark -w /tmp/tcp.pcap tcp and host stackoverflow.com
<wait a few seconds>
% tshark -r /tmp/tcp.pcap -T fields -e ip.flags | sort | uniq -c
186 0x00000002
0x02 means the DF bit is set. I confess in other captures I have seen the occasional TCP segment in an IP packet without a DF bit; I suspect rfc1191 has an explanation for this.
Now back to your question, I think there's no portable way to set the DF bit and this is a more widespread question (there isn't even a POSIX-portable way).
There is (likely) an escape hatch in the relevant package for your implementation under golang.org/x/sys.
For example, on a Unix that supports IP_DONTFRAG such as FreeBSD one could use unix.SetsockoptInt and dig the relevant constant value.
On Linux there is not IP_DONTFRAG, as you discovered from the question you linked. The workaround seems to be to use IP_MTU_DISCOVER which happens to be available as a constant in the unix package. You can use that same unix.SetsockoptInt to set it.
This question already has answers here:
What does the number in parentheses shown after Unix command names in manpages mean?
(7 answers)
Closed 4 years ago.
I have a simple question I made my self but didn't find any answer and hints.
When I type for the man entries of a command, e.g. "man git", I get the following:
...
DESCRIPTION
...
See gittutorial(7) to get started, then see Everyday Git[1] ...
The Git User's Manual[2] has a more in-depth
introduction.
After you mastered the basic concepts, you can come back to this page to learn what commands Git offers. You can learn more about individual Git
commands with "git help command". gitcli(7) manual page gives you an overview of the command line command syntax.
Formatted and hyperlinked version of the latest Git documentation can be viewed at http://git-htmldocs.googlecode.com/git/git.html.
Could someone explain what are those "See gittutorial(7)...Everyday Git[1]...gitcli(7)" etc.? I mean, I know that they are telling "look at this resource if you want to know the basic concepts, for more info, etc.", but actually how should one interpret it?
What is the meaning of the numbers (like 7, 1, 2, etc..) inside the parenthesis or brackets? And where I can find the resources the manual is telling me to see, do I have to type something in the man prompt, or search on the Internet?
I just would like to ask for an elucidation.
Thank you for your attention!
Man pages are splitted into sections
to access a manual page inside a specific section you prepend the section number before the manpage name, for example try:
man 3 fork
or
man 2 fork
Usually the square braketed numbers are links to additional material in the NOTES section of the manpage (scroll to the bottom)
The parenthesized numbers indicate in which section of the manual the referenced entry appears. Section (1) is commands (programs), section (2) is system call functions, section (3) is general library functions, etc. Some terms have distinct entries in multiple sections. For example, this ...
man 1 printf
... gives a different manual page (from section 1, describing the printf program) than does this ...
man 3 printf
... which gives a page from section 3, describing the printf() function from the C standard library.
It means type man 7 gittutorial for more info. Man page are divided in numbered categories, sometimes overlapping. Use apropos git for instance to see the various possibilities.
The numbers in parentheses, manpage(N), are the manual section, each of the 8 sections covers a different topic.
See man-mages(7) ;) for a list of sections:
man man-pages
And you can open a manpage from a given section by including the number in the command:
man 7 man-pages
The numbers give you a hint of what the manpage will cover, e.g. time(1) is about a command, whereas time(2) is about a system call, and let you specify which section of the manual you're interested in when there's an entry with the same name on different sections.
The numbers between brackets, something[N] are footnotes, usually pointing to places where you can get more information.
In Org-mode you can make comments and from Org-mode you can export to LaTeX but Org-mode comments are not exported to LaTeX comments. How can Org-mode be made to export Org-mode comments as LaTeX comments?
Here is an example. The following
* Test
Text before comment
# Comment
Text after comment
Text before comment
#+BEGIN_COMMENT
Comment
#+END_COMMENT
Text after comment
exports to
\section{Test}
\label{sec-1}
Text before comment
Text after comment
Text before comment
Text after comment
But I want the Org-mode comments to be exported as LaTeX comments. Thus, I want the following LaTeX output:
\section{Test}
\label{sec-1}
Text before comment
% Comment
Text after comment
Text before comment
\begin{comment}
Comment
\end{comment}
Text after comment
I am running Org-mode 7.6 in Emacs 23.3.1.
Under the current exporter the only method I can think of that would allow you to export comments would be backend-specific. You could use something along the lines of:
#+latex: comment
or
#+begin_latex
\begin{comment}
comment
\end{comment}
#+end_latex
However both are contrived and you would need to do the equivalent for HTML etc if you intend to export to more than one format.
There is a new exporter in development however where this should not be overly difficult to implement (comments are already identified as blocks in the parser so it would simply need a method to convert them on export).
I'm forwarding this request to the mailing list to see if this can be included.
Edit: Thread located here.
Edit: Response from the maintainer of Org-Mode
the current exporters don't allow this, but the new export engine by
Nicolas makes it possible.
The plan is to merge the new export engine into Org's core before
version 8.0, so please stay tuned.
In addition to Jonathan Leech-Pepin's answer, there is a hackish way of doing it for a given exporter backend. Comments are handled in the org-export-handle-comments function, which is called by org-export-preprocess-string in org-exp.el. Each exporter backend is different, but let us consider the LaTeX backend.
If you look in the org-export-as-latex function in org-latex.el, you can find calls to org-export-preprocess-string. One of the things passed to the org-export-preprocess-string function is a parameter list, in particular it contains a :comments parameter, which in the LaTeX case is set to nil. This parameter tells the org-mode exporter what to do with comments - for the details look at the call to and implementation of org-export-handle-comments in org-exp.el. Essentially, the :comments parameter can be a format string showing how to handle the comments; if it is nil, this means no format handling so nothing is printed. If, in the org-export-as-latex function, you replace :comments nil with :comments "%% %s", then this will insert a "%" in front of whatever the comment text is upon export. So in your case
this is text before a comment
# this is a comment
this is text after a comment
would be exported as
this is text before a comment
% this is a comment
this is text after a comment
This isn't the most convenient way of doing things, and I'm not sure of a way to specify the :comments parameter on a per-file basis. Maybe something in the thread Jonathan set up will shed some light on this subject.
Note that you may need to remove the byte-compiled org-latex.elc file in order to see your changes in org-latex.el propagate through to the export.
I've just installed and setup an instance of Doxygen, but out of the box it only finds TODO tags in code when marked in a block like:
/**
* #todo Foo
*/
It doesn't seem to find:
// TODO Foo
// FIXME Bar
// #todo Baz
Most IDE's and bug trackers which handle parsing are fine with them, is there an easy way to configure Doxygen to find them and list them as ToDo items?
There are a number of examples and methods we can use:
For a one line comment with valid doxygen commands (e.g. \todo) you would use
/// \todo Some (optional) text
Note the three forward slashes, not the usual two. See point three on the second list in the special documentation blocks section of the doxygen documentation. This can be used to add new todo items to your source code.
Generally one can define custom tags (like FIXME) by defining an alias in the Doxygen configuration file. For example
ALIASES += FIXME="\todo"
which will allow you to write \FIXME in your source code and the comments prefixed with \FIXME will be included in you todo list in the final documentation. The problem here is that you have to prefix your aliases with the \ (or #) symbol and begin the comment with three leading forward slashes which, if you want to leave the FIXMEs in your code as they are, is not an option.
Finally, an alternative method, and what I think you are looking for, would be to preprocess your source files using the INPUT_FILTER configuration file option. This option defines a command that is applied to each of your source files before doxygen builds the documentation, so we can define a command which replaces instances of TODO and FIXME with valid doxygen markup.
INPUT_FILTER = "sed -e 's/\/\/.*FIXME/\/\/\/ \\todo/'"
This filter replaces all instances of // FIXME (with any amount (or none) of whitespace between // and FIXME) with /// \todo. This substitution is made internally by doxygen only: your source files are not modified on disk.
Note: This last point was inspired by the accepted answer to the question Getting doxygen and MSVC TODO tags to work together. However, that answer used the FILE_VERSION_FILTER configuration option rather than INPUT_FILTER. I think that the latter (INPUT_FILTER) is actually more appropriate here. Also, the sed command used in that answer does not work for me.
I read somewhere that it wasn't possible to specify multiple ports to
exclude for shellcode is that correct? if not is the following
correct?
List of ports you want to look for SHELLCODE on.
portvar SHELLCODE_PORTS ![21,25,80,143,587,8889]
I'm using snort 2905
Try it. If Snort doesn't like the syntax, it should throwback a fatal parsing error. I believe, though, that syntax is better implemented as:
portvar SHELLCODE_PORTS [21,25,80,143,587,8889]
I.e., without the negation, and then used in a rule thus:
alert tcp any any <> any !SHELLCODE_PORTS ( ... )
You could also do:
portvar SHELLCODE_PORTS [!21,!25,!80,!143,!587,!8889]
Which should be valid syntax. Haven't tested, though. YMMV.
You want !$SHELLCODE_PORTS
You are missing the dollar sign.