Posts by Gary Gapinski

Ex IT chief at Homeland Security watchdog stole US govt software to pirate

I hope they rot.

The curious case of Spamhaus, a port scanning scandal, and an apparent U-turn

TCP half-open is not legitimate

"A SYN scan, or half-open scan, waits for a SYN-ACK response from the server and if it receives a response, it does not respond. Such events generally are not logged because a TCP connection is never consummated. These port scans may be malicious reconnaissance or legitimate market and internet research, and the difference is not always obvious."

Having watched quite a bit of traffic, I'll assert that sentence #1 describes unwanted (and thus block-worthy) traffic. A "legitimate" scan would send a RST in response to the SYN-ACK, which would distinguish it from a TCP half-open attack. I recently appeared to have provoked some multiple addresses in ASN55679 to do exactly this (SYN, SYN-ACK, silence) and have since tweaked net.ipv4.tcp_synack_retries=1 and am considering 0 retries (the default is 5).

I whitelist research scans when they provide a tidy list of origins with which to so do — not all do, nor do all provide an easy way to assess the origin, such as providing an explanatory web page at the scan origin address.

Does UK high street banks' crappy crypto actually matter?

TLS compatibilities

SSL Labs has a nice comparison of user agent (TLS client) capabilities at https://www.ssllabs.com/ssltest/clients.html.

Note that all recently revised user agents can handle TLS 1.2 (obviating the need for older TLS protocols when observation of a web site's clientele demonstrates the UAs are indeed all compatible).

If one looks at individual UAs in that same comparison, it shows that recent ones can negotiate the stronger (i.e., AEAD+EDH) cipher suites. Those which cannot are likely quite old and equally likely lack the ability to negotiate TLS 1.2, and can be accommodated (if actually present in the clientele) by a configuration that offers the older, weaker, TLS protocols and cipher suites. The newer UAs will negotiate the stronger combinations.¹

As for HSTS, its use should be promoted, as it forces the web site operator to ensure that information is always delivered over TLS, and modern browser support is broad (https://caniuse.com/#search=hsts).

¹ See, e.g., https://www.ssllabs.com/ssltest/viewClient.html?name=Apple%20ATS&version=9&platform=iOS%209&key=112 for a particularly aggressive stance.

Slow IPv6 adoption is a GOOD THING as IETF plans privacy boost

Dismisinformation

NAT induces problems while providing something more than a tad short of comprehensive ingress filtering. Those who favor NAT likely favor wearing hair shirts.

DHCP and DHCPv6 are not security instruments, despite being wielded as a NAC talisman by some.

SLAAC is much easier to provide than DHCPv6. It works quite well. RFC7217 provides an improvement.

DHCPv6 is not the same as DHCP(v4). DHCPv6 can be used with or without SLAAC, and need not be used to dole out addresses.

Some common contemporary network implementations in a SLAAC environment use RFC4941 addresses, and use them preferentially.

Not all contemporary network implementations support DHCPv6: Android does not at this time (nor does it support RDNSS, so DHCPv4 is also required).

I suspect the resistance I often observe regarding IPv6 addressing, loathing of SLAAC, and devotion to DHCP, is fundamentally Calvinistic.

http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-03 is also worth reading.

Brutish SSH attacks continue to bear fruit

Rate limit

Password guessing works poorly when guesses are limited. On Linux, packet filtering can be rate sensitive using the iptables "recent" module. Coupled with a few SSH configuration directives such as

MaxStartups 1

LoginGraceTime 10s

AllowUsers <list only those necessary>

MaxAuthTries 1

PermitRootLogin no

rate-limited packet filtering can be quite effective at frustrating such attacks.

openSUSE can be configured in a single line (in /etc/sysconfig/SuSEfirewall2) to rate limit:

FW_SERVICES_ACCEPT_EXT="0.0.0.0/0,tcp,22,,hitcount=3,blockseconds=300,recentname=ssh"

This will cause SSH connections (specifically, TCP SYN packets from anywhere to port 22) from a single source in excess of three to be ignored for five minutes following the most recent. Roughly equivalent iptables directives are

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \

--update --seconds 300 --hitcount 3 -j DROP

This of course will not prevent a low-speed, distributed, determined attack, but it does keep out the riff-raff. No additional program is required (such as log watchers). Note that the packet filters are not aware if traffic is legitimate or not; one can be hoist on one's own petard.

And, by the way, security via obscurity is not effective security.