fail2ban attack

February 26, 2008 Leave a comment

I was talking about fail2ban running from my firewall and a certain IP being the only one allowed in (as specified in iptables).  First of all, I should probably be using port knocking or something better for this scenario (in fact, after the comment I went ahead and put spa on the firewalls – something I’ve been meaning to do anyway for awhile now) but that’s beside the point.

fail2ban works by denying an ip address for x amount of time because of failed logins.  It does this by using log entries from /var/log/auth.log and writing corresponding iptables rules.  This is mostly for limiting ssh login failures.

If you spoofed the ipaddress of the machine I was logging in from, you could maybe launch a dos by getting the legitimate machine banned. Realistically, I think the attack would not succeed.  Here’s what would happen.

  1. An attacker sends a spoofed connection packet to my firewall with a legitimate ip address (so it makes it through my dummy firewall)
  2. The ssh server responsds with a syn/ack to the correct ip address (not the attacker)
  3. The correct ip address doesn’t know where this came from, so either drops it or sends a RST packet if there are no firewall controls on the sender machine.

The point is that the handshake is never completed, so there is never a failed login entry in /var/log/auth, and it never gets so far as to fail2ban.

 

Filed under Pentest Tagged with , , , ,

Unintended consequences of half open scans

February 21, 2008 Leave a comment

Short analysis of the nmap half open scans (also called syn scans).

These scans are distinguished from the default operation of full connection scans, which completes the full tcp handshake. i.e.

SYN –>
<—SYN+ACK
ACK–>

A half open scan just does

SYN–>
<–SYN+ACK

The scanner determines weather the port is up or not based on if the SYN+ACK comes back.  Obviously, the final ack is never sent back.  This can be performed by

$ nmap -P0 -sS target

This was a popular method due to it being ‘stealthy’ though it’s not so much stealthy anymore and because it’s fast – though it doesn’t seem to be faster than a full connection scan in practice.

Anyways, now to something everyone doesn’t already know (maybe, at least I didn’t).

nmap uses raw sockets to craft these packets, which is why syn scans must be run as root.  What’s interesting is that if the remote host responds with a SYN+ACK – the local stack receives this packet, which did not come from the local stack (because again, it was crafted with a raw socket by nmap).  As far as the scanning computer knows, the SYN+ACK is not part of a handshake and appears to have come out of nowhere, so the scanner sends a RST back to the target system.  Nuts.

You can stop this by using simple iptables, on INPUT or OUTPUT, by having a default drop policy (only allowing ESTABLISHED,RELATED and known services through is probably a good rule of thumb).

Filed under Pentest Tagged with , ,

Build a Bridge and Get Over it

November 6, 2007 Leave a comment

In my environment, the best kind of firewall is the bridge kind of firewall. Meaning: a transparent kind of firewall. Here’s how I generally set them up.

So, I don’t have control of the gateway routers. I have IP addresses all over the place in my little IP pool. For example I have one little server room with a 134.50.7.24 a 134.50.7.88 and a 134.50.7.244. What I want is a firewall complete with IDP to limit access to stuff in a centralized way. BTW, I also tend to have firewalls on every machine, I guess for the double layer of protection. Firewalls are sort of like condoms. Double layering doesn’t seem to help that much, but it couldn’t hurt. And either way, once you’re penetrated, you’re fucked.

To clarify, what I want is something completely invisible to the outside. As far as the outside is concerned, there is nothing there. In fact, this could be the case as far as the inside is concerned. However, you may want to give the bridge an IP address and let something through so you can ssh in to fix whatever problems.

So:

Network —– Bridge ——switch —Internal Network of various IPs

The cool thing about a bridge is you can stick it anywhere and it won’t change how any of your other hosts are hooked up.

For this task, I chose everyone’s favorite os, Linux. I also chose a minimalist version of Ubuntu since I heart ubuntu. This is actually a pretty trivial thing to set up.

# apt-get install bridge-utils

Then you want to create a new bridge device and add your ethx to it. Your ethx will obviously probably be eth0, eth1, eth2 or whatever network devices you want on the bridge.

# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# ip link set br0 up

Now guess what. You’ve now turned your $300 machine into a $10 hub.

Next if you want to give your bridge an ip address and a route:

# ip addr add x.x.x.x/x brd + dev br0
# route add default gw x.x.x.x dev br0

Where x is your ip and your subnet and gateway.

I find as I’m writing this I’m just repeating what else is out there. Go and read http://www.linuxjournal.com/article/8172 and it will show you the way.

Now that you’ve got your bridge working you can filter traffic using ebtables (on the hardware level) and iptables (on the ip level) and snort and whatever. There are tons of examples of this online, so I won’t bore you here. Awesome.

Put all this in rc.local or whatever boot up script so that your system remembers everything and you’re golden! To all those people who say “just use smoothwall and don’t worry about iptables” in your face! smoothwall/ipcop/monowall are all pretty cool, but being a transparent bridge isn’t one of the things they are capable of out of the box. They are mostly meant to be gateways or whatever.

Filed under Pentest Tagged with , , , ,