I am setting up some iptables to help protect against DDos attacks for a university assignment. Im using the OWASP broken wep application and i have found some rules that work and ive figured out majority of the rules i just cant find out what the -t means. for example:
Iptables -t mangle -A PREROUTING -m conntack –ctstate INVALID -j DROP
This option specifies the packet matching table which the command should operate on. If the kernel is configured with automatic module loading, an attempt will be made to load the appropriate module for that table if it is not already there.
The tables are as follows:
filter:
This is the default table (if no -t option is passed). It contains the built-in chains INPUT (for packets destined to local sockets), FORWARD (for packets being routed through the box), and OUTPUT (for locally-generated packets).
nat:
This table is consulted when a packet that creates a new connection is encountered. It consists of four built-ins: PREROUTING (for altering packets as soon as they come in), INPUT (for altering packets destined for local sockets), OUTPUT (for altering locally-generated packets before routing), and POSTROUTING (for altering packets as they are about to go out). IPv6 NAT support is available since kernel 3.7.
mangle:
This table is used for specialized packet alteration. Until kernel 2.4.17 it had two built-in chains: PREROUTING (for altering incoming packets before routing) and OUTPUT (for altering locally-generated packets before routing). Since kernel 2.4.18, three other built-in chains are also supported: INPUT (for packets coming into the box itself), FORWARD (for altering packets being routed through the box), and POSTROUTING (for altering packets as they are about to go out).
raw:
This table is used mainly for configuring exemptions from connection tracking in combination with the NOTRACK target. It registers at the netfilter hooks with higher priority and is thus called before ip_conntrack, or any other IP tables. It provides the following built-in chains: PREROUTING (for packets arriving via any network interface) OUTPUT (for packets generated by local processes)
security:
This table is used for Mandatory Access Control (MAC) networking rules, such as those enabled by the SECMARK and CONNSECMARK targets. Mandatory Access Control is implemented by Linux Security Modules such as SELinux. The security table is called after the filter table, allowing any Discretionary Access Control (DAC) rules in the filter table to take effect before MAC rules. This table provides the following built-in chains: INPUT (for packets coming into the box itself), OUTPUT (for altering locally-generated packets before routing), and FORWARD (for altering packets being routed through the box).
Related
Before I proceed, I'd like to mention that I did try to research this topic on the internet, but I still need clarification.
Let's say I have two Linux machines connected to a switch (and only to a switch). Machine A has an IP address of 10.0.0.1 and machine B -- 10.0.0.2. I used nmcli command to set the IP address and create an ethernet interface for each machine. Everything works as expected.
Now, the confusing part is how machine A can find machine B and vice versa? I'm using the following command to connect from machine A to machine B:
ssh userB#10.0.0.2
And it works, even if this is the very first data transmission. This surely means that machine A somehow already knew the machine's B MAC address; otherwise, the frame wouldn't find its way to machine B. But how? Since the IP address is meaningless to the switch (Level2), why when I do ping 10.0.0.2 or ssh 10.0.0.2, it still works?
Probably the ARP cache was already populated. Maybe there was a grations ARP broadcast:
Every time an IP interface or link goes up, the driver for that interface will typically send a gratuitous ARP to preload the ARP tables of all other local hosts.
If not, most likely an ARP request/reply was happening right before the first ping. Check the arp command or ip neigh.
In general I suggest you use Wireshark to explore what's going on, or something like tcpdump -n -i eth0 not ssh if your are working remotely (note the -n to prevent name resolution). You can also record traffic with tcpdump -s 9999 -w output.pcap and view it later in Wireshark.
If you sniff network traffic on a third PC, keep in mind that switches will not send traffic to all ports when they have learned where the destination is. Some switches allow you to configure a mirror port to observe all traffic to or from a certain port. Either way you should always be able to observe ARP requests as they are broadcast.
basically, when the first packet reach to the switch ( virtual or physical switch ), the switch will populate arp broadcast packet for the sake of getting all devices mac and ip addresses. so even though ip addresses seem meaningless to switches ( cause they're layer 3 concept but switch is for layer 2 ), switches still need those data to process the packets. because this is how we, as human beings, interact with computers for transmitting data by using ip addresses.
when you ping a device, like 10.0.0.2, the switch will search in it's arp table and find the corresponding mac address and also the interface for reaching to the destination.
the best way to comprehend the whole process is to capture the data using wireshark or even implementing a simple topology in softwares like cisco packet tracer.
I am using OpenWRT router. I need to block a URL or multiple URLs (Not IP) for specific time. for example, I want to block facebook.com so that clients of this router cant access the website. firewall rules should have the option to do that but I dont know how to do that.
Here is one way to block by domain name rather than by IP address.
The main reason of why you need such a complicated method is that each domain name (e.g. facebook.com) may be resolved as different IP address at any given time. So, we need to keep a list of resolved IP addresses and add iptables rules based on this list.
First, you should enable logging in dnsmasq config:
uci set dhcp.#dnsmasq[0].logqueries=1
uci commit dhcp
/etc/init.d/dnsmasq restart
This will give you log entries like:
daemon.info dnsmasq[2066]: reply facebook.com is 31.13.72.36
Now, you just have to constantly parse syslog and add corresponding iptables rules like this (note that you most likely need a more versatile script and ipset for better performance):
logread -f | awk '/facebook.com is .*/{print $11}' | while read IP; do iptables -I OUTPUT -d $IP -j DROP; done
i try to run snort as an IPS. so i install snort on ubuntu server via apt-get and config daq_type as afpacket and daq_mode as inline. and 2 interface like eth1:eth2
then i write a rule for test
reject tcp any any -> any any (sid: 1000005;)
it work but when i change it to
drop tcp any any -> any any (sid: 1000005;)
it does not work. and when i change action to sdrop the result is same.
and i install snort from source but the result was same.
can you help to to write true rule?
Snort can operate in three different modes namely tap (passive), inline, and inline-test.
If you want to use drop rules to drop packets you need to make sure that you are running in inline mode. From the looks of it you are probably not in inline mode. The reason "reject" is working is because it will send a reset for TCP, which will stop the rest of that stream, or it will send an ICMP port unreachable message back for UDP. See the following explanations from the snort manual (http://manual.snort.org/node29.html) on rule headers:
drop - block and log the packet
reject - block the packet, log it, and then send a TCP reset if the protocol is TCP or an ICMP port unreachable message if the protocol is UDP.
sdrop - block the packet but do not log it.
If snort is not running in inline mode it is not going to actually drop the packet(s), it will just generate an alert (for drop) and pass the packet(s).
See the following from the snort manual on the three modes: http://manual.snort.org/node11.html#SECTION00295100000000000000
Specifically, inline mode is described as follows:
When Snort is in Inline mode, it acts as an IPS allowing drop rules to trigger. Snort can be configured to run in inline mode using the command line argument -Q and snort config option policy_mode as follows:
snort -Q
config policy_mode:inline
You need to make sure the line "config policy_mode:inline" in is you snort.conf and when you are running snort you pass the "-Q" option. If both of these are not done it will not drop. Hope this helps!
is it possible to send an echo-request to a host set behind nat
after. all the echo-request doesn't hold a port for the destination host so if there are several hosts using the same external ip address how will the nat be able to forward the echo-request to a specific host
Most modern NAT/packet filtering implementations are stateful. That means they have a wider concept of the word connection than the older stateless variants. That allows them to handle more complex protocols that use additional connections (e.g. FTP), as well as connection-less protocols like ICMP.
In the case of ICMP packets, echo requests contain an ID field that is preserved in the reply. While its 16 bits are somewhat restrictive, it allows in conjuction with the source IP address from the IP header to have a reasonably high confidence on which echo request each reply corresponds to.
EDIT:
As for targeting specific hosts behind a NAT implementation, that is not generally possible. You might be able to:
Redirect all ICMP traffic to one internal host to monitor that one host only.
Use the "pad" data bytes of the echo request packet to provide some kind of host identifier. For example, the -p option of ping on some Linux systems allows setting that field. This is by no means standard, though.
In general, NAT is supposed to hide the hosts behind it from the world, with the exception of any forwarded IP connections.
I have a Perl-based CGI/Fast CGI web service and want to rate-limit clients by IP address to stop aggressive clients causing too much work.
I have looked around for some code and found Algorithm::TokenBucket in CPAN but that is for client requests; it has no persistence and has no per-user config so is not really useful for server-side rate limiting.
I am looking for suggestions for something that already exists, otherwise I'll need to roll my own based on some simple persistence such as tie to DB_File per-IP address and some batch job that does the token management.
I've used Cache::FastMmap for rate-limiting by tracking hits per IP address. It's a cache so data will expire over time, but if you set the size and expire time right, this shouldn't be an issue.
The IP address is the hash key and the hash value is an array of timestamps. I have a second data structure (also backed by Cache::FastMMap) which is a hash of banned IP addresses, updated according to the data from the first structure.
I know it's not what you asked, but have you considered handling this elsewhere in the stack where it's already been done for you? Clearly I don't know your deployment stack, but if it's apache you could use mod_evasive. Alternately if you're on Linux you could let iptables do its job using something like:
#Allow only 12 connections per IP
/sbin/iptables -A INPUT -p tcp --dport 80 -m conn-limit --connlimit-above 12 -j REJECT --reject-with tcp-reset
certainly more complicated rules are possible.