I'm tempted to flag this as a duplicate since there have been several questions like this asked before, but you ask for specific security-centric things. Therefore in the spirit of helping:
There is an active security audit that's ongoing during every release cycle. It also contains good advice about some basic security measures that are already in place specifically to harden and test your system against unwanted external access.
Configuration
No Open Ports
Password hashing
SYN cookies
Subsystems
- Configurable Firewall
- Filesystem Capabilities
- PR_SET_SECCOMP
Mandatory Access Control (MAC)
Filesystem encryption
Userspace Hardening
- Stack Protector
- Heap Protector
- Pointer Obfuscation
- Address Space Layout Randomisation (ASLR)
- Built as PIE
- Built with Fortify Source
- Built with RELRO
- Built with BIND_NOW
- Non-Executable Memory
- /proc/$pid/maps protection
- Symlink restrictions
- Hardlink restrictions
- ptrace scope
Kernel Hardening
- 0-address protection
- /dev/mem protection
- /dev/kmem disabled
- Block module loading
- Read-only data sections
- Stack protector
- Module RO/NX
- Kernel Address Display Restriction
- Blacklist Rare Protocols
- Syscall Filtering
With the list of existing protections in place, lets examine the rest of your question:
- In relation to Logging connection attempts, this has been covered, and if you want something simpler to configure there is always fail2ban or denyhosts.
- When watching configurations for modifications, there is AppArmor.
- As far as indicating on TCP/IP Stack hardening, you would need data to validate the necessity of performing this, but for the paranoid there is a good post on the advantages of blocking SYN flooding. But as you'll notice from the security audit link above, SYN Cookies is enabled by default, and helps mitigate this out of the box.
So it appears that all you really need to do at this point, is ensure the extra applications you may/may not be installing are undergoing active security audits and that you are current with any patches. Have installed any extra AppArmor profiles required to secure your customizations. (or SELinux additions, respective to your particular configuration)
How to detect a SYN attack
It is very simple to detect SYN attacks. The netstat command shows us how many connections are currently in the half-open state. The half-open state is described as SYN_RECEIVED in Windows and as SYN_RECV in Unix systems.
# netstat -n -p TCP tcp 0 0 10.100.0.200:21
237.177.154.8:25882 SYN_RECV - tcp 0 0 10.100.0.200:21
236.15.133.204:2577 SYN_RECV - tcp 0 0 10.100.0.200:21
127.160.6.129:51748 SYN_RECV - tcp 0 0 10.100.0.200:21
230.220.13.25:47393 SYN_RECV - tcp 0 0 10.100.0.200:21
We can also count how many half-open connections are in the backlog queue at the
moment. In the example below, 769 connections (for TELNET) in the SYN RECEIVED state
are kept in the backlog queue.
# netstat -n -p TCP | grep SYN_RECV | grep :23 | wc -l 769
The other method for detecting SYN attacks is to print TCP statistics and
look at the TCP parameters which count dropped connection requests. While under
attack, the values of these parameters grow rapidly.
# netstat -s -P tcp | grep tcpHalfOpenDrop tcpHalfOpenDrop = 473
It is important to note that every TCP port has its own backlog queue, but only
one variable of the TCP/IP stack controls the size of backlog queues for all ports.