Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Should I be concerned?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Should I be concerned?

SimpleNodeSimpleNode Member
edited August 2012 in Help

Decided to run netstat on our first node, got this:

hax

It seems like this single IP is connecting to the SSH port of all of our clients servers. Should I be concerned?
I'm assuming they're trying to get into the SSH or something.

Comments

  • AlexBarakovAlexBarakov Patron Provider, Veteran

    Just nullroute it
    iptables -A INPUT -s x.x.x.x -j DROP

    Thanked by 1risharde
  • SimpleNodeSimpleNode Member
    edited August 2012

    @Alex_LiquidHost
    Done that, still there.

    I'm assuming I have to reload/restart iptables, however doesn't that break the network for a split second?

  • SimpleNodeSimpleNode Member
    edited August 2012

    @Jack said: I messaged Netrouting on skype for you :)

    Huh? What?

    EDIT: Oh right, that's the ISP for that IP.

  • AlexBarakovAlexBarakov Patron Provider, Veteran

    You shouldn't have to restart the iptables for this to take effect. You can ask your provider to block the IP for you at upper level.

  • @Alex_LiquidHost said: Just nullroute it

    iptables -A INPUT -s x.x.x.x -j DROP

    Thats not nullrouting, thats dropping the packets. Nullrouting is done on the routing level, as the name implies :P

    Thanked by 2klikli risharde
  • AlexBarakovAlexBarakov Patron Provider, Veteran

    @gsrdgrdghd said: Thats not nullrouting, thats dropping the packets. Nullrouting is done on the routing level, as the name implies :P

    route add -host IP-ADDRESS reject ?

    I think that the IPTABLES should work as well on this issue.

    Thanked by 1risharde
  • KuJoeKuJoe Member, Host Rep
    edited August 2012

    @SimpleNode said: Done that, still there.

    The connections will still happen but the IP won't get a reply. After you run the iptables command it can take a while before the attacker realizes he isn't getting a response anymore and stops the attack.

    If you do an iftop you'll notice that the packet size for the connections is now 0 meaning no data is being returned when they initiate a connection.

    Here's a script I used to use one our OpenVZ nodes before we could blackhole at the router level:

    iptables -A FORWARD -i eth0 -s $1 -j DROP iptables -A INPUT -i eth0 -s $1 -j DROP cp /etc/sysconfig/iptables /etc/sysconfig/iptables.bak echo '$1 dropped @date' >> /var/log/ipdrop.log

    All you need to do is put this script in your /usr/bin directory (we call it ipdrop) and to use it just use the following command:

    ipdrop 1.1.1.1

    Not sure why we have a FORWARD and an INPUT line but we got the iptables commands from OpenVZ.org and they worked really well so I didn't question it.

  • KuroKuro Member

    @KuJoe said: Not sure why we have a FORWARD and an INPUT line

    The FORWARD rule will drop packets destined to any of the CTs, but not the host.
    The INPUT rule will drop packets destined to the host but not any of the CTs.

  • KuJoeKuJoe Member, Host Rep

    @Kuro said: The FORWARD rule will drop packets destined to any of the CTs, but not the host.

    The INPUT rule will drop packets destined to the host but not any of the CTs.

    Thanks for the info. iptables has always been something that I never really understood (particularly with OpenVZ). I just Google my way around it as needed.

  • Additionally, I wrote a script (detailed here: http://www.lowendtalk.com/discussion/4185/sshcheck.php-blocking-ssh-bruteforce-attempts-against-client-vps-containers ) that run as a cron task and automatically add iptables DROP lines for source IPs that have gone over a specified threshold of connections (I think the script defaults to 15).

    Let me know if you'd like the most recent version of it. Most recent version ensures that the IP is not already in the iptables chains. (so you don't get many emails for the same IP while waiting for the connection to time out)

  • TazTaz Member

    @Damian said: Let me know if you'd like the most recent version of it. Most recent version ensures that the IP is not already in the iptables chains. (so you don't get many emails for the same IP while waiting for the connection to time out)

    Go for it.

  • raindog308raindog308 Administrator, Veteran

    A lot of iptables recipes have an early rule that jumps to ACCEPT for any ESTABLISHED connections.

Sign In or Register to comment.