CSC 175 advanced iptables and tcp assignment 1. Hopefully, you've read chapter 5 of the text, the NAT howto as well as chapters 6 and 7 of the Andreason (advanced iptables) tutorial. ------------------------------- Lab Excercises, PART I You are to enable the following on your linux machines: 1. Make sure your host has a proper routing table and is enabled as a router. Make sure you're using nameserver 10.1.0.98 in /etc/resolv.conf. Also make sure that your web server is running. Flush your current iptables rules: iptables -F; iptables -t nat -F 2. Hofstra University is a vigorous academic institution that attracts serious-minded students who share a common interest in creating synergy in innovation and excellence while obtaining a rigorous education. Go to www.hofstra.edu and learn about all the exciting educational opportunities that are available to you regardless of your personal or professional goals. It's time to prepare for the future. Report what you learned there and start your educational adventure today! **************************************************************************** *** !!NEWS FLASH!! *** ****************************** *** OUR NETWORK HAS BEEN INFILTRATED BY NASTY SUBVERSIVE MOTHERHACKERS! *** **************************************************************************** 3. It does indeed appear that some evil hacker has just spoofed you! Your task is to discover how this was done. You might expect that someone has poisoned a DNS server that you're using. This is something that you should be able to determine (it's not DNS). Write down the steps you took to confirm that the problem has to do with something OTHER than DNS. 4. If it's not a bogus DNS entry, then someone may be redirecting your connection to other, clandestine servers somewhere. Information brought to us by our Bothan spies indicate that this server may exist right under our noses: in Adams 019! (many Bothans died to bring us this information). You are to track down the location (both ip and port) of the server, then order a Star Destroyer to capture them. Hint: learn about "nmap". 5. What kind of iptables rule(s) was used to effect such redirection? Write rules that would do the same thing if you were the gateway router. 5b. EXTRA CREDIT. Figure out a way to circumvent the redirection and allow your linux host to connect to the real hofstra server, and if you're able to do so, allow others to connect through you so they can also go around the masquerader. Hint: create a tunnel. But don't use a commericial VPN unless you know what exactly it's doing. 6. In the first iptables assignment, you wrote a set of rules that blocked access to DNS servers other than those that should be used. With NAT, we can now also redirect attempts to access illegitimate servers to the ones that we approve. Write a iptables rule that redirects all attempts to access a nameserver (upd,tcp port 53) other than 10.1.0.98 to 10.1.0.98. Be careful. You need to be aware of the order in which the chains are traversed. In particular, the PREROUTING chain is checked before the INPUT chain. 7. Many firewalls block ports up to 1024 from external access, but leave higher ports open, since these ports are dynamically assigned to client-side programs. It is possible to run a server on a port that's different from the designated port - web servers sometimes run on 8080 instead of 80. With NAT you can redirect connections to open ports to locked ones. Please note that this technique can be used for vicious purposes ("man in the middle attack"). But it could also be used in valid ways. It's just a means to have finer control over your host and router. 7a. Write a iptables rule to block all TCP state NEW connections to your host on ports < 1024 from 10.2.0.0/16 (using -m conntrack). 7b. Write a rule to redirect tcp connections to port 5000 to port 22 (ssh). (read about the -j REDIRECT target in the NAT Howto). The rule for 7b will let you ssh into your host through a (external) firewall that refuses to forward ssh connections. However, you CANNOT use 7a and 7b together - it won't work. Try it and explain why it didn't work. -------------------------------------- Part II: Do it like Nat! This part of the lab asks you to conduct an experiment to determine the type of NAT that is enabled by a simple linux-based router. Most such routers implement NAT with only one rule, which is of the form: iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to eth0IP where eth0 is the interface that has the public ipaddress eth0IP. -j MASQUERADE can also be used. To understand the details of how SNAT works, you need to use the conntrack tool (apt-get install conntrack), which is a program that lets you monitor and even modify the connection tracking information kept by the OS. On some linux distributions this information is found in the file /proc/net/nf_conntrack (on the NAT box). Linux tracks each connection by storing the expected source and destination addresses and ports of both inbound and outbound packets. A notion of "connection" is imposed on UDP, even though UDP is normally considered a "connectionless" protocol. An inbound UDP packet is considered part of the same connection as the outbound packet if it matches the expected address and ports as specified in nf_conntrack, and if it comes through within a specified number of seconds (TTL). Many internet technologies such as VOIP require a capability called "NAT-Traverasal". Since hosts behind the NAT box does not even have real internet addresses, how is one supposed to contact them (initiate a connection to them)? One way is to have explicit DNAT rules on the router. But one such rule is required for each port that may require this capability. Helper protocols such as NAT-PMP and Microsoft's UPNP allow a client program on the internal network to request the NAT router to forward a port to it dynamically. But these technologies require a compliant client program as well as a compliant NAT box. NAT-PMP also elminates the role that a NAT box plays as a natural firewall. You can read the following article: http://www.securityweek.com/12-million-networking-devices-vulnerable-due-nat-pmp-issues In any case, by adding DNAT rules or by using a protocol such as NAT-PMP, we can implement what is called **FULL-CONE NAT**. Any machine can make a connection (tcp or udp) to a port that has been mapped to an internal client. Of course, keep in mind that TCP is a connection-oriented protocol, which means you cannot connect to a port that's already in use by another connection. Each tcp connection is unqiuely defined by the source and destination addresses and ports. However, in a UDP program there is no such reservation of ports. You can send a packet from the same port to multiple destinations, as well as receive packets from multiple sources. This aspect of UDP makes it more flexible than TCP, especially when we wish to traverse NAT boxes. Consider the scenario where you want someone else (first-person shooter-buddy) to connect to your machine through UDP (imagine hosting a game session), but that you are behind a NAT box and there is no explicit DNAT rule that forwards the port. The external host might still be able to "connect" to your server if your NAT box implements RESTRICTED CONE NAT or PORT-RESTRICTED CONE NAT. In such a scenario, you must send a UDP packet to the other host before they can connect to you. Since it's UDP, the other side might not even receive this packet (it's probably also behind a NAT box), but that's not important. What's important is that your local NAT box will now be expecting an incomming packet from the destination, which will then be forwarded back to you! In other words, you can entice your NAT box to forward packets to you. In RESTRICTED CONE NAT, once you send a packet to dip:dport from a source port (srport), then the host dip can send a packet to your srport, *even if it uses a different source port* than dport. With PORT-RESTRICTED CONE NAT, the return packets must also be sent from dport, which is the destination port of the enticement packet. With both forms of cone NAT, you can send enticement packets to MULTIPLE destinations from the same port, and each peer will then be able to reply to you at the same port. Usually each program will use only one source port (create one udp socket). -- The remaining form of NAT is called SYMMETRIC NAT. As opposed to the three forms of CONE NAT, if you send a packet to two different destinations from the same source port, you cannot expect BOTH destinations to reply to you, because the NAT box will map the two packets to two different ports of its own. With this form of NAT you will need an intermediate proxy or rely program. Instead of exchanging data directly between the two hosts, they will both connect to the public relay, which can easily become a bottleneck. Of course, even with (port) restricted cone NAT, the external host needs to know what port you're getting the firewall to open up. This is usually accomplished using an intermediate "broker" program, which has a public address and port. But unlike a relay program, the broker is only helping the two hosts to establish the connection. Once that's done, actual data is exchanged between the two hosts directly. ------------- Your lab exercise is to conduct an experiment to determine the type of NAT that a single generic SNAT rule implements. You will need to collaborate with other groups. Then conduct an experiment to see your firewall can be "pierced" in the manner described above. 1. First you need to simulate a NAT box using your machine. Now SNAT all packets to -o ens1 to your ip address 10.1.0.x. Now you can observe connections tracked by your NAT box with conntrack -L (or -E for realtime). for example, to look at all tracked udp "connections": conntrack -L | grep udp Now if I name you as my default router, I will be MASQUERADING myself as YOU! But don't call the FBI just yet. Set up an arrangement with another group and test your nasty NATers. You should be able, for example, to circumvent firewall rules that block out certain ip addresses. (side question: how would a firewall know that a source address was SNATed?). --- 2. Download from the class webpage the programs udpsend.c and udprecv.c compile them: gcc udpsend.c -o udpsend udp send works as follows: ./udpsend 4000 10.1.0.4 5000 This will continuously send packets from source port 4000 to destination ip 10.1.0.4 at destination port 5000. If the source port is <=1023, then a random port will be picked by the operating system. ./udprecv 5000 will continuously try to receive packets on port 5000 (--dport 5000). When it receives a packet, it prints the source ip and port of the packet. You need to devise and conduct experiments using these programs in conjunction with using conntrack (have several terminal windows open). What kind of NAT is your box implementing? Explain your experiment, report the details (address, ports used), as well as evidence to support your conclusion pasted conntrack output. Especially, INDEPENDENTLY provide evidence as to whether linux is doing RESTRICTED CONE NAT, or just PORT RESTRICTED CONE NAT Just because it's doing PRCN doesn't mean it's not doing RCN so you need to devise separate experiments to find out. -----------------