UDP tunneling is an attack that is often overlooked when manufacturers design wireless hotspot and other firewall/proxy based devices.
When you try and resolve a domain name, you make a request to a name server on UDP port 53. The way that a lot of wireless hotspot, firewalls and proxies work, is that your DNS request is allowed out, you get the IP for the machine you’re looking for, and then your request to the IP is redirected to the wireless hotspot login page, or through a web proxy server.
The problem is, that all port 53 UDP traffic is allowed out to anywhere, without any kind of authentication. You can therefore install OpenVPN on a remote server which by default listens in on UDP port 1194. You can change this with one configuration option to 53, and then edit your client config to connect to the server on port 53 instead. Often, other TCP/UDP ports might be allowed out, and ICMP is also sometimes a possibility. It is possible to easily tunnel your data out over TCP, UDP or ICMP as a worst case.
This type of attack worked on 5 out of 6 different wireless hotspot systems to gain access without authentication.
The one that it didn’t work on, captured all outbound 53 UDP requests, and silently redirected them to it’s own local DNS server. This is simple enough to do, so I’m not sure why more manufacturers haven’t done the same. Using iptables:
${IPTABLES} -t nat -A PREROUTING -i eth0 -p udp -m udp –dport 53 -j REDIRECT –to-port 53
These are the same type of rules used to configure transparent proxying for Squid.
Tags: 53, firewall, hotspot, iptables, openvpn, squid, transparent proxying, udp, udp tunneling
Full NAT, DNAT and SNAT aka 1:1 NAT, 1 to 1 NAT – this is used when you want to map a dedicated external IP on an external interface to another IP on a separate interface with everything routed between them.
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -i ${EXTERNAL_IF} -d ${EXTERNAL_IP} -j DNAT –to-destination ${INTERNAL_IP}
iptables -t nat -A POSTROUTING -o ${EXTERNAL_IF} -s ${INTERNAL_IP} -j SNAT –to-source ${EXTERNAL_IP}
route add -host ${EXTERNAL_IP} ${INTERNAL_IF}
arp -Ds ${EXTERNAL_IP} ${INTERNAL_IF}
Tags: dnat, iptables, nat, route, snat
Quite a while back, I posted article http://www.adamsinfo.com/extending-tc-and-iproute2-linux-routing-split-access-multiple-uplinks-multiple-isps-iptables-masquerading/
The article focuses on using the standard iproute2 tool to allow the box to attempt to balance traffic over multiple uplinks with multiple default routes. While relatively easy to set up, it has a few problems:
I’ve recently decided to give this a go in netfilter purely. My environment is a router with a number of LAN devices, with eth0 being the LAN interface (192.168.1.0/24), while eth1 and eth2 are separate ISP links with public IPs.
(more…)
Tags: balancer, connmark, conntrack, dnat, icmp, iproute2, iptables, load balancing, mark, netfilter, snat, split access, tcp, udp
As a Linux Security Freelancer, I’m often asked where best to start when securing a single linux host. Whereas most would suggest configuring iptables or similar, the most effective first step in my opinion is to remove unnecessary services.
There are a number of methods that you can use to show open sockets at least:
lsof -U will list open sockets
nmap -sT -sU localhost will scan your local machine for open TCP or UDP ports
netstat -a | grep LISTEN will show all listening sockets.
Forgive me for stating the obvious, but the first thing to do is disable any open sockets or services that aren’t required. On a default install, this could include the likes of the portmapper service, identd and an smtpd.
Next, you want to suitably lock down user accounts, check passwords, and perhaps consider enforcing a secure password policy, at minimum I generally prefer at least 8 characters, at least one uppercase, one lowercase and one integer. Obviously this shouldn’t be easily guessible, nor should it just end in a ‘1′.
Once done, the next thing that you want to do is to suitably firewall the services that you do require open, and perhaps also restrict the rate of ICMPs, etc, with iptables.
(more…)
Tags: buffer overflow, freelancer, icmp, identd, iptables, Linux, linux security freelancer, lsof, netstat, nmap, node, ping, portmapper, root, security, Security Consultant, setuid, smtpd, suid
Port Knocking is a clever and interesting method of allowing remote firewall manipulation whilst leaving all ports closed to all IPs. When I attempt to initiate a TCP connection to a remote host I send a packet with a ‘SYN’ flag, indicating my intention, along with other information such as a source port, destination port, source IP and destination IP. The target machine has the option of responding by accepting, responding by rejecting, or simply ignoring the packet alltogether, known under iptables and most other firewalls as ACCEPT, REJECT or DROP.
(more…)
Tags: accept, connection, drop, firewall, IP, iptables, port, port knocking, protocol, reject, source ip, syn, target, tcp
Here’s a really quick rundown on setting up masquerading. You’d use this to share one internet connection between multiple local network machines. It’s what most regular ‘routers’ that your ISP sends out do and it’s really easy to set up under Linux in it’s most simplest form
(more…)
Tags: iptables, ip_forward, Linux, masquerade, masquerading, modprobe, nat, postrouting
Here’s a quick guide that I write as I’m setting up PPTP/MPPE/MPPC on a Linux server. My preferred VPN technology is OpenVPN mainly because it’s so quick and easy to set up and use, however in some cases PPTP is required chiefly when the Client wants to use the inbuilt Windows VPN capabilities rather than having to deploy 3rd party software.
My server is a Debian (of course) etch machine, with 2.6.24 (from source) kernel. My client is Windows XP Pro SP3.
(more…)
Tags: 2.6.24, debian, iptables, kernel, Linux, masquerade, mppc, mppe, patch, ppp, pppd, pptp, pptpd, VPN
There are a number of reasons why you might want to use Squid in transparent mode, I won’t go into them – I’ll just explain how!
In Squid versions before 2.6, you’ll want to edit your configuration to specify:
In 2.6 versions and beyond, you can append ‘transparent’ to the end of your http_port option, i.e.:
Squid will now be ready for transparent proxying. Now create some iptables rules to push all outbound port 80 traffic through squid:
eth0 is the local side of your router, –dport 80 specifies a destination port of 80 (HTTP) and we’re going to redirect it to 3128 where your Squid proxy runs.
Tags: iptables, redirect, squid, transparent proxy
I’ve used OpenWrt previously to this project to build some firmwards for the Linksys Router WRT54 range. OpenWrt is an incredibly powerful and small Linux distro. Although debian is probably better suited to the reasonably powerful hardware, I wanted to give OpenWrt a go anyway.
Unless you’re running a MIPS 4Kc processor on your host which I’m guessing you’re not, you’ll either need to cross compile your binaries, or just compile them natively on the device itself. Compiling on the device works fine as long as you have the relevant packages, however if I was going to build a 2.6 kernel, I’d rather do it on an x86 quad core intel host, rather than waiting a week for the device to do it. I also wanted to minimize the writes on the CF card.
OpenWrt comes with a nice buildroot environment which you can read about and download from www.openwrt.org using Subversion.
Here http://downloads.openwrt.org/kamikaze/docs/openwrt.html#x1-310002 is a great HOWTO on getting the build root environment set up on your x86 host.
Also, see: http://wiki.mikrotik.com/wiki/RB500_Linux_SDK – this is a very complete HOWTO, which is why I’ve not covered most of the installation process and just detailed customizations.
You’ll need to select the RB5xx target for the kernel. Also, run:
In your build root top directory, and add USB support (as my one is modded for USB which is not RB5xx default.
While you’re there, browse to the networking options and make sure you have everything you want, specifically the schedulers for traffic shaping.
Here is my precompiled image:
Tags: /dev/cfa1, /dev/cfa2, /dev/cfa3, bridge, build root, buildroot, debian, dropbear, ifconfig, iptables, kamikaze, mikrotik, miniupnp, miniupnpd, mips 4kc, multiple isps, multiple providers, ntp, ntp client, openwrt, precompiled image, rb532a, rbxxx, split route, subversion, svn kernel, uplink, usb, usb support, x86
Following on from the previous article, I’ve written some scripts which you’ll find in the /root/scripts/ directory of the prebuilt image. I’ve attached and commented them here, as they could also be useful elsewhere.
bridge.sh #For setting up a simple bridge
(more…)
Tags: 532a, APNIC Box, bandwidth management, bandwidth rate, bridge, cbq, ifconfig, iproute2, iptables, lcd, Linux, picolcd, qdisc, routerboard, routerboard 532a, shaping, tc, time, usblcd, usleep