I have a question about security in iptables.
Is it safe to give ACCEPT policy to FORWARD chain? I mean, if packet gets there, it has come through PREROUTING table and in PREROUTING you only change destination ip of packet if you "like it".
all packets that get in FORWARD was matched against one of the rules in PREROUTING right?
If a packet does not match any rules in your PREROUTING chain, there is nothing to prevent it from hitting your FORWARD chain, unless you set the default PREROUTING policy to DROP.
Packets only go to the INPUT chain if their destination address is an address that belongs to a local interface on your host. Otherwise, they go to the FORWARD chain, and if they pass that chain AND the ip_forward sysctl is enabled, your system will forward them based on your routing table.
Your system may receive packets that are not destined for a local interface. This is how basic routing works: when your system wants to contact, say, Google's dns server at 8.8.8.8, packets are sent to your local default gateway, which receives and routes them even though the destination address is somewhere else entirely.
Your system may explicitly route traffic for physical networks to which it is attached or for containers or virtual machines hosted on the system. All of these involve your system accepting and forwarding packets that do not match a local interface.
Related
How's it going everyone? I am trying to create either an iptable or a BPF rule which will only allow OpenVPN traffic over UDP to my VPN server on destination port 1194 in the hopes of preventing DDoS attacks to that port whilst still being able to connect to it. I would normally implement a simple whitelist of me and my friends' ips however one of them has a dynamic IP which changes very regularly so constantly updating my firewall to allow traffic from his IP would be somewhat annoying aha. If it could also only allow windows users to connect that would be great as well as me and my two buddies run windows and this would be one more parameter the traffic has to match in order to be accepted. Any help in creating this rule would be greatly appreciated as my cheap little personal VPN for some reason has been DDoS over 5 times this week while my friends and I play GTA - perhaps that's the reason! Thanks in advance to anyone who can chime in here!
I have tried the following rules but unfortunately to no avail:
#Allow packets with the string "OpenVPN" to my connection port then drop remaining UDP traffic to that port
iptables -A INPUT -p udp --dport 1194 -m string --algo bm --string "OpenVPN" --to 65535 -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -j DROP
After flushing my iptables and adding these two rules, I was expecting to be able to connect to my VPN server through OpenVPN but unfortunately I was unable to connect.
There is no simple way to tell if incoming traffic originates from an OpenVPN application or not. The only way to validate that would be to see if the contents of your UDP packet looks like an OpenVPN protocol header, does the size match, does it contain magic numbers or do certain fields contain the values you expect. So it would require fairly intimate knowledge of the OpenVPN protocol to pull that off.
Additionally, UDP is inherently susceptible to DDoS attacks because of UDP amplification. Even if you were to manage the above, its trivial for most DDoS attackers to just saturate your uplink, making any filtering useless.
Switching to TCP will make it a bit more difficult since launching TCP attacks requires more resources for the same amount of traffic and the three-way handshake offers a good place to enforce proper TCP clients and/or implement IP blacklists.
Ultimately, the only real way to deal with DDoS attacks are to seek protection using DDoS mitigation/protection companies like Cloudflare, Akamai, Imperva, ect. which unfortunately are not free most of the time.
What i am trying to achieve with iptables is setting a rule(s) that when a specific packet arrives from wan it gets redirected to a new address on wan.
Example:
Any UDP packet arriving on port 10000 gets redirected to 8.8.8.8:10000.
This can be more specific, like it originates from ip 1.1.1.1 or destination lan ip is 192.168.1.1 if there is a requirement for the rule to work.
Is this possible? Been trying a couple of rules in chain PREROUTING and using DNAT but i'm honestly in the dark here...
First: your question is more appropriate at Server Fault or Unix & Linux.
To answer your question: it isn't sufficient to only change the destination address because all returned datagrams would go directly from 8.8.8.8 to the original sender who could not relate them to the original datagrams.
So you would add DNAT rules in the PREROUTING chain and additional SNAT rules in the POSTROUTING chain so that the answers gets back to your machine and then can be sent back to the original sender with the appropriate addresses. You have to be very careful when designing these rules.
I was looking into raw sockets. so I created one raw socket client and other one is server. on two different computers. I am using ISP provided router. so I sent spoofed packet (with iphdr struct's saddr of different computer on same network) from client but when the packet received at the server the source ip in packet's ip header was correct (the real sender address=client address) plus the source port and destination port of tcphdr were something different too (which really didnt make sense). So I assumed that my ISP provided router is doing something funny -- OR I am completely wrong correct if this is a normal ip protocol. if I am correct then what steps should i take to configure my router so it does not mess up with tcp and ip headers of incoming packets plus the sync=1 at sender's end became sync=0 of tcphdr. I am using local IPs plus I am trying to implement tcp using raw socket server. I have configured iptables on server as well with sync allowed on my bounded port
iptables -I INPUT -p tcp --dport xxxx --syn -j ACCEPT
WHat settings do I need to do on server in iptables so my socket incoming packets wont be dropped nor any header be touched so I can get all packets required for tcp to keep coming in. plus what setting do I need to do on router so,if its cause problem then, it wont
Update 1:
after spending some time to the problem I found that one cause could be my kernel tcp stack dropping the incoming sync packets. so I looked around and found that in the tcp stack there is work done to make this happening. So I changed the sysctl.conf in /etc to allow sync packets to come in through by adding or uncommenting this line
net.ipv4.tcp_syncookies=1
Then I rebooted the system but still no difference. is it because somehow I have to reload my sysctl.conf file. if this is the case or any related case then please fill in.
Update 2
I have reloaded sysctl.conf after allowing syn packets and now I am getting syn packets from client application. but the destination port different. also along with syn=1, ack=1 is also coming in same packet. is this also something kernel is doing. please explain. as long as I know this is not how tcp works (tcp handshake) and I am connecting from client using stream socket
If my development machine has an iptables rule to FORWARD some packets, are those packets being captured by tcpdump? I have this question because I know there exist other chain called INPUT which filters packets to apps, if a packet is routed to FORWARD chain, will it reach tcpdump app?
May you make some reliable reference to official documentation or express well explained ideas to solve this question?
TCPDump captures traffic from the hardware device. Iptables handles network frames at a different level.
So the answer is no, TCPDump will capture traffic only when it passes through the network card. IPtables can be taking inbound traffic on a card that TCPDump is monitoring, but may send it outbound on a different network card that is not being monitored by TCPDump.
Just remember, TCPDump will catch the traffic only if it passes through the network card.
Let's say my application has listening UDP socket and it knows from what IP addresses it could receive UDP datagrams. Anything coming from other IP addresses would be considered as malicious datagram and should be discarded as early as possible to prevent DoS attacks. The hard part is that the set of these legit IP addresses can dynamically change over application's life time (ie by dynamically receiving them over control channel).
How would you implement filtering based on the source IP address in the case above?
I see two solutions where to put this source IP filtering logic:
Implement it in the application itself after recvfrom() call.
Install default drop policy in the Firewall and then let the application install Firewall rules that would dynamically whitelist legit IP addresses.
There are pros and cons for each solutions. Some that come to my mind:
iptables could end up with O(n) filtering complexity (con for iptables)
iptables drop packets before they even get to the socket buffer (pro for iptables)
iptables might not be very portable (con for iptables)
iptables from my application could interfere with other applications that potentially would also install iptables rules (con for iptables)
if my application installs iptables rules then it can potentially become attack vector itself (con for iptables)
Where would you implement source IP filtering and why?
Can you name any Applications that follow convention #2 (Administrator manually installing static Firewall rules does not count)?
My recommendation (with absolutely no authority behind it) is to use iptables to do rate-limiting to dampen any DoS attacks and do the actual filtering inside your application. This will give you the least-bad of both worlds, allowing you to use the performance of iptables to limit DoS throughput as well as the ability to change which addresses are allowed without introducing a potential security hole.
If you do decide to go about it with iptables alone, I would create a new chain to do the application-specific filtering so that the potential for interference is lowered.
Hope this helps.
Hope this link help you
Network layer firewalls or packet filters operate at the TCP/IP protocol stack, not allowing packets to pass through the firewall unless they match the established rule set defined by the administrator or applied by default. Modern firewalls can filter traffic based on many packet attributes such as source IP address, source port, destination IP address or port, or destination service like WWW or FTP. They can filter based on protocols, TTL values, netblock of originator, of the source, and many other attributes.
Application layer firewalls work on the application level of the TCP/IP stack, intercepting all packets travelling to or from an application, dropping unwanted outside traffic from reaching protected machines, without acknowledgment to the sender. The additional inspection criteria can add extra latency to the forwarding of packets to their destination.
Mandatory access control (MAC) filtering or sandboxing protect vulnerable services by allowing or denying access based on the MAC address of specific devices allowed to connect to a specific network.
Proxy servers or services can run on dedicated hardware devices or as software on a general-purpose machine, responding to input packets such as connection requests, while blocking other packets. Abuse of an internal system would not necessarily cause a security breach, although methods such as IP spoofing could transmit packets to a target network.
Network address translation (NAT) functionality allows hiding the IP addresses of protected devices by numbering them with addresses in the "private address range", as defined in RFC 1918. This functionality offers a defence against network reconnaissance