[XCSSA] Re: July 16th Meeting Ideas?

[xcssa@xcssa.org]

--Fba/0zbH8Xs+Fj9o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Oh, another possible topic is network security, particularly about
firewalls.  For example:

1) Do you know why the TCP sequence number should be randomized, and
that most OSes get it wrong?  The pf packet filter can randomize the
sequence numbers as they pass through, transparently.

2) That one can often blindly reset active TCP connections by forging
many TCP RST packets with various sequence numbers, so that one will
eventually land within the "window" of acceptable sequence numbers?

3) Do you know that if you don't randomize your IP IDs (some OSes use
a counter), that your system could be used to remotely scan a third
party?  The pf packet filter can randomize them on the way through.

4) A single TCP SYN packet can identify the OS you are using.

5) The TCP timestamp field can be used to identify individual
   internal hosts behind NAT, and can identify what OS it is
   running.  PS: It is NOT the system clock.  Again, pf adds
   a small random constant to this to prevent problems.

6) That clock skew in the TCP timestamps can be used to fingerprint
   remote network hosts, even laptops that change location and IP
   addresses. Even if they run NTP.

7) That the path MTU can be used to discern information like how many
   VPN links your packets are crossing.  pf can limit the MSS to a
   certain maximum value.

8) That fragments can bypass network intrusion detection systems.
   See fragroute.  pf can reassemble fragments before forwarding
   them, reducing ambiguity.

9) That your TTL can give away how many hops you are from the
   remote system (and a rough guess at your OS).  pf can force
   the TTL to a minimum value as the packets through.

10) If your firewall sends back ICMP unreach or TCP RSTs, the
    TTLs on these can give away that it never made it to the
    end system.

11) Did you know that you need to open both TCP and UDP for
    port 53 for DNS?  UDP alone is not enough, though it work
    in most cases.  TCP is not just for zone transfers, either.

12) Did I mention I like pf?

This last bit can come in handy in defense too; for example, suppose
someone nmaps you with decoy scans.  They are smart enough they didn't
use pings (-P0), or OS fingerprinting (-O is not cloaked by decoys)
and their ISP doesn't do egress filtering (so the decoy scans get
through), so now you have several streams of packets.  Assume that you
have symmetric routing, or if there is asymmetry the number of hops is
similar, and that traceroutes get reasonably close to the source IPs.

Well, what I do is run traceroutes back to those IPs.  If any send
back an ICMP net unreach or host unreach, I can usually rule those
out.  Then I get a rough idea of how many hops it should be, and then
add that to the TTLs I observe, and see if they're close to the
default TTL of an OS.  If it's not, or if the OS isn't consistent with
the fingerprint of the connections (again, passive TCP fingerprinting
is invaluable here), I can generally rule it out.

If normal UDP traceroute doesn't work, I try sending to port 53.  If
that fails, I try TCP traceroutes to port 53 and 80.  And it's even
possible to geolocate the IP, in some cases - and I'm not talking
about the city/state of their ISP, I'm talking about GPS coordinates,
possibly a street address.  For their particular IP, not their ISP.

--=20
"That is not dead which can eternal lie, and with strange aeons even
 death may die." - H.P. Lovecraft, The Call of the Cthulhu
<URL:https://www.subspacefield.org/~travis/> -><- dharma <>< advaita
For a good time on my UBE blacklist, email john@subspacefield.org.

--Fba/0zbH8Xs+Fj9o
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (OpenBSD)

iQIVAwUBRpLoRWQVZZEDJt9HAQKuIBAAjb5jIi6P7rpn6F/ox7sgUd+Cj/FwkBd9
vHGt0k35Ehjdpf64HE82PpMLQFF1qnCUNd49OHA4QLb77BBJ+GLGJNflzPCBz9n3
z6MVoOQobbnjkcp4QVM10jAggJmQE0x99an+O7ufvsxThp0aeSIbIS/W0wtqz1r3
9vJgZmbMNfE/kE/ns9pPfT+++epUNAUbptRiMpRk/8i/SjUPmdWZUwFLCJVWhhwC
cDmvklbueflnoWXqAaQ5V1akpnKianorBi7bm99AlI5/LIZ2u5kVs1Y5Gn8hbkV2
GWnU/gQlurn4OaFfpdrgOg0SLfbRZ4K9fxL2P0UkTw48cN3tLUZEhq9wTKdXHf74
nnteEzcpJiSGBOEuE06bYMZYxWEkIbENm9CTyFtPAvhYneNe0aw/G3tnpfqGNcsf
MoOmq8DzuTZaSPkl6MFKZg2uMZu6hbdBpCpe87fNkUIrA3yHOZ721XLsMaaI7Viz
8EdkEbk3Me6cHtz8JwG0z5RYgn0fR6dyTnAjwJiBfuKYjQd82wFSNBllCThTLRws
C00upKHiHMah8/qbeN6rVZ3cCwkuMezR+0IzK+Vdo+DgPJD6qb3k+a54uXvdIgA2
NMxVdnDW6yL6Il4SqWgHfYN9itL1dbUOX5m48unCfisK5IfvNt/EjN8HmG8MaD6M
HJSI6EAIeqY=
=vHM4
-----END PGP SIGNATURE-----

--Fba/0zbH8Xs+Fj9o--