1. Cosc 5/4765 Protecting against ssh attacks And is this secure?

2. Protecting against ssh attacks The Idea: –1. Stop script kiddies constant attacks against the ssh server –2. Stop/slow down password cracking via ssh. –IE make things more secure. Or at least this is the plan. The Plan: –giving a number of failed login attempts from a given IP in a given time, block them for a period of time (or forever).

3. SSH “Religious” issues. The extreme “Right” ssh people, believe that the only way to login is via –public/private key login only. –NO Passwords allowed. The problems: –the keys must be installed before it can be used. Every machine and user most have those keys –Can you see the problems here?

4. How? Install a program to check the logs –DaemonShield or something like it. or watch the tcp connections –PortSentry or something like it. Write my own?! –Not happening.

5. Implementation PortSentry turns out to not work and to complex to fix. Move to the “simpler” concept of using the failed logins via the logs. –Get DaemonShield (from sourceforge)‏ First problem: Not being maintained anymore. Second problem: Still beta, but manageable. But is Redhat Ent compliant. –uses Python.

6. DaemonShield Simple program –written in Python. –Pretty configurable Set how often to check the logs (every 5 seconds)‏ How long to into history to use (30 minutes)‏ How many failures before blocking (2 is default)‏ How long offending IP is block (1 hour is default)‏ So if an user in the last 30 minutes fails to login twice, they their ip is blocked for 1 hour. –Compile and install

7. DaemonShield (2)‏ –Configured up Change to 5 minutes history, 4 logins failures and blocked for 30 minutes add a couple of other things. See Demo –and started it. Testing (not a production system)‏ Fail to login from a system –only 2 failed login and get blocked (?)‏ –wait 10 minutes try again, except still blocked Works except… –Says I have 4 failed logins in the last 0 minutes –That’s a problem.

8. fixing problems. Check and reconfigure daemonshield –still no joy, system is still blocked (45 minutes later!) with only 2 failed logins check logs –SSHD has registered 4 failed logins! –SSHD registered 2 failed logins with time stamps of GMT (+7 hours) and 2 with MDT

9. The Hunt Search the Internet… Oh joy! findings and Multiple known sshd bugs 1. sshd has been put into a chroot –problem, doesn’t understand Timezone data correctly –https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203 671 2. Due to a bug fix where sshd was not loggin correctly, a new bug was introduced causing it to log some things twice! –both the parent process and child process now log. »And (I think) the child doesn’t get the Timezone correct.

10. Attempting to fix First the duplicate logging can’t be fixed by me –Wait for sshd people to issue fix. –double failed login number in daemonshield Hope I remember when sshd is patched.

11. Attempting to fix (2)‏ Second, timezone issues. –multiple fixes for this one copy the /etc/timezone file into /var/empty/ssh/etc/ directory –Consistency problems will happen! –TZdata is updated every couple of months, so these files will get out sync Link /var/empty/sshd/etc/localtime to /etc/timezone –Soft link? –Hard link?

12. Linking So sshd is chroot in it’s own directories –Linking either through soft link localtime --> /etc/localtime –Hard link creates a second inode link to the /etc/localtime file And /etc/localtime is a softlink to the correct timezone as well. What problems have been created?

13. One more issue DaemonShield –Adds an extra logging feature So all attempts from offending IP while it is blocked will now be logged Adds to the log files and makes them bigger Not really what I want. –Edit Python Remove the lines to create the logging in iptables

14. Update SSHD fixed logging –Only logs once for every attempt timezone issues. –On every startup sshd now copies the /etc/timezone file into /var/empty/ssh/etc/ directory

15. Now the real question. By doing all of this How we made the system more secure?

16. Q A &