I would like to filter packages containing either HTTP, IRC, or DNS messages.
Can you recommend any command to do this with Wireshark?
How about this?
http or irc or dns
Use "or" to combine multiple possible matches as a filter.
E.g.
tcp.port eq 80 or tcp.port eq 53 or tcp.port eq 194
I know this is long time after but this link from wireshark is good https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html
If you want to Filter in protocols you can use
http||dns||irc (The || is an or)
If you want to Filter out protocols you can use
!http&&!dns&&!irc (The && is an and)
Related
I am attempting to create some rules to help deal with the outbound spam we've seen lately from our customers being compromised. To do this I'm using an Exim filter and I need to discard the emails which includes numbers from 0-9 for example:
$sender_address: contains "#domain.com"
$header_subject: contains "^([0-9]+)\#domain\.com"
However, the filter is not working as expected. I want to discard the emails which are received from domain.com like 123#domain.com | 234567#domain.com
I tried many tricks, but none of them was working.
For the regex matching, try using matches instead of contains
$header_subject: matches "^([0-9]+)\#domain\.com"
Problem:
Trying to write a milter for Postfix to tie the presence of certain headers in an email to the destination IP address and TCP Port of the outbound relay host.
Following the Postfix milter guide it seems I need to implement a before-queue milter.
Doing so using the Sendmail::Milter perl module.
I can get at everything I need in the headers, envelope, etc except for the ultimate destination (IP and port) that it will be relayed to. Obviously that makes sense for a before-queue milter.
Where to get the relay information?
Looking at our Postfix logs I can see messages of the following format:
TIMESTAMP HOST postfix/qmgr[pid]: XXXXXXXXXX: log message here
TIMESTAMP HOST postfix/smtp[pid]: XXXXXXXXXX: log message here
TIMESTAMP HOST postfix/smtpd[pid]: XXXXXXXXXX: log message here
Some of the log lines have the relay information I'm looking for, i.e:
<TIMESTAMP> <HOST> postfix/smtp[pid]: XXXXXXXXXX: to=EMAIL, relay=HOST[ADDR]:PORT, ...
That ADDR and PORT is exactly what I'm looking for. The XXXXXXXXXX is what seems to tie it all together in the logs. I'm led to believe that this is called the 'Queue ID' or 'Job ID' depending on what you're talking about.
If I could get at that XXXXXXXXXX Queue/Job ID from the milter, then it'd be no problem to tie the logs together.
Tried?
It looks like I might be able to get at some vendor specific information by calling $ctx->getsymval SYMNAME from the callbacks.
Additional information is passed in to the vendor filter routines using symbols.
Symbols correspond closely to sendmail macros. The symbols defined depend on the
context. SYMNAME is the name of the symbol to access.
This function returns the value of the symbol name SYMNAME.
The milter guide has code like the following to get at the 'Queue ID':
/* Determine the job ID for logging. */
if (dfc->mctx_jobid == 0 || strcmp(dfc->mctx_jobid, JOBIDUNKNOWN) == 0) {
char *jobid = smfi_getsymval(ctx, "i");
if (jobid != 0)
dfc->mctx_jobid = jobid;
}
I just can't figure out if I can get at that jobid via getsymval (and what the SYMNAME might be), or via some other context method.
Any ideas?
Use below to get queue_id.
my $queue_id = $ctx->getsymval('i');
I need to strip the rport parameter from the Via field of SIP messages being generated by Yate (for compatibility with a broken peer). Can I use the scripting capabilities of Yate to do this? How do I intercept and modify outgoing SIP messages?
I discovered, by reading the code, that Yate already supports this feature. In accfile.conf, in the section defining the sip server to register to, place the following line:
xsip_flags=1
This prevents the rport parameter from being placed in SIP messages. This may break routing if you are behind a NAT, so beware.
An example config would therefore be:
[sip_service]
enabled=yes
protocol=sip
description=sip_service
username=user
domain=somewhere.com
authname=auth
password=secret
server=somewhere.com
xsip_flags=1
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"COMMUNITY BOT IRC Traffic Detected By Nick Change"; flow: to_server,established; content:"NICK "; nocase; offset: 0; depth: 5; flowbits:set,community_is_proto_irc; flowbits: noalert; classtype:misc-activity; sid:100000240; rev:3;)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"COMMUNITY BOT Internal IRC server detected"; flow: to_server,established; flowbits:isset,community_is_proto_irc; classtype: policy-violation; sid:100000241; rev:2;)
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CHAT IRC message from internal bot"; flow: established; flowbits:isset,community_is_proto_irc; content:"PRIVMSG "; nocase; classtype:policy-violation; sid:1463;)
The above rules have been written by David Bianco to track IRC bot/server activity on any IRC port. However, the above rules works fine but I have a problem with them. My problem is happening when multiple IRC servers (some of them work on 7000 and the other work on 6667) run on the network some of them will achieve the conditions of the rules and Snort will generate the alerts and some of them (or even one of them) will not achieve these condition and as a result Snort wont generate any alert related to the defined set. I think there's a kind of inconsistency. Any suggestions on that issue? I am working on Snort 2.8.
These IRC rules are quite old and won't (as you've seen) capture all IRC traffic. It's almost impossible to say why they're not matching with a network capture or trace.
The first rule is set a flowbit based on the rule matching the traffic (based on an insenstitive match of the word 'NICK' from offset 0 for a depth of 5), if the first rule doesn't match the traffic then it won't set the flowbit to "community_is_proto_irc". Here's an old explanation on flowbits - http://forums.snort.org/forums/rules/topics/flowbits.
The second rule simply alerts on the presence of the flowbit (for traffic from external to home) whilst the third rule is more granular with a content match (and the traffic flow reversed).
I'd recommend getting a pcap for the non-matching IRC traffic and firing it through Snort locally to see what's being missed and then tailoring your rules accordingly (snort -r test.pcap -c /etc/snort_test.conf) - http://manual.snort.org/node8.html.
HTH!
Thanks God, the issue is resolved now.... The reason of the problem was a conflict between many rules which trying to trig at the same time for the same activity (PRIVMSG), so when I removed these rules, every think was just fine for the above rules.
I want something like:
"http://www.anyhostname.com" ==> "http://192.168.0.1"
i.e. I want to redirect any request other than "192.168.0.1" to "http://192.168.0.1"
I am using Lighttpd as my webserver and dnsmasq as my DNS server.
I have to wonder if you're doing transparent proxying -- if so, there may be better mechanisms to accomplish what you want to do than literally doing what you outlined as your goal.
But if you want to keep going this route, I think you can use lighttpd's mod_evhost facility to easily use a default site configuration:
General Example:
server.document-root = "/home/user/sites/default/site"
evhost.path-pattern = "/home/user/sites/%0/site/"
If example.org is requested, and
/home/user/sites/example.org/site/ is
found, that path becomes the docroot.
If example.net is requested but no
directory named
/home/user/sites/example.net/site/
exists, then the docroot remains
/home/user/sites/default/site
If you have specific hostnames that you want to handle, you can add them to /etc/hosts and your dnsmasq will serve them. This would work if you had a few hundred hosts/domains that you wanted to handle, but if you wanted to handle everything, then dnsmasq may not be the right tool.
I know that PowerDNS's PipeBackend can be used to easily give the same answer regardless of DNS question; this way, you could easily intercept requests and handle some or all requests specially. This way, you could answer 192.168.0.1 for every request, for some requests, or anything you can program.
Okay, I solved the problem. Posting the solution here back with hope that it helps somebody in the future...
I solved this by modifying the lighttpd.conf file. I added the following inside my lighttpd.conf file:
$HTTP["host"] !~ "mydesiredhostname\.com" {
url.redirect = (
"" => "http://192.168.0.1/"
)
}
Thank you everybody for your time. Cheers!