Re: [WISPA] Crude dictionary attack via ssh
I'm suprised nobody else has mentioned this... hosts.allow/hosts.deny It's simple, and dosen't depend on the firewall software to be running. hosts.deny allows you to deny access from all IPs (or specific ones) hosts.allow lets you override the deny file with the IP ranges or less securely the domain names of hosts you wish to allow. We do it on all servers, and allow SSH access only as needed. Problem prevented instead of problem solved. If staff needs to get into our servers while traveling, they can VPN into our VPN servers and then they'd have access. If it's a backend server, also consider not putting a public IP on it. We have lots of servers running 10.x IP numbers that don't need to be accessed from the Internet. Things like radio/snmp monitoring, xen hypervisors, workstations, office file servers, etc... On Fri, May 01, 2009 at 06:22:22PM -0700, Tom Sharples wrote: Spotted this a few minutes ago on one of our back-end servers. Didn't work, but worth noting. Tom S. May 2 01:05:12 QORVUS1 sshd[21728]: Illegal user lieu from 213.165.154.53 May 2 01:05:13 QORVUS1 sshd[21730]: Illegal user lilly from 213.165.154.53 May 2 01:05:15 QORVUS1 sshd[21739]: Illegal user linda from 213.165.154.53 May 2 01:05:17 QORVUS1 sshd[21751]: Illegal user ling from 213.165.154.53 May 2 01:05:18 QORVUS1 sshd[21754]: Illegal user lionel from 213.165.154.53 May 2 01:05:20 QORVUS1 sshd[21761]: Illegal user lis from 213.165.154.53 May 2 01:05:22 QORVUS1 sshd[21763]: Illegal user lisa from 213.165.154.53 May 2 01:05:22 QORVUS1 kernel: multicast May 2 01:05:23 QORVUS1 sshd[21765]: Illegal user liv from 213.165.154.53 May 2 01:05:25 QORVUS1 sshd[21768]: Illegal user liz from 213.165.154.53 May 2 01:05:26 QORVUS1 sshd[21806]: Illegal user liza from 213.165.154.53 May 2 01:05:28 QORVUS1 sshd[21808]: Illegal user loan from 213.165.154.53 May 2 01:05:30 QORVUS1 sshd[21810]: Illegal user logan from 213.165.154.53 May 2 01:05:31 QORVUS1 sshd[21812]: Illegal user lois from 213.165.154.53 May 2 01:05:33 QORVUS1 sshd[21814]: Illegal user lok from 213.165.154.53 May 2 01:05:35 QORVUS1 sshd[21817]: Illegal user loki from 213.165.154.53 May 2 01:05:37 QORVUS1 sshd[21819]: Illegal user lola from 213.165.154.53 May 2 01:05:38 QORVUS1 sshd[21821]: Illegal user long from 213.165.154.53 May 2 01:05:40 QORVUS1 sshd[21823]: Illegal user lorena from 213.165.154.53 May 2 01:05:42 QORVUS1 sshd[21825]: Illegal user lorene from 213.165.154.53 May 2 01:05:43 QORVUS1 sshd[21827]: Illegal user lorenzo from 213.165.154.53 May 2 01:05:45 QORVUS1 sshd[21830]: Illegal user lorna from 213.165.154.53 May 2 01:05:46 QORVUS1 sshd[21868]: Illegal user lotus from 213.165.154.53 May 2 01:05:48 QORVUS1 sshd[21870]: Illegal user lou from 213.165.154.53 May 2 01:05:50 QORVUS1 sshd[21881]: Illegal user louis from 213.165.154.53 May 2 01:05:51 QORVUS1 sshd[21888]: Illegal user luca from 213.165.154.53 May 2 01:05:53 QORVUS1 sshd[21891]: Illegal user lucas from 213.165.154.53 May 2 01:05:55 QORVUS1 sshd[21906]: Illegal user lucian from 213.165.154.53 May 2 01:05:56 QORVUS1 sshd[21912]: Illegal user lucky from 213.165.154.53 May 2 01:05:58 QORVUS1 sshd[21917]: Illegal user lucy from 213.165.154.53 May 2 01:05:59 QORVUS1 sshd[21921]: Illegal user ludwig from 213.165.154.53 May 2 01:06:01 QORVUS1 sshd[21923]: Illegal user luigi from 213.165.154.53 May 2 01:06:03 QORVUS1 sshd[22065]: Illegal user luis from 213.165.154.53 May 2 01:06:04 QORVUS1 sshd[22069]: Illegal user luke from 213.165.154.53 May 2 01:06:06 QORVUS1 sshd[22089]: Illegal user luna from 213.165.154.53 May 2 01:06:07 QORVUS1 sshd[22110]: Illegal user lupe from 213.165.154.53 May 2 01:06:09 QORVUS1 sshd[22112]: Illegal user luther from 213.165.154.53 May 2 01:06:11 QORVUS1 sshd[22114]: Illegal user luz from 213.165.154.53 May 2 01:06:12 QORVUS1 sshd[22116]: Illegal user ly from 213.165.154.53 May 2 01:06:14 QORVUS1 sshd[22118]: Illegal user lyn from 213.165.154.53 May 2 01:06:15 QORVUS1 sshd[22121]: Illegal user lynda from 213.165.154.53 May 2 01:06:17 QORVUS1 sshd[22123]: Illegal user lynn from 213.165.154.53 May 2 01:06:19 QORVUS1 sshd[22125]: Illegal user lysa from 213.165.154.53 May 2 01:06:20 QORVUS1 sshd[22127]: Illegal user mac from 213.165.154.53 May 2 01:06:22 QORVUS1 kernel: multicast May 2 01:06:22 QORVUS1 sshd[22129]: Illegal user macy from 213.165.154.53 May 2 01:06:24 QORVUS1 sshd[22131]: Illegal user mae from 213.165.154.53 May 2 01:06:25 QORVUS1 sshd[22134]: Illegal user pwla from 213.165.154.53 May 2 01:06:27 QORVUS1 sshd[22172]: Illegal user mama from 213.165.154.53 May 2 01:06:28 QORVUS1 sshd[22181]: Illegal user maeko from 213.165.154.53 May 2 01:06:30 QORVUS1 sshd[22190]: Illegal user magda from 213.165.154.53 May 2 01:06:32 QORVUS1 sshd[22192]: Illegal user maggie from 213.165.154.53 May 2 01:06:33 QORVUS1 sshd[22204]: Illegal user mai from 213.165.154.53 May 2
Re: [WISPA] Crude dictionary attack via ssh
Patrick, I agree with that argument but I don't think anyone here has ever seen that problem before. IPs are allocated to organizations. If you block the Chinese hacker organization then how many subs are going to be complaining about that? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 When you have eliminated the impossible, that which remains, however improbable, must be the truth. --- Sir Arthur Conan Doyle On Mon, May 4, 2009 at 9:37 AM, Patrick Shoemaker shoemak...@vectordatasystems.com wrote: Just to follow up on this thought, the main unintended consequence I had in mind was a customer running some sort of security verification suite against his/her own servers. If I were an IT employee using this sort of software from outside my network, and all of a sudden certain IPs or subnets can no longer access my company's network for some unknown reason, I would not be pleased. I would be expecting my ISP to get packets from point A to point B, not to babysit connections for me. If this feature were offered as an opt-in service, then it would be a completely different story. Of course, this probably isn't an issue at all for most residential and SMB customers. Patrick Shoemaker Vector Data Systems LLC shoemak...@vectordatasystems.com office: (301) 358-1690 x36 http://www.vectordatasystems.com Butch Evans wrote: On Sat, 2009-05-02 at 17:51 -0400, Patrick Shoemaker wrote: There's another linux program out there called BFD that does the same thing: parses logs and creates IPTABLES rules, but it doesn't use python. Google it and see if it will work for your application. Again, this is a good approach, but is (for my taste) a little to reactive. The approach that Eje was speaking of is more proactive. It is the same approach that I take when providing firewall applications to my own customers. It goes a little like this: Create a firewall for the router itself that will explicitly permit all of the traffic you wish to allow to connect via ftp or ssh. How you accomplish this is up to you. Watch for connections by ssh/ftp/other that are NOT valid. Grab the source address of those offending ssh attacks. In the firewall that protects your network, deny all traffic from those that were detected as attempting to connect to your firewall router. Watch for NEW ssh connections and set some reasonable limit for how often a specific IP may attempt a new ssh connection. You have to pick the right number here in order to prevent false positives. It's all about finding an appropriate rate of new connection attempts. If an IP trips the above set of rules, then deny them further traffic into the network. It's really not that complicated. It's not easy maybe, but not complicated. You simply have to have a router with some decent firewall capability (iptables based). Also, this might go without saying, but I'd recommend against applying any router-based rules to customer subnets. That approach is ripe for unintended consequences, and can create a troubleshooting nightmare for your customers. I disagree. Done right, you don't have unintended consequences. And even if you do, it's rather easy to take care of those as they come up. WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Crude dictionary attack via ssh
Very simple effective fix if you have iptables: iptables -A INPUT -p tcp --dport 22 -s your_subnet/21 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j LOG --log-prefix 'SSH attack: ' iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP Replace your subnet with the IP pool you never want to block. After its working do 'service iptables save' to save it. This stopped all problems like this for me. Matt Spotted this a few minutes ago on one of our back-end servers. Didn't work, but worth noting. Tom S. May 2 01:05:12 QORVUS1 sshd[21728]: Illegal user lieu from 213.165.154.53 May 2 01:05:13 QORVUS1 sshd[21730]: Illegal user lilly from 213.165.154.53 May 2 01:05:15 QORVUS1 sshd[21739]: Illegal user linda from 213.165.154.53 May 2 01:05:17 QORVUS1 sshd[21751]: Illegal user ling from 213.165.154.53 May 2 01:05:18 QORVUS1 sshd[21754]: Illegal user lionel from 213.165.154.53 May 2 01:05:20 QORVUS1 sshd[21761]: Illegal user lis from 213.165.154.53 May 2 01:05:22 QORVUS1 sshd[21763]: Illegal user lisa from 213.165.154.53 May 2 01:05:22 QORVUS1 kernel: multicast May 2 01:05:23 QORVUS1 sshd[21765]: Illegal user liv from 213.165.154.53 May 2 01:05:25 QORVUS1 sshd[21768]: Illegal user liz from 213.165.154.53 May 2 01:05:26 QORVUS1 sshd[21806]: Illegal user liza from 213.165.154.53 May 2 01:05:28 QORVUS1 sshd[21808]: Illegal user loan from 213.165.154.53 May 2 01:05:30 QORVUS1 sshd[21810]: Illegal user logan from 213.165.154.53 May 2 01:05:31 QORVUS1 sshd[21812]: Illegal user lois from 213.165.154.53 May 2 01:05:33 QORVUS1 sshd[21814]: Illegal user lok from 213.165.154.53 May 2 01:05:35 QORVUS1 sshd[21817]: Illegal user loki from 213.165.154.53 May 2 01:05:37 QORVUS1 sshd[21819]: Illegal user lola from 213.165.154.53 May 2 01:05:38 QORVUS1 sshd[21821]: Illegal user long from 213.165.154.53 May 2 01:05:40 QORVUS1 sshd[21823]: Illegal user lorena from 213.165.154.53 May 2 01:05:42 QORVUS1 sshd[21825]: Illegal user lorene from 213.165.154.53 May 2 01:05:43 QORVUS1 sshd[21827]: Illegal user lorenzo from 213.165.154.53 May 2 01:05:45 QORVUS1 sshd[21830]: Illegal user lorna from 213.165.154.53 May 2 01:05:46 QORVUS1 sshd[21868]: Illegal user lotus from 213.165.154.53 May 2 01:05:48 QORVUS1 sshd[21870]: Illegal user lou from 213.165.154.53 May 2 01:05:50 QORVUS1 sshd[21881]: Illegal user louis from 213.165.154.53 May 2 01:05:51 QORVUS1 sshd[21888]: Illegal user luca from 213.165.154.53 May 2 01:05:53 QORVUS1 sshd[21891]: Illegal user lucas from 213.165.154.53 May 2 01:05:55 QORVUS1 sshd[21906]: Illegal user lucian from 213.165.154.53 May 2 01:05:56 QORVUS1 sshd[21912]: Illegal user lucky from 213.165.154.53 May 2 01:05:58 QORVUS1 sshd[21917]: Illegal user lucy from 213.165.154.53 May 2 01:05:59 QORVUS1 sshd[21921]: Illegal user ludwig from 213.165.154.53 May 2 01:06:01 QORVUS1 sshd[21923]: Illegal user luigi from 213.165.154.53 May 2 01:06:03 QORVUS1 sshd[22065]: Illegal user luis from 213.165.154.53 May 2 01:06:04 QORVUS1 sshd[22069]: Illegal user luke from 213.165.154.53 May 2 01:06:06 QORVUS1 sshd[22089]: Illegal user luna from 213.165.154.53 May 2 01:06:07 QORVUS1 sshd[22110]: Illegal user lupe from 213.165.154.53 May 2 01:06:09 QORVUS1 sshd[22112]: Illegal user luther from 213.165.154.53 May 2 01:06:11 QORVUS1 sshd[22114]: Illegal user luz from 213.165.154.53 May 2 01:06:12 QORVUS1 sshd[22116]: Illegal user ly from 213.165.154.53 May 2 01:06:14 QORVUS1 sshd[22118]: Illegal user lyn from 213.165.154.53 May 2 01:06:15 QORVUS1 sshd[22121]: Illegal user lynda from 213.165.154.53 May 2 01:06:17 QORVUS1 sshd[22123]: Illegal user lynn from 213.165.154.53 May 2 01:06:19 QORVUS1 sshd[22125]: Illegal user lysa from 213.165.154.53 May 2 01:06:20 QORVUS1 sshd[22127]: Illegal user mac from 213.165.154.53 May 2 01:06:22 QORVUS1 kernel: multicast May 2 01:06:22 QORVUS1 sshd[22129]: Illegal user macy from 213.165.154.53 May 2 01:06:24 QORVUS1 sshd[22131]: Illegal user mae from 213.165.154.53 May 2 01:06:25 QORVUS1 sshd[22134]: Illegal user pwla from 213.165.154.53 May 2 01:06:27 QORVUS1 sshd[22172]: Illegal user mama from 213.165.154.53 May 2 01:06:28 QORVUS1 sshd[22181]: Illegal user maeko from 213.165.154.53 May 2 01:06:30 QORVUS1 sshd[22190]: Illegal user magda from 213.165.154.53 May 2 01:06:32 QORVUS1 sshd[22192]: Illegal user maggie from 213.165.154.53 May 2 01:06:33 QORVUS1 sshd[22204]: Illegal user mai from 213.165.154.53 May 2 01:06:35 QORVUS1 sshd[22214]: Illegal user maia from 213.165.154.53 May 2 01:06:36 QORVUS1 sshd[0]: Illegal user makoto from 213.165.154.53 May 2 01:06:38 QORVUS1 sshd[3]: Illegal user mallory from 213.165.154.53 May 2 01:06:40 QORVUS1
Re: [WISPA] Crude dictionary attack via ssh
Just to follow up on this thought, the main unintended consequence I had in mind was a customer running some sort of security verification suite against his/her own servers. If I were an IT employee using this sort of software from outside my network, and all of a sudden certain IPs or subnets can no longer access my company's network for some unknown reason, I would not be pleased. I would be expecting my ISP to get packets from point A to point B, not to babysit connections for me. If this feature were offered as an opt-in service, then it would be a completely different story. Of course, this probably isn't an issue at all for most residential and SMB customers. Patrick Shoemaker Vector Data Systems LLC shoemak...@vectordatasystems.com office: (301) 358-1690 x36 http://www.vectordatasystems.com Butch Evans wrote: On Sat, 2009-05-02 at 17:51 -0400, Patrick Shoemaker wrote: There's another linux program out there called BFD that does the same thing: parses logs and creates IPTABLES rules, but it doesn't use python. Google it and see if it will work for your application. Again, this is a good approach, but is (for my taste) a little to reactive. The approach that Eje was speaking of is more proactive. It is the same approach that I take when providing firewall applications to my own customers. It goes a little like this: Create a firewall for the router itself that will explicitly permit all of the traffic you wish to allow to connect via ftp or ssh. How you accomplish this is up to you. Watch for connections by ssh/ftp/other that are NOT valid. Grab the source address of those offending ssh attacks. In the firewall that protects your network, deny all traffic from those that were detected as attempting to connect to your firewall router. Watch for NEW ssh connections and set some reasonable limit for how often a specific IP may attempt a new ssh connection. You have to pick the right number here in order to prevent false positives. It's all about finding an appropriate rate of new connection attempts. If an IP trips the above set of rules, then deny them further traffic into the network. It's really not that complicated. It's not easy maybe, but not complicated. You simply have to have a router with some decent firewall capability (iptables based). Also, this might go without saying, but I'd recommend against applying any router-based rules to customer subnets. That approach is ripe for unintended consequences, and can create a troubleshooting nightmare for your customers. I disagree. Done right, you don't have unintended consequences. And even if you do, it's rather easy to take care of those as they come up. WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Crude dictionary attack via ssh
I was thinking of the case where the IT person is running the security audit tool from a trusted network, like a branch office or their home connection. Probably an obscure case. But annoying if a customer ever gets burned by it. My philosophy is that the ISP should be responsible for the most basic network-level protections, such as uRPF enforcement, blocking RFC1918 address space, etc. Any fiddling above layer 3 should be done on an opt-in basis. This is what works for my customer base (no residential), YMMV. Not saying it's what should be done in every case. Patrick Shoemaker Vector Data Systems LLC shoemak...@vectordatasystems.com office: (301) 358-1690 x36 http://www.vectordatasystems.com Josh Luthman wrote: Patrick, I agree with that argument but I don't think anyone here has ever seen that problem before. IPs are allocated to organizations. If you block the Chinese hacker organization then how many subs are going to be complaining about that? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 When you have eliminated the impossible, that which remains, however improbable, must be the truth. --- Sir Arthur Conan Doyle On Mon, May 4, 2009 at 9:37 AM, Patrick Shoemaker shoemak...@vectordatasystems.com wrote: Just to follow up on this thought, the main unintended consequence I had in mind was a customer running some sort of security verification suite against his/her own servers. If I were an IT employee using this sort of software from outside my network, and all of a sudden certain IPs or subnets can no longer access my company's network for some unknown reason, I would not be pleased. I would be expecting my ISP to get packets from point A to point B, not to babysit connections for me. If this feature were offered as an opt-in service, then it would be a completely different story. Of course, this probably isn't an issue at all for most residential and SMB customers. Patrick Shoemaker Vector Data Systems LLC shoemak...@vectordatasystems.com office: (301) 358-1690 x36 http://www.vectordatasystems.com Butch Evans wrote: On Sat, 2009-05-02 at 17:51 -0400, Patrick Shoemaker wrote: There's another linux program out there called BFD that does the same thing: parses logs and creates IPTABLES rules, but it doesn't use python. Google it and see if it will work for your application. Again, this is a good approach, but is (for my taste) a little to reactive. The approach that Eje was speaking of is more proactive. It is the same approach that I take when providing firewall applications to my own customers. It goes a little like this: Create a firewall for the router itself that will explicitly permit all of the traffic you wish to allow to connect via ftp or ssh. How you accomplish this is up to you. Watch for connections by ssh/ftp/other that are NOT valid. Grab the source address of those offending ssh attacks. In the firewall that protects your network, deny all traffic from those that were detected as attempting to connect to your firewall router. Watch for NEW ssh connections and set some reasonable limit for how often a specific IP may attempt a new ssh connection. You have to pick the right number here in order to prevent false positives. It's all about finding an appropriate rate of new connection attempts. If an IP trips the above set of rules, then deny them further traffic into the network. It's really not that complicated. It's not easy maybe, but not complicated. You simply have to have a router with some decent firewall capability (iptables based). Also, this might go without saying, but I'd recommend against applying any router-based rules to customer subnets. That approach is ripe for unintended consequences, and can create a troubleshooting nightmare for your customers. I disagree. Done right, you don't have unintended consequences. And even if you do, it's rather easy to take care of those as they come up. WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ WISPA Wants You! Join today! http://signup.wispa.org/
Re: [WISPA] Crude dictionary attack via ssh
On Mon, 2009-05-04 at 09:37 -0400, Patrick Shoemaker wrote: Just to follow up on this thought, the main unintended consequence I had in mind was a customer running some sort of security verification suite against his/her own servers. If I were an IT employee using this sort of software from outside my network, and all of a sudden certain IPs or subnets can no longer access my company's network for some unknown reason, I would not be pleased. I would be expecting my ISP to get packets from point A to point B, not to babysit connections for me. While I agree that this scenario is an accurate example of one that would create a false positive to the method I use, it is a stretch to call it normal. I'd bet that if we took a poll here, that we'd find that over 90% (maybe more) of the customer base represented is residential. Additionally, I suspect that at least 80% of the business accounts represented here would not create a false positive. This leaves only 2% in the at risk category. It's a very small risk, in my opinion. Furthermore, I've installed this type of solution at the headend of at least 80 networks. Some of these have been running for at least 2 years. I have yet to hear a complaint from my customers (the ISPs). I think that if we assume the 2% number above is accurate (it may be very high), that it is worth the risk to prevent the propagation of this attack mechanism. That's what these things do, by the way. Once a successful login occurs, that machine becomes a bot that is performing the ssh attack itself. Not only does it do that, but it is a likely host to become a spambot as well. It may be that your specific situation makes this approach the wrong choice. If it does, I can only say that your network is an exception and not the rule in this case. -- * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/* Network Engineering * * http://www.wispa.org/ * WISPA Board Member * * http://blog.butchevans.com/ * Wired or Wireless Networks * WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Crude dictionary attack via ssh
It's a flavor of Slack Linux. Don't have Python on these boxes so am writing a bash script to do essentially the same thing as DenyHosts. Tom S. - Original Message - From: Rogelio scubac...@gmail.com To: Tom Sharples tsharp...@qorvus.com; WISPA General List wireless@wispa.org Sent: Friday, May 01, 2009 10:53 PM Subject: Re: [WISPA] Crude dictionary attack via ssh Tom Sharples wrote: Spotted this a few minutes ago on one of our back-end servers. Didn't work, but worth noting. Which OS are you running? WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Crude dictionary attack via ssh
Tom Sharples wrote: It's a flavor of Slack Linux. Don't have Python on these boxes so am writing a bash script to do essentially the same thing as DenyHosts. You run iptables on this box? You might have some options there, as well. WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Crude dictionary attack via ssh
Tom Sharples wrote: It's a flavor of Slack Linux. Don't have Python on these boxes so am writing a bash script to do essentially the same thing as DenyHosts. Here's an idea that might work too, assuming you have iptables on that box http://www.e18.physik.tu-muenchen.de/~tnagel/ipt_recent/ WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Crude dictionary attack via ssh
On Fri, 2009-05-01 at 18:36 -0700, Tom Sharples wrote: This works too :-) iptables -A INPUT -s 213.165.154.53/24 -j DROP It does for sure. The only problem is that this one host is not the only one to be concerned about. If you have a router at the border of the network that has the capability of watching the network for this type of behaviour and responding to it, then I'd suggest adding that function there. The denyhosts script that Josh suggested works, but it is a reactive script. In other words, it watches the log file and does what you suggest automatically. At least that's what I saw the first time I looked at it. A better approach is the one that Eje suggested. His suggestion uses a router (probably Mikrotik in his case) that watches for this behaviour and drops all traffic from this host automatically. You can do this with Mikrotik, ImageStream or any other OS that includes iptables and the recent module. It's not even that hard to do. -- * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/* Network Engineering * * http://www.wispa.org/ * WISPA Board Member * * http://blog.butchevans.com/ * Wired or Wireless Networks * WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Crude dictionary attack via ssh
There's another linux program out there called BFD that does the same thing: parses logs and creates IPTABLES rules, but it doesn't use python. Google it and see if it will work for your application. Also, this might go without saying, but I'd recommend against applying any router-based rules to customer subnets. That approach is ripe for unintended consequences, and can create a troubleshooting nightmare for your customers. -- Patrick Shoemaker President, Vector Data Systems LLC shoemak...@vectordatasystems.com office: (301) 358-1690 x36 http://www.vectordatasystems.com Tom Sharples wrote: I'm writing a reactive bash script this weekend to take care of the problem. Can't load python on these embedded servers, or I'd just use the denyhosts script Josh and George suggested. The idea of generating a common database of offending IPs to propagate to all our servers is a good one too, that will be in Version 2 :-) Thanks, Tom S. - Original Message - From: Butch Evans but...@butchevans.com To: Tom Sharples tsharp...@qorvus.com; WISPA General List wireless@wispa.org Sent: Saturday, May 02, 2009 12:18 PM Subject: Re: [WISPA] Crude dictionary attack via ssh On Fri, 2009-05-01 at 18:36 -0700, Tom Sharples wrote: This works too :-) iptables -A INPUT -s 213.165.154.53/24 -j DROP It does for sure. The only problem is that this one host is not the only one to be concerned about. If you have a router at the border of the network that has the capability of watching the network for this type of behaviour and responding to it, then I'd suggest adding that function there. The denyhosts script that Josh suggested works, but it is a reactive script. In other words, it watches the log file and does what you suggest automatically. At least that's what I saw the first time I looked at it. A better approach is the one that Eje suggested. His suggestion uses a router (probably Mikrotik in his case) that watches for this behaviour and drops all traffic from this host automatically. You can do this with Mikrotik, ImageStream or any other OS that includes iptables and the recent module. It's not even that hard to do. -- * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/* Network Engineering * * http://www.wispa.org/ * WISPA Board Member * * http://blog.butchevans.com/ * Wired or Wireless Networks * WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Crude dictionary attack via ssh
On Sat, 2009-05-02 at 17:51 -0400, Patrick Shoemaker wrote: There's another linux program out there called BFD that does the same thing: parses logs and creates IPTABLES rules, but it doesn't use python. Google it and see if it will work for your application. Again, this is a good approach, but is (for my taste) a little to reactive. The approach that Eje was speaking of is more proactive. It is the same approach that I take when providing firewall applications to my own customers. It goes a little like this: Create a firewall for the router itself that will explicitly permit all of the traffic you wish to allow to connect via ftp or ssh. How you accomplish this is up to you. Watch for connections by ssh/ftp/other that are NOT valid. Grab the source address of those offending ssh attacks. In the firewall that protects your network, deny all traffic from those that were detected as attempting to connect to your firewall router. Watch for NEW ssh connections and set some reasonable limit for how often a specific IP may attempt a new ssh connection. You have to pick the right number here in order to prevent false positives. It's all about finding an appropriate rate of new connection attempts. If an IP trips the above set of rules, then deny them further traffic into the network. It's really not that complicated. It's not easy maybe, but not complicated. You simply have to have a router with some decent firewall capability (iptables based). Also, this might go without saying, but I'd recommend against applying any router-based rules to customer subnets. That approach is ripe for unintended consequences, and can create a troubleshooting nightmare for your customers. I disagree. Done right, you don't have unintended consequences. And even if you do, it's rather easy to take care of those as they come up. -- * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/* Network Engineering * * http://www.wispa.org/ * WISPA Board Member * * http://blog.butchevans.com/ * Wired or Wireless Networks * WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Crude dictionary attack via ssh
Josh Luthman wrote: Install DenyHosts and those go away. ditto http://denyhosts.sourceforge.net/ http://denyhosts.sourceforge.net/faq.html http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts DenyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks). If you've ever looked at your ssh log (/var/log/secure on Redhat, /var/log/auth.log on Mandrake, etc...) you may be alarmed to see how many hackers attempted to gain access to your server. Hopefully, none of them were successful (but then again, how would you know?). Wouldn't it be better to automatically prevent that attacker from continuing to gain entry into your system? WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Crude dictionary attack via ssh
This works too :-) iptables -A INPUT -s 213.165.154.53/24 -j DROP Tom S. - Original Message - From: Josh Luthman j...@imaginenetworksllc.com To: Tom Sharples tsharp...@qorvus.com; WISPA General List wireless@wispa.org Sent: Friday, May 01, 2009 6:25 PM Subject: Re: [WISPA] Crude dictionary attack via ssh Install DenyHosts and those go away. On 5/1/09, Tom Sharples tsharp...@qorvus.com wrote: Spotted this a few minutes ago on one of our back-end servers. Didn't work, but worth noting. Tom S. May 2 01:05:12 QORVUS1 sshd[21728]: Illegal user lieu from 213.165.154.53 May 2 01:05:13 QORVUS1 sshd[21730]: Illegal user lilly from 213.165.154.53 May 2 01:05:15 QORVUS1 sshd[21739]: Illegal user linda from 213.165.154.53 May 2 01:05:17 QORVUS1 sshd[21751]: Illegal user ling from 213.165.154.53 May 2 01:05:18 QORVUS1 sshd[21754]: Illegal user lionel from 213.165.154.53 May 2 01:05:20 QORVUS1 sshd[21761]: Illegal user lis from 213.165.154.53 May 2 01:05:22 QORVUS1 sshd[21763]: Illegal user lisa from 213.165.154.53 May 2 01:05:22 QORVUS1 kernel: multicast May 2 01:05:23 QORVUS1 sshd[21765]: Illegal user liv from 213.165.154.53 May 2 01:05:25 QORVUS1 sshd[21768]: Illegal user liz from 213.165.154.53 May 2 01:05:26 QORVUS1 sshd[21806]: Illegal user liza from 213.165.154.53 May 2 01:05:28 QORVUS1 sshd[21808]: Illegal user loan from 213.165.154.53 May 2 01:05:30 QORVUS1 sshd[21810]: Illegal user logan from 213.165.154.53 May 2 01:05:31 QORVUS1 sshd[21812]: Illegal user lois from 213.165.154.53 May 2 01:05:33 QORVUS1 sshd[21814]: Illegal user lok from 213.165.154.53 May 2 01:05:35 QORVUS1 sshd[21817]: Illegal user loki from 213.165.154.53 May 2 01:05:37 QORVUS1 sshd[21819]: Illegal user lola from 213.165.154.53 May 2 01:05:38 QORVUS1 sshd[21821]: Illegal user long from 213.165.154.53 May 2 01:05:40 QORVUS1 sshd[21823]: Illegal user lorena from 213.165.154.53 May 2 01:05:42 QORVUS1 sshd[21825]: Illegal user lorene from 213.165.154.53 May 2 01:05:43 QORVUS1 sshd[21827]: Illegal user lorenzo from 213.165.154.53 May 2 01:05:45 QORVUS1 sshd[21830]: Illegal user lorna from 213.165.154.53 May 2 01:05:46 QORVUS1 sshd[21868]: Illegal user lotus from 213.165.154.53 May 2 01:05:48 QORVUS1 sshd[21870]: Illegal user lou from 213.165.154.53 May 2 01:05:50 QORVUS1 sshd[21881]: Illegal user louis from 213.165.154.53 May 2 01:05:51 QORVUS1 sshd[21888]: Illegal user luca from 213.165.154.53 May 2 01:05:53 QORVUS1 sshd[21891]: Illegal user lucas from 213.165.154.53 May 2 01:05:55 QORVUS1 sshd[21906]: Illegal user lucian from 213.165.154.53 May 2 01:05:56 QORVUS1 sshd[21912]: Illegal user lucky from 213.165.154.53 May 2 01:05:58 QORVUS1 sshd[21917]: Illegal user lucy from 213.165.154.53 May 2 01:05:59 QORVUS1 sshd[21921]: Illegal user ludwig from 213.165.154.53 May 2 01:06:01 QORVUS1 sshd[21923]: Illegal user luigi from 213.165.154.53 May 2 01:06:03 QORVUS1 sshd[22065]: Illegal user luis from 213.165.154.53 May 2 01:06:04 QORVUS1 sshd[22069]: Illegal user luke from 213.165.154.53 May 2 01:06:06 QORVUS1 sshd[22089]: Illegal user luna from 213.165.154.53 May 2 01:06:07 QORVUS1 sshd[22110]: Illegal user lupe from 213.165.154.53 May 2 01:06:09 QORVUS1 sshd[22112]: Illegal user luther from 213.165.154.53 May 2 01:06:11 QORVUS1 sshd[22114]: Illegal user luz from 213.165.154.53 May 2 01:06:12 QORVUS1 sshd[22116]: Illegal user ly from 213.165.154.53 May 2 01:06:14 QORVUS1 sshd[22118]: Illegal user lyn from 213.165.154.53 May 2 01:06:15 QORVUS1 sshd[22121]: Illegal user lynda from 213.165.154.53 May 2 01:06:17 QORVUS1 sshd[22123]: Illegal user lynn from 213.165.154.53 May 2 01:06:19 QORVUS1 sshd[22125]: Illegal user lysa from 213.165.154.53 May 2 01:06:20 QORVUS1 sshd[22127]: Illegal user mac from 213.165.154.53 May 2 01:06:22 QORVUS1 kernel: multicast May 2 01:06:22 QORVUS1 sshd[22129]: Illegal user macy from 213.165.154.53 May 2 01:06:24 QORVUS1 sshd[22131]: Illegal user mae from 213.165.154.53 May 2 01:06:25 QORVUS1 sshd[22134]: Illegal user pwla from 213.165.154.53 May 2 01:06:27 QORVUS1 sshd[22172]: Illegal user mama from 213.165.154.53 May 2 01:06:28 QORVUS1 sshd[22181]: Illegal user maeko from 213.165.154.53 May 2 01:06:30 QORVUS1 sshd[22190]: Illegal user magda from 213.165.154.53 May 2 01:06:32 QORVUS1 sshd[22192]: Illegal user maggie from 213.165.154.53 May 2 01:06:33 QORVUS1 sshd[22204]: Illegal user mai from 213.165.154.53 May 2 01:06:35 QORVUS1 sshd[22214]: Illegal user maia from 213.165.154.53 May 2 01:06:36 QORVUS1 sshd[0]: Illegal user makoto from 213.165.154.53 May 2 01:06:38 QORVUS1 sshd[3]: Illegal user mallory from 213.165.154.53 May 2 01:06:40 QORVUS1 sshd[5]: Illegal user mandy from 213.165.154.53 May 2 01:06:41 QORVUS1 sshd[7]: Illegal user marc from 213.165.154.53 May 2 01:06:43 QORVUS1
Re: [WISPA] Crude dictionary attack via ssh
Those attacks been going on for years now. I create on our core router long time back that will detect successive new ssh connections and block the source ip for 30minutes. Works very well. /Eje Sent via BlackBerry from T-Mobile -Original Message- From: Tom Sharples tsharp...@qorvus.com Date: Fri, 1 May 2009 18:22:22 To: WISPA General Listwireless@wispa.org Subject: [WISPA] Crude dictionary attack via ssh Spotted this a few minutes ago on one of our back-end servers. Didn't work, but worth noting. Tom S. May 2 01:05:12 QORVUS1 sshd[21728]: Illegal user lieu from 213.165.154.53 May 2 01:05:13 QORVUS1 sshd[21730]: Illegal user lilly from 213.165.154.53 May 2 01:05:15 QORVUS1 sshd[21739]: Illegal user linda from 213.165.154.53 May 2 01:05:17 QORVUS1 sshd[21751]: Illegal user ling from 213.165.154.53 May 2 01:05:18 QORVUS1 sshd[21754]: Illegal user lionel from 213.165.154.53 May 2 01:05:20 QORVUS1 sshd[21761]: Illegal user lis from 213.165.154.53 May 2 01:05:22 QORVUS1 sshd[21763]: Illegal user lisa from 213.165.154.53 May 2 01:05:22 QORVUS1 kernel: multicast May 2 01:05:23 QORVUS1 sshd[21765]: Illegal user liv from 213.165.154.53 May 2 01:05:25 QORVUS1 sshd[21768]: Illegal user liz from 213.165.154.53 May 2 01:05:26 QORVUS1 sshd[21806]: Illegal user liza from 213.165.154.53 May 2 01:05:28 QORVUS1 sshd[21808]: Illegal user loan from 213.165.154.53 May 2 01:05:30 QORVUS1 sshd[21810]: Illegal user logan from 213.165.154.53 May 2 01:05:31 QORVUS1 sshd[21812]: Illegal user lois from 213.165.154.53 May 2 01:05:33 QORVUS1 sshd[21814]: Illegal user lok from 213.165.154.53 May 2 01:05:35 QORVUS1 sshd[21817]: Illegal user loki from 213.165.154.53 May 2 01:05:37 QORVUS1 sshd[21819]: Illegal user lola from 213.165.154.53 May 2 01:05:38 QORVUS1 sshd[21821]: Illegal user long from 213.165.154.53 May 2 01:05:40 QORVUS1 sshd[21823]: Illegal user lorena from 213.165.154.53 May 2 01:05:42 QORVUS1 sshd[21825]: Illegal user lorene from 213.165.154.53 May 2 01:05:43 QORVUS1 sshd[21827]: Illegal user lorenzo from 213.165.154.53 May 2 01:05:45 QORVUS1 sshd[21830]: Illegal user lorna from 213.165.154.53 May 2 01:05:46 QORVUS1 sshd[21868]: Illegal user lotus from 213.165.154.53 May 2 01:05:48 QORVUS1 sshd[21870]: Illegal user lou from 213.165.154.53 May 2 01:05:50 QORVUS1 sshd[21881]: Illegal user louis from 213.165.154.53 May 2 01:05:51 QORVUS1 sshd[21888]: Illegal user luca from 213.165.154.53 May 2 01:05:53 QORVUS1 sshd[21891]: Illegal user lucas from 213.165.154.53 May 2 01:05:55 QORVUS1 sshd[21906]: Illegal user lucian from 213.165.154.53 May 2 01:05:56 QORVUS1 sshd[21912]: Illegal user lucky from 213.165.154.53 May 2 01:05:58 QORVUS1 sshd[21917]: Illegal user lucy from 213.165.154.53 May 2 01:05:59 QORVUS1 sshd[21921]: Illegal user ludwig from 213.165.154.53 May 2 01:06:01 QORVUS1 sshd[21923]: Illegal user luigi from 213.165.154.53 May 2 01:06:03 QORVUS1 sshd[22065]: Illegal user luis from 213.165.154.53 May 2 01:06:04 QORVUS1 sshd[22069]: Illegal user luke from 213.165.154.53 May 2 01:06:06 QORVUS1 sshd[22089]: Illegal user luna from 213.165.154.53 May 2 01:06:07 QORVUS1 sshd[22110]: Illegal user lupe from 213.165.154.53 May 2 01:06:09 QORVUS1 sshd[22112]: Illegal user luther from 213.165.154.53 May 2 01:06:11 QORVUS1 sshd[22114]: Illegal user luz from 213.165.154.53 May 2 01:06:12 QORVUS1 sshd[22116]: Illegal user ly from 213.165.154.53 May 2 01:06:14 QORVUS1 sshd[22118]: Illegal user lyn from 213.165.154.53 May 2 01:06:15 QORVUS1 sshd[22121]: Illegal user lynda from 213.165.154.53 May 2 01:06:17 QORVUS1 sshd[22123]: Illegal user lynn from 213.165.154.53 May 2 01:06:19 QORVUS1 sshd[22125]: Illegal user lysa from 213.165.154.53 May 2 01:06:20 QORVUS1 sshd[22127]: Illegal user mac from 213.165.154.53 May 2 01:06:22 QORVUS1 kernel: multicast May 2 01:06:22 QORVUS1 sshd[22129]: Illegal user macy from 213.165.154.53 May 2 01:06:24 QORVUS1 sshd[22131]: Illegal user mae from 213.165.154.53 May 2 01:06:25 QORVUS1 sshd[22134]: Illegal user pwla from 213.165.154.53 May 2 01:06:27 QORVUS1 sshd[22172]: Illegal user mama from 213.165.154.53 May 2 01:06:28 QORVUS1 sshd[22181]: Illegal user maeko from 213.165.154.53 May 2 01:06:30 QORVUS1 sshd[22190]: Illegal user magda from 213.165.154.53 May 2 01:06:32 QORVUS1 sshd[22192]: Illegal user maggie from 213.165.154.53 May 2 01:06:33 QORVUS1 sshd[22204]: Illegal user mai from 213.165.154.53 May 2 01:06:35 QORVUS1 sshd[22214]: Illegal user maia from 213.165.154.53 May 2 01:06:36 QORVUS1 sshd[0]: Illegal user makoto from 213.165.154.53 May 2 01:06:38 QORVUS1 sshd[3]: Illegal user mallory from 213.165.154.53 May 2 01:06:40 QORVUS1 sshd[5]: Illegal user mandy from 213.165.154.53 May 2 01:06:41 QORVUS1 sshd[7]: Illegal user marc from 213.165.154.53 May 2 01:06:43 QORVUS1 sshd[9]: Illegal user marcel from 213.165.154.53 May 2 01:06:44 QORVUS1 sshd[22232]: Illegal user marco from 213.165.154.53 May 2
Re: [WISPA] Crude dictionary attack via ssh
I do it on my core router and block their ip access to any service on my entire network and not just ssh on the linux box itself but any other possible attack vector they might throw on any system with public ip. Don't think that they will only attack and test ssh ports. /Eje Sent via BlackBerry from T-Mobile -Original Message- From: Rogelio scubac...@gmail.com Date: Fri, 01 May 2009 18:31:41 To: WISPA General Listwireless@wispa.org Subject: Re: [WISPA] Crude dictionary attack via ssh Josh Luthman wrote: Install DenyHosts and those go away. ditto http://denyhosts.sourceforge.net/ http://denyhosts.sourceforge.net/faq.html http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts DenyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks). If you've ever looked at your ssh log (/var/log/secure on Redhat, /var/log/auth.log on Mandrake, etc...) you may be alarmed to see how many hackers attempted to gain access to your server. Hopefully, none of them were successful (but then again, how would you know?). Wouldn't it be better to automatically prevent that attacker from continuing to gain entry into your system? WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Crude dictionary attack via ssh
Tom Sharples wrote: Spotted this a few minutes ago on one of our back-end servers. Didn't work, but worth noting. Which OS are you running? WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
