Forums

Resolved
0 votes
Hi people. I have the next problem or Vulnerability.
If I try to conect to my external IP X.X.X.X and por 22 I can't because the firewall block it.
But In the notification area I see how someone from China try to enter to My clearOS.
Then I try to conect to my external ip (I use Putty) but the mensaje is conection refuse, How did the guy to connect whitout firewall rules????

PS: The china guy can't connect because I use a secured password.
PS2: I disabled SSHD for security.

https://image.ibb.co/kdLCfw/SSH.png
Wednesday, November 08 2017, 12:40 AM
Share this post:
Responses (9)
  • Accepted Answer

    Wednesday, November 15 2017, 08:14 AM - #Permalink
    Resolved
    0 votes
    Hi Dennis,

    There are two ways which IDS can run, inside the firewall and outside the firewall and I think there is a lot of debate about which is better. ClearOS chose to run IDS outside the firewall. This means you will see intrusion attempts even though the firewall is closed. You can easily check if the firewall is closed using some of the on line port checkers such as Shields Up at grc.com (but treat some of his security stuff with a pinch of salt).

    In ClearOS, incoming WAN ports are closed by default except one or two (tcp:81 and a few others). You can check which are open by doing an "iptables -nvL INPUT" and all your ones are pretty normal apart from extended OpenVPN rules. Personally I'd also close tcp:81 and always connect by OpenVPN although to the ClearOS LAN IP. Similarly, if you wanted SSH access, I'd do it via OpenVPN to the LAN IP to avoid opening 22 on the WAN.

    If ports are shut, there is no point in running IDS on those ports. I personally would disable the SSH rules as they serve no purpose in your set up.

    Also by default all LAN traffic is allowed into ClearOS
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 15 2017, 04:46 AM - #Permalink
    Resolved
    0 votes
    I just today updated/reinstalled from ClearOS 6 to 7.

    It was literally a matter of minutes before I got hit by the same IP address trying to log in by SSH. Obviously, they are not getting through, but how do we as users 'convince' ourselves of the protections are working.

    Intrusion detection logs the attempt, but does the other active intrusion app morph the firewall rules to be more aggressive against the intruder?

    Where can I verify that root does not have access by ssh? I though that can we limit access to webmin and ssh by network adapter also- like not from the WAN side but allow from the LAN side.


    Dennis
    .
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 08 2017, 06:16 PM - #Permalink
    Resolved
    0 votes
    Perhaps you can try looking at your system log around that time:
    grep firewall: /var/log/system.*
    You just want the entries around 2017-10-09 but note that the last message could be from a few days previously.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 08 2017, 05:20 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    There is nothing wrong with those rules. :)


    How did the chinese guy to try to connect to my ClearOS by SSH?
    This happen in two servers, diferent places.
    The solution to me is down de SSH service.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 08 2017, 04:46 PM - #Permalink
    Resolved
    0 votes
    There is nothing wrong with those rules. :)
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 08 2017, 04:30 PM - #Permalink
    Resolved
    0 votes

    [root@kyt01 ~]# iptables -nvL INPUT
    Chain INPUT (policy DROP 848 packets, 53231 bytes)
    pkts bytes target prot opt in out source destination
    0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set f2b-sshd-ddos src reject-with icmp-port-unreachable
    0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set f2b-sshd src reject-with icmp-port-unreachable
    0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587,220,993,110,995 match-set f2b-postfix-sasl src reject-with icmp-port-unreachable
    199 12017 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
    0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset
    16 11724 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
    0 0 DROP all -- enp4s9 * 127.0.0.0/8 0.0.0.0/0
    0 0 DROP all -- enp4s9 * 169.254.0.0/16 0.0.0.0/0
    0 0 DROP all -- ppp0 * 127.0.0.0/8 0.0.0.0/0
    0 0 DROP all -- ppp0 * 169.254.0.0/16 0.0.0.0/0
    315 33287 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
    0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
    9879 774K ACCEPT all -- enp2s0 * 0.0.0.0/0 0.0.0.0/0
    831 24099 ACCEPT icmp -- enp4s9 * 0.0.0.0/0 0.0.0.0/0 icmptype 0
    1 156 ACCEPT icmp -- enp4s9 * 0.0.0.0/0 0.0.0.0/0 icmptype 3
    9 296 ACCEPT icmp -- enp4s9 * 0.0.0.0/0 0.0.0.0/0 icmptype 8
    0 0 ACCEPT icmp -- enp4s9 * 0.0.0.0/0 0.0.0.0/0 icmptype 11
    0 0 ACCEPT udp -- enp4s9 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
    0 0 ACCEPT tcp -- enp4s9 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
    831 24099 ACCEPT icmp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 icmptype 0
    0 0 ACCEPT icmp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 icmptype 3
    38 3388 ACCEPT icmp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 icmptype 8
    0 0 ACCEPT icmp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 icmptype 11
    0 0 ACCEPT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
    0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
    0 0 ACCEPT tcp -- * * 0.0.0.0/0 XXX.XXX.XX.XX tcp dpt:1194
    0 0 ACCEPT tcp -- * * 0.0.0.0/0 XXX.XX.XX.XXX tcp dpt:1194
    67633 18M ACCEPT udp -- * * 0.0.0.0/0 XXX.XXX.XX.XX udp dpt:1195
    0 0 ACCEPT udp -- * * 0.0.0.0/0 XXX.XX.XX.XXX udp dpt:1195
    64943 16M ACCEPT udp -- * * 0.0.0.0/0 XXX.XXX.XX.XX udp dpt:1196
    0 0 ACCEPT udp -- * * 0.0.0.0/0 XXX.XX.XX.XXX udp dpt:1196
    0 0 ACCEPT udp -- * * 0.0.0.0/0 XXX.XXX.XX.XX udp dpt:1197
    0 0 ACCEPT udp -- * * 0.0.0.0/0 XXX.XX.XX.XXX udp dpt:1197
    0 0 ACCEPT udp -- * * 0.0.0.0/0 XX.XXX.XX.XX udp dpt:1194
    0 0 ACCEPT udp -- * * 0.0.0.0/0 XX.XX.XX.XXX udp dpt:1194
    12 829 ACCEPT tcp -- * * 0.0.0.0/0 XX.XXX.XX.XX tcp dpt:81
    9 561 ACCEPT tcp -- * * 0.0.0.0/0 XX.XX.20.XXX tcp dpt:81
    0 0 ACCEPT udp -- enp4s9 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
    0 0 ACCEPT tcp -- enp4s9 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED
    3154 956K ACCEPT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
    80 54622 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED


    Thank for the help
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 08 2017, 01:38 PM - #Permalink
    Resolved
    0 votes
    By default SSH is closed in the firewall. Could you have a different rule which happens to also cover the ssh port? What is the output of:
    iptables -nvL INPUT
    Please can you put the results between "code" tags (the piece of paper icon with a <> on it).
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 08 2017, 11:41 AM - #Permalink
    Resolved
    0 votes
    This mont we change the central systems in all site. I have a los of work. When I see that a month ago I block ssh. That doest'n work, Soo i disable the sshd service.
    Now I have more time to post it :)
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 08 2017, 02:54 AM - #Permalink
    Resolved
    0 votes
    The timestamp for this is a month ago did you have SSH open a month ago? Are you just seeing these entries now and reacting to something that you closed a month ago?
    The reply is currently minimized Show
Your Reply