Forums

Resolved
0 votes
Hello folks!

I've been having some fun with ClearOS 6.4 on a brand new Atom system.

So far, I've never been able to get an IP to show up on the blocked list under Gateway > Intrusion Prevention. I've tried running a dozen portscans and even figured out how to run BruteSSH from an external IP. In searching the forums, I've read how "Snortsam" might not be working quite right in 6.4, and therefore I might not be getting ANY IP blocks. Is there a setting or something I'm not doing right? Any help/suggestions/information/links to other reading material would be GREATLY appreciated.

I'm considering purchasing some subscriptions for the IPS updates, but this malfunction (if it even is one) has me paused. :unsure:

Details:
- Clean install of ClearOS 6.4 onto brand new hardware.
- Gateway mode is enabled between ETH0 (external) and ETH1 (LAN)
- Intrusion Prevention shows as "running"
- Intrusion Detection shows as "running"
- I've tried rebooting the server entirely and running my simulated attacks again, but still nothing shows up.
- I just did a "yum upgrade" and everything is already up to date (there were no updates).
-

Thank you!
Tony
Friday, July 05 2013, 08:23 PM
Share this post:
Responses (30)
  • Accepted Answer

    Friday, July 05 2013, 09:28 PM - #Permalink
    Resolved
    0 votes
    It really depends which rules you run with. The default set is pretty old and does not contain many block rules - have a look at the various rules files for any rule with "fwsam" towards the end:
    grep fwsam /etc/snort.d/rules/gpl/*.rules -c
    They hardly ever trigger for me.
    If you want more block rules have a look at the various rules available from the Emerging Threats site. Also consider modifying rules on your own. Remember most things (e.g.not pings) are blocked by default.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, July 05 2013, 11:37 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:
    It really depends which rules you run with. The default set is pretty old and does not contain many block rules - have a look at the various rules files for any rule with "fwsam" towards the end:
    grep fwsam /etc/snort.d/rules/gpl/*.rules -c
    They hardly ever trigger for me.
    If you want more block rules have a look at the various rules available from the Emerging Threats site. Also consider modifying rules on your own. Remember most things (e.g.not pings) are blocked by default.


    Makes more sense now! Thank you!

    This is what I got back from that command, so it seems what you're saying applies to what I'm seeing, in that there aren't many rules going to snortsam:

    /etc/snort.d/rules/gpl/attack_response.rules:2
    /etc/snort.d/rules/gpl/chat.rules:0
    /etc/snort.d/rules/gpl/dns.rules:3
    /etc/snort.d/rules/gpl/exploit.rules:35
    /etc/snort.d/rules/gpl/ftp.rules:4
    /etc/snort.d/rules/gpl/icmp_info.rules:0
    /etc/snort.d/rules/gpl/imap.rules:1
    /etc/snort.d/rules/gpl/misc.rules:7
    /etc/snort.d/rules/gpl/netbios.rules:6
    /etc/snort.d/rules/gpl/p2p.rules:3
    /etc/snort.d/rules/gpl/pop3.rules:5
    /etc/snort.d/rules/gpl/rpc.rules:3
    /etc/snort.d/rules/gpl/scan.rules:10
    /etc/snort.d/rules/gpl/shellcode.rules:15
    /etc/snort.d/rules/gpl/smtp.rules:2
    /etc/snort.d/rules/gpl/snmp.rules:0
    /etc/snort.d/rules/gpl/sql.rules:29
    /etc/snort.d/rules/gpl/tftp.rules:4
    /etc/snort.d/rules/gpl/web_client.rules:0
    /etc/snort.d/rules/gpl/web_server.rules:17
    /etc/snort.d/rules/gpl/web_specific_apps.rules:1

    Thanks for your help!
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, July 06 2013, 06:23 AM - #Permalink
    Resolved
    0 votes
    So...I've downloaded and configured Snort to use the rules from Emerging Threats, but I still don't see any evidence of IP blocking. I've been running portscans and packet generators all night, and so far nothing gets blocked.

    I don't get why snort and snortsam aren't working together. I could have sworn in 5.2, IP blocks would happen and show, where as in 6.4, nothing...

    Any other ideas?
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, July 06 2013, 06:26 AM - #Permalink
    Resolved
    0 votes
    I just ran snortsam at the command line, and noticed some errors (this is a clean ClearOS 6.4 install):

    SnortSam, v 2.69.
    Copyright (c) 2001-2009 Frank Knobbe <frank@knobbe.us>. All rights reserved.

    Plugin 'fwsam': v 2.5, by Frank Knobbe
    Plugin 'fwexec': v 2.7, by Frank Knobbe
    Plugin 'pix': v 2.9, by Frank Knobbe
    Plugin 'ciscoacl': v 2.12, by Ali Basel <alib@sabanciuniv.edu>
    Plugin 'cisconullroute': v 2.5, by Frank Knobbe
    Plugin 'cisconullroute2': v 2.2, by Wouter de Jong <maddog2k@maddog2k.net>
    Plugin 'netscreen': v 2.10, by Frank Knobbe
    Plugin 'ipchains': v 2.8, by Hector A. Paterno <apaterno@dsnsecurity.com>
    Plugin 'iptables': v 2.9, by Fabrizio Tivano <fabrizio@sad.it>, Luis Marichal <luismarichal@gmail.com>
    Plugin 'ebtables': v 2.4, by Bruno Scatolin <ipsystems@uol.com.br>
    Plugin 'watchguard': v 2.7, by Thomas Maier <thomas.maier@arcos.de>
    Plugin 'email': v 2.12, by Frank Knobbe
    Plugin 'email-blocks-only': v 2.12, by Frank Knobbe
    Plugin 'snmpinterfacedown': v 2.3, by Ali BASEL <ali@basel.name.tr>
    Plugin 'forward': v 2.8, by Frank Knobbe

    Parsing config file /etc/snortsam.conf...
    Linking plugin 'iptables'...
    Parsing config file /etc/snortsam.d/whitelist.conf...
    Parsing config file /etc/snortsam.d/dns-whitelist.conf...
    Error: [/etc/snortsam.conf: 51] Config file '/etc/snortsam.d/clearcenter-whitelist.conf' not found or inaccessible!
    Error: [/etc/snortsam.conf: 52] Config file '/etc/snortsam.d/webconfig-whitelist.conf' not found or inaccessible!

    Parsing config file /etc/snortsam.d/system-autowhitelist.conf...
    Checking for existing state file "/var/db/snortsam.state".
    Found. Reading state file.
    Error: Could not bind socket.

    Exiting SnortSam...
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, July 06 2013, 08:26 AM - #Permalink
    Resolved
    0 votes
    If the file does not exist you can try creating it:
    touch /etc/snortsam.d/clearcenter-whitelist.conf
    Which ET rules did you use and do they show any blocks? Note there are specific block rule sets available from ET at http://rules.emergingthreats.net/blockrules/. When choosing the rule sets you have to be very careful not to choose overlapping rule sets or snort will fail. I chose my block rules from the link just posted and normal rules from http://rules.emergingthreats.net/open-nogpl/snort-2.9.0/rules/ but I am fairly selective and do not bother with rules for services I do not expose to the WAN. See the ET FAQ's to get an idea about the various rule sets.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, July 06 2013, 05:55 PM - #Permalink
    Resolved
    0 votes
    Holy sh*t!!! I created blank .conf files for the two it was missing, and all of the sudden, EVERYTHING WORKS!!

    Sounds like a bug that needs to be filed...

    Thanks Nick!
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, July 06 2013, 06:32 PM - #Permalink
    Resolved
    0 votes
    Also - for anyone reading this thread and is curious, I followed this script for 6.3, and it worked for 6.4. This is for updating Snort rules from Emerging Threats:

    http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,40/func,view/id,18341/limit,10/limitstart,110/#51354
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, July 06 2013, 06:55 PM - #Permalink
    Resolved
    0 votes
    I've just appended to that post because of a setting error.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, July 08 2013, 05:57 PM - #Permalink
    Resolved
    0 votes
    I said everything was working, but so far, I've only seen it ever block ONE IP.

    So I set logging to verbose in snortsam.conf, and noticed this today:

    2013/07/07, 10:58:31, -, 2, snortsam, Removing 86400 sec complete block for host 46.165.208.105.
    2013/07/07, 10:58:31, -, 1, iptables, Info: UnBlocking ip 46.165.208.105
    2013/07/07, 10:58:31, -, 3, iptables, Info: Command /sbin/iptables -D FORWARD -i eth0 -s 46.165.208.105 -j DROP Executed Successfully
    2013/07/07, 10:58:31, -, 3, iptables, Info: Command2 /sbin/iptables -D INPUT -i eth0 -s 46.165.208.105 -j DROP Executed Successfully
    2013/07/07, 10:58:31, -, 3, iptables, Error: Command /sbin/iptables -D FORWARD -i eth0 -d 46.165.208.105 -j DROP Failed
    2013/07/07, 10:58:31, -, 1, iptables, Error: Command2 /sbin/iptables -D INPUT -i eth0 -d 46.165.208.105 -j DROP Failed

    My main concern is whether that particular IP was actually blocked by iptables. It looks like it did, and this action where errors occurred was the unblocking process. But I'm not entirely sure.

    Bug? Expected behavior? Thoughts?

    Maybe this bug fixed in 5.1? http://tracker.clearfoundation.com/view.php?id=20
    The reply is currently minimized Show
  • Accepted Answer

    Monday, July 08 2013, 08:45 PM - #Permalink
    Resolved
    0 votes
    It looks like the first two delete commands worked so the subsequent failed as there was no rule left to unblock.

    You can look at the firewall with
    iptables -L -n -v
    Generally the snortsam rules are at or near the top of each section (chain).
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, July 10 2013, 04:26 PM - #Permalink
    Resolved
    0 votes
    Hello all,

    This has become a huge problem in my opinion. The GPL rules in the default snort ruleset are old and fairly useless - 500-ish rules that haven't been really updated in 5 years. If you aren't running with ClearCenter's Intrusion Protection app (13,000+ rules updated weekly/monthly) or hacking in Emerging Threats rules, then you are probably just wasting RAM and CPU cycles running with IDS/IPS.

    Personally, I would like to see the Intrusion Detection and Intrusion Prevention apps hidden from Marketplace -- it's doing more harm than good having these apps listed. Even with User Guide pages and a "tooltip" in the web interface, we still see a lot of inbound "IDS/IPS is not working" questions. I'm not trying to pick on you Tony, I'm like everyone else and rarely read user guides or instruction manuals!
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, July 10 2013, 05:50 PM - #Permalink
    Resolved
    0 votes
    Thank you for your reply, Peter!

    From your message, this is what I understood:
    - The "free" IPS/IPD modules in ClearOS are useless and I should not bother using them.
    - To get actual IPS/IPD protection on my gateway, I'll need to buy the $99/year subscription.
    - If I feel like it, I can hack in the Emerging Threats rules (which I've done).
    - I should have RTFM'd this, and known all of the above.

    I do want to point out, that the tooltip and user guide to not explain the above points, as you suggest. For example, here is the tool tip on the IPS page: "The default open source rule set is included. Commercial rule sets provide more than 10 times the coverage with regular updates." The user guide simply instructs the user how to use IPS/IPD, but contains no language about those three main points. At the very least, I'd expect the out dated rules to detect and block a simple portscan, as it used to in version 5.2. Again - that's the reason why I came to the forum to get my answers.

    From my perspective, I was/am ready to purchase the $99/year subscription. What has caused pause in this purchase decision, is a perception of a product defect in IPS/IPD. Why would I want to pay for something I don't immediately see working properly? Perhaps a trial version of the paid solution would help people like me make that decision? Or as you suggested, a removal of the free IPS/IPD from the Marketplace.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 04 2013, 01:41 AM - #Permalink
    Resolved
    1 votes
    Was I wrong?
    The reply is currently minimized Show
  • Accepted Answer

    douggmc
    douggmc
    Offline
    Wednesday, September 04 2013, 03:10 PM - #Permalink
    Resolved
    0 votes
    I don't think you are wrong. I think you hit it spot on.

    For whatever reason, standard "free" IPS/IDS is not getting attention and is not functional / is useless.

    I don't understand why it is not getting attention (speculate it is a matter of priorities and limited developer bandwidth), but would think it worthy of at least a timeline/expectation. If nothing else, I would think a functional (albeit very limited) "free" IDS/IPS that will works and occasionally blocks the basic attacks would be a better selling tool for the paid subscription. After all, if I, a relatively ignorant admin, never see ANYTHING blocked with an enabled free IDS/IPS, I'm thinking all is wonderful in the world and would think "why pay for subscription IDS/IPS, when my basic "free" is not finding anything to block?".

    PS - I have the paid subscription. I like it, but would like to see a little bit of configuration options to it (block time, permanent block list, etc.).
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 04 2013, 05:45 PM - #Permalink
    Resolved
    0 votes
    It's not a technical/development issue, it's a perception issue. IDS/IPS only works well when there are people keeping a watchful eye on IDS/IPS signatures. It's not like a standard app (e.g. OpenVPN), where a developer can build the app and forget about it for months at a time. IDS/IPS requires grunt work each and every week! The free version should just be removed, but that's where the perception issue creeps in:

    - "ClearOS is greedy"
    - "ClearOS is closed source" (ignoring the 100-ish free apps/libraries)
    - "Other products offer it for free, why on earth should I pay"

    No matter, it's not my call -- I'm just the technical guy.
    The reply is currently minimized Show
  • Accepted Answer

    douggmc
    douggmc
    Offline
    Wednesday, September 04 2013, 05:53 PM - #Permalink
    Resolved
    0 votes
    Hi Peter ... I hope my post didn't sound overly negative. It really wasn't meant to be!

    I guess, I would like to see the default IDS/IPS trigger on SOMETHING! That was my point. Whether it is extremely stale/old rules (add a couple new basic ones in) or whatever. It USED to trigger occasionally, it does not now (at least for me ... I've had a gateway up for months with static IP without a single block).

    For me it is moot as I subscribe to paid subscription.

    Again ... I love you guys! You are NOT greedy. You guys offer a great product!
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 04 2013, 05:59 PM - #Permalink
    Resolved
    0 votes
    Your post wasn't taken in any negative context at all :-) We just know from experience that when something "free" goes away, there will be a small but vocal segment of the community that will cry foul. That might not be the case with IDS/IPS though - it was really the upstream licensing changes (Snort removing rules from releases) that caused grief.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, September 05 2013, 09:25 PM - #Permalink
    Resolved
    0 votes
    I was poking around with this the other day and noticed that Snort HOME_NET was defined only as the LAN internal subnet. This reflects the snort sensor being 'inside' the firewall and picking up on traffic that passes through onto your LAN. This could be quite limited if you don't have any external services...

    A lot of my traffic is directed at my external IP for services hosted by ClearOS so I wanted the snort sensor to pick up on all traffic outside my LAN... so I added my public IP to HOME_NET in /etc/snort.conf and now I am receiving a lot more snort logs (noise)

    Perhaps you are not seeing many entries because the sensor is setup on the LAN inside the firewall? The preference of where the sensor should go is a personal one...personally I prefer to see what's knocking on the door, rather than what gets through the letter box :)
    https://isc.sans.edu/diary/The+Snort+Top+10/1981

    I should note I am using the ET rule set... in addition to the GPL rules
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 06 2013, 11:20 AM - #Permalink
    Resolved
    0 votes
    There is a bug here so I suspect you may have specified HOME_NET yourself. Interestingly the init script should also add your WAN subnet to HOME_NET were it not for the var -> ipvar bug. I did not like this when I reported the bug as it meant any other VM customer on my WAN subnet was defined as HOME_NET. To me it is not OK to put your WAN subnet into HOME_NET if you don't own the subnet which is not the init script's assumption.

    I know little of the pro's and con's of adding your WAN IP or owned WAN subnet to HOME_NET.

    I think most people on 6.x will have an incorrect definition of HOME_NET because of the bug, and this will not be fixed until 6.5. People on 5.x are fine.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 06 2013, 01:07 PM - #Permalink
    Resolved
    0 votes
    Hmm, thanks not seen that! I agree WAN subnet is not great, but WAN IP should be fine (i.e. with /32 in CIDR notation)

    For example without your WAN IP snort will not trigger any of the HTTP rules which typically use the $EXTERNAL_NET -> $HOME_NET rules

    I've not edited mine before hand, the HOME_NET variable is set by the auto_configure function in /usr/clearos/apps/intrusion_detection/libraries/Snort.php (called by the clearsync event in /var/clearos/events/network_configuration/intrusion_detection)
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 06 2013, 01:17 PM - #Permalink
    Resolved
    0 votes
    I fudged it with the following hack to /usr/clearos/apps/intrusion_detection/libraries/Snort.php at line 185
             $networks = $iface_manager->get_most_trusted_networks(TRUE, TRUE);
    $wanip = $iface_manager->get_external_ip_address();
    $new = '[' . implode(',', $networks) . ',' . $wanip . '/32]';
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 06 2013, 01:23 PM - #Permalink
    Resolved
    0 votes
    Interesting about the HTTP rules. I fixed my init script as in the bug report and it would be easy to add my WAN IP as well as you suggest, but it is all going to change in 6.5 in the near future.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 06 2013, 02:46 PM - #Permalink
    Resolved
    0 votes
    From what I can tell, the init script code has been removed in the upcoming 6.5 release, with the clearsync php code remaining?
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 06 2013, 03:46 PM - #Permalink
    Resolved
    0 votes
    It should now be covered by a clearsync event handler looking for a network change. Unfortunately I can look at scripts to an extent but not php. Related bugs: 1225 and 1266. 1266 refers to the event handler. Reading the texts, it looks like it goes through to 1267 which is the event handler tracking bug.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 06 2013, 06:40 PM - #Permalink
    Resolved
    0 votes
    Hi guys,

    For the mainline ClearOS 6 version, HOME_NET is set to the default "any". The old init script never did anything since it had and older parameter lookup algorithm that never triggered. Those running the 6.5.0 Beta 1 (i.e. have updates-testing enabled), will only have LAN networks defined for HOME_NET. I'll make sure WAN IPs are added to HOME_NET for beta 2 (tracker #1302).

    Sorry for the confusion!
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 06 2013, 07:44 PM - #Permalink
    Resolved
    0 votes
    So the new logic is this for HOME_NET:

    - All DMZ, HotLAN and LAN networks are added
    - All External IPs are added

    Does that sound right? Should a special case be made for standalone systems?
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 06 2013, 07:54 PM - #Permalink
    Resolved
    0 votes
    @Pete,

    Also EXTRALANS (which I used in my script mod in the initial bug report)? And did there not used to be an undocumented parameter for VPN's something like VPNLANS (not that I've ever used it)? Can the logic also cover OpenVPN subnets?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 11 2013, 07:58 PM - #Permalink
    Resolved
    0 votes
    Thanks Nick, I'll add EXTRALANS to the list. The VPN LANs should already be covered -- that was just a way to make IPsec happy about routing for multiple subnets.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 11 2013, 08:29 PM - #Permalink
    Resolved
    0 votes
    Yes I thought about it some more and I use EXTRALANS for my IPsec VPN LAN. I looked up the VPN one in 5.2 and it was not VPNLANS but LANNET in /etc/firewall, but I agree it is probably unnecessary. It would have been nice to cover the OpenVPN subnets automatically but EXTRALANS can always be used manually.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 14 2015, 10:39 PM - #Permalink
    Resolved
    0 votes
    This is my first post in years! And glad to be back. Anyway...

    Having used one of the first ClarkConnect versions for years and having updated to one of the first ClearOS versions in about 2003 or 2004, (I think), and I have used this older version successfully at my home/office for many years. I just now upgraded my ClearOS to 6.6.0 final (the latest release I could locate), with the IPS/IDS installed. My old ClearOS/ClarkConnect would always block some kiddy script and sometimes something a bit more malicious. However, this new version with the free included rules/signatures never seems to block an IP. Other than that, for my simple home office use, ClearOS 6.6.0 is working very well.

    Having checked the snort.php file, it appears to have changed significantly and trying the hack mentioned above at line 185 appears to not be a prudent thing to attempt.

    Has this been resolved? Again, there is a perception that something is not quite right.

    It also appears that there are those that feel this should not even be a part of the installation or available in the store. Is it best to not even run these tools with the stock rules?

    Thanks for any information or thoughts.

    JohnJ
    The reply is currently minimized Show
Your Reply