iptables: what is a chain? - linux

I've been reading about iptables for hours and I still don't understand what is it that they're calling a "chain".
I see this word everywhere in the doc and in tutorials and it's still fuzzy to me what they're talking about.
What's a chain?

Chain is nothing but sequence of filter rules maintained by iptables.
INPUT Chain : For packets coming into the system or destined for the
system.
FORWARD Chain : For packets travelling (being routed) through the
system.
OUTPUT Chain : For packets leaving the system or originating from
the system.
To know more about IPTABLES, Visit an article my Linux Blog:

A chain is a sequence of rules applied in order.
There are three built-in chains (INPUT, OUTPUT and FORWARD) and you can create your own to streamline processing for e.g. specific packet types.

Related

Why are there different STRING formats?

When some time ago I had developed a script to query network interfaces via snmpwalk and IF-MIB::ifDescr the output format was like STRING: eth0.
The OS was SLES11 using net-snmp (it still works in SLES12 using net-snmp-5.7.3).
However on a different OS (still Linux) the interface strings are represented as STRING: "port1" (note the surrounding double-quotes).
Now the question is: Who is responsible for the extra double quotes? A different version of net-snmp, or a different SNMP agent? Or is one of the results incorrectly implemented in the agent?
As far as I understand SNMP the double quotes are not necessary for the protocol as strings are always transmitted with their length.
While it would be unusual (and undesirable) for an SNMP Agent to provide a quoted string in response to a query for ifDescr (or for anything else!) as they are indeed not part of the contract of a string at that level, the SNMP world is rife with oddities and variations and specification deviations, so this is not something you can assume will never happen.
Meanwhile, the format of the command-line output of a tool like Net-SNMP is effectively arbitrary: the developers can choose whether or not to quote strings, and as long as they document their choice, the end result is the same. So you cannot make any assumptions here either.
You should examine the actual data. You can do this by sniffing the SNMP packets with a tool like tcpdump and loading them into a UI like Wireshark (previously Ethereal). Then you can observe the actual contents of the datagram without the Net-SNMP formatting. If it contains quotes, it's the agent's fault; if it doesn't, the app is adding them for display.
(There's probably a Net-SNMP flag to make it display the bytes, in hex form, making up the string, which would be an easier way to gather this evidence if I remembered what the flag was.)
As an editorial note, if you'd told us what the "different" Linux OS actually was, and what version of Net-SNMP you were using on it, we could have confirmed (or ruled out) option two for you.
(For what it's worth, I'm not aware of any Net-SNMP change that added or removed quotation marks from the command-line output, so this is probably an oddity of the agent on that "different" system.)

Is it possible to extract antenna's radio signal (analog) input samples with RFID FX7500?

I need to do some NON-STANDARD signal processing operations with an RFID-reader, so I'd like to know if it is possible to extract antenna's individual analog (actually digital samples right after ADC) input signal samples with Motorola FX7500 (if you know how this works on FX7400 or FX9500, please do tell, could be helpful). Samples would be processed in a JAVA-based host computer program.
What I've already tried:
Investigating Motorola's own RFID3 API's possibilities, it doesn't go deep enough to actually get in touch with input analog signal samples.
Using LLRP to its full extent, it doesn't allow analog signal sample access either. RFsurvey-functionality would have been helpful to some extent, but FX7500 doesn't support it either.
Accessing RFID-reader's linux terminal, trying to find the driver function(s), that could listen the input sample stream. If current input sample(s) could be extracted from the input stream, I could (in theory) make a script, that would save a few of those sample values in a txt-file in the host computer during a tag inventory round. My linux skills are kinda bad, hence I ask this question.
The only realistic way to solution seems to be via linux terminal, so if you folks have any ideas about that (where to look and what to do), please advise!
Contents of reader:
rfidadm#FX7500abcdef:/$ ls -1
apps
bin
dev
etc
home
include
lib
linuxrc
media
mnt
platform
proc
readerconfig
run
sbin
sys
tmp
usr
var
I cannot completely rule that out, but it's highly unlikely you can get the raw signal digitized; the devices you're looking at aren't really software defined radio devices, typically.
"speaking" RFID physically is a bit different from "usual" wireless communication: The reader doesn't only observe the energy transmitted from the tag, but more importantly the fluctuations of energy extracted from the near field of the reader's antenna coil. Hence, you don't actually have a baseband of RF bandpass signal, but hardware-specific modulations of transmitted (and inversely, antenna-reflected) energy. Demodulation is hence usually done in specialized hardware.
However, do not fret: It's totally possible to build a software defined RFID reader. There have been several approaches to that, but personally, I trust these based on Ettus USRPs and/or GNU Radio best. Look through the results IEEExplore gives you, eg. this search.
Most probably this is not possible with the Motorola readers. What you can do, is use one of the RFID chipsets available on the market: either the AMS RFID IC's, or the Impinj RFID IC's. As far as I know, both IC's support retrieving the digital samples that are received. They also have a development kit to test-drive the IC's.

Capability to drop IP packets in Linux

I want to drop outgoing IP packets from my machine based on some criteria. I checked the capabilities provided by iptables but unfortunately it doesn't have what I am looking for.
So what I want is access to packets (at least those generate on my machine and going out). And based on some criteria the ability to drop them.
Should I be looking at modifying the iptables source code to add this functionality OR should I make a Linux kernel module to do this? or is there something else I should look into?
I want some general guidance but any specifics like a particular file in iptables where such functionality can be added will be very useful too!
You can use the NFQUEUE target of the netfilter. It sends packets to a userland program which can parse the payload and return a decision like DROP or ACCEPT.
You can find documentation and examples on the netfilter website.
This functionality is mentionned at the beginning of man iptables...
From what you're describing, it sounds like what you're trying to do could probably be implemented as a new iptables match. You'd have to tell us what conditions you're trying to drop packets based on before we could advise you in more detail, though.
I'm pretty sure iptables could be used to drop packets based on the condition. If the condition is complicated you might need to write your own netfilter plugin (http://netfilter.org/) to augment what can be done with iptables.

Tool to discard packet payload?

I'm trying to anonymize packets from a pcap file that I have. I need to discard all the packets payloads/content (leaving only header information) and was wondering if there would be a tool that I could use for this (on Linux)? I have thought about using tcpdump with specifying the snaplen but with the header length changing, I don't think that would work.
If there isn't a tool that could accomplish this, a point in the direction of what library for coding would be best(easiest) would work as well. I'd rather not take that route since I have virtually no experience in network programming.
Any help is much appreciated.
You don't need any network programming experience to anonymize the packets. The format of the output file is well documented in the pcap-savefile(5) manpage. You will need to lookup the layouts of the various protocols you'll be handling in order to identify what fields need to be anonymized. You should also look at the link layer header types documentation at tcpdump.org to help you get started.
EDIT: Also look at libpcap itself... according to the pcap-savefile manpage:
NOTE: applications and libraries
should, if possible, use libpcap to
read savefiles, rather than having their own code to read
savefiles.
If, in the future, a new file format is supported by libpcap,
applica-
tions and libraries using libpcap to read savefiles will be
able to
read the new format of savefiles, but applications and
libraries using
their own code to read savefiles will have to be changed to
support the
new file format.

Sanitizing Input from irc

So I was thinking of writing a irc bot/bot extension that lets users play certain text based games by starting the game,
sending parts of certain lines they enter(regexp match for game signal if not in bots channel ex. rbot gamename enter the forest . sends "enter the forest) to std in of game,
while standard out of game is cached by bot and the piped to the channel (ex.
"let us rejoice for
the duck has been defeated"
gets read into a line cache inside the bot and then
the bot sends it to the appropriate channel as
gamename: let us rejoice for
gamename: the duck has been defeated"
)
But I'm sort of worried about the tricky things people on irc might do, would stripping all non printable characters be enough safety? If a program quits (say they enter the quit command for the game) what happens when you try writing to the file descriptor for that programs std in(error)? Any other potential problems?
Note I'm going to run this on linux or *bsd so I don't need to worry about windows specific things.
Some basics you might want to consider:
It's much safer to allow text through that you know is safe, than to try and filter out text that you think might not be safe. The games probably accept only alpha-numeric characters, so check to see if the input contains only those values, and deny anything else.
Run the bot under an account that has the lowest permissions possible, and as limited access to the rest of the machine as possible. If you can sandbox or virtualize it completely, even better.
You should be watching the PID of the child process for termination, and decide what to do if it exits, restart it or fail further commands, exit the bot, etc.
There are any number of possible security issues whenever exposing services to the network, you would do well to read about general secure programming topics, a quick google search turns up this how-to for example.
It pays to be paranoid. Without following proper secure programming practices, the most you can hope for is that nobody gives an honest try at breaking it.
escaping quotes and pipe will keep you safe from most stuff
" ' |
It doesn't matter where the user input is coming from, it matters how its used.
The one attack that affects IRC is CRLF injection. This will come up for you if you echo back user input over IRC. An attacker could try and inject a carrage return (\r) line feed (\n). This type of injection affects many protocols including HTTP and SMTP. In the case of IRC the attacker would be able to force your bot to send a command to the IRCD (like /join or /kick or /ban :). Make sure to look at an ASCII table and filter out all 0x0A (\n) and 0x0D (\r). In most cases the new line is enough, so make sure you filter for both.
Make sure you read over OWASP A1: Injection. Especially if you are using user input in a sql query or invoking a process on the commandline.

Resources