Taming the beasts… aka suricata blueprint
-
Isnt 2.2 FreeBSD 10 based??
-
@Hollander:
Well thank you Bill and JFL for boosting my self esteem ;D ;D ;D
But now… 8)
( ;D )
I am struggling with a dnsmasq problem (blocking ad servers via dnsmasq, can't get the script to run in cron - although manually it works), and on the site that provides the lists I also noted a format for Snort:
http://pgl.yoyo.org/adservers/
**(Select the second drop down - list ad servers IP adresses): there is also a Snort format of the list there.
Would it make sense to use Snort to block ad servers using that list?**
I know there will be reservations; 'noob, shut up'.
Ok, I will :P
When you can't get a script to run via cron, the #1 cause is forgetting to provide the complete and entire path to all files used in the script. When a cron task executes, it does not inherit the user environment you have when working at a shell prompt (CLI). Some examine the script and make sure full paths are provided for all referenced files.
Bill
Thanks Bill ;D
I didn't mean to bother you with the problem I have to get a cron job running (I did have the full path, btw): I was only meandering away from the point in question: the text in bold in the above :P
-
Isnt 2.2 FreeBSD 10 based??
Yes it is, but I couldn't find much info on this issue with my google FU…
I did find this link:
http://smyck.net/2014/01/22/freebsd-authentication-error/I don't have a 2.2 box, so I can't test it myself. If anyone else has 2.2, can you see if these two commands work? Don't need to be using my Script to test if fetch and https work on 2.2 Alpha.
cd /tmp
fetch -v -o honeypot.txt "https://www.projecthoneypot.org/list_of_ips.php?t=d&rss=1"
wget –no-check-certificate -O honeypot.txt "https://www.projecthoneypot.org/list_of_ips.php?t=d&rss=1" -
My problem was a PEBKAC, I had a self signed cert installed in pfSense. I removed it and it works just fine. Thanks for your hard work. I can report that I'm not having any issues with the script or the widget in 2.2, all seems to be working fine except the patches for dns look up report that they can not be installed cleanly. Not important.
Thanks,
Bill -
all seems to be working fine except the patches for dns look up report that they can not be installed cleanly. Not important.
Good to hear!
Is this the 2.2 diag_dns.php file that matches what you have on your box?
https://github.com/pfsense/pfsense/blob/master/usr/local/www/diag_dns.phpIf its the same, I will post an updated version of the Patch.
-
I believe it is. On the current snapshot.
Patch can NOT be applied cleanly (detail)
Patch can NOT be reverted cleanly (detail)Thanks,
Bill -
Also neither widget displays list count or correctly determines failed downloads. It is correctly displaying other correct information. This is on Today's snapshot of 2.2. I didn't look into it because I can read logs… :)
PfIP Reputation2
minimize
close
(All Downloads Successful)List Count
Alias CIDRs Packets Updated Status
IR_IB 60359 0 Jul 29 22:42
IR_PRI1 2418 0 Jul 29 20:42
IR_PRI2 24652 40 Jul 30 15:52 -
I want to think jflsakfja and BBcan177 for this thread. Fantastic work.
-
I want to think jflsakfja and BBcan177 for this thread. Fantastic work.
As long as you are not thinking of us while taking a bath ;)
-
@jflsakfja:
I want to think jflsakfja and BBcan177 for this thread. Fantastic work.
As long as you are not thinking of us while taking a bath ;)
;D ;D ;D
-
JFL, could I ask: what is your opinion on this:
Why block an attacker that's already been blocked by your firewall? Because they will continue to beat on your door till they find something they can brute force or exploit. So lets use their initial scanning to identify hostile intent and block.
http://doc.emergingthreats.net/bin/view/Main/WhatEveryIDSUserShouldDo
It would make sense to this noob ;D
-
@Hollander:
JFL, could I ask: what is your opinion on this:
Why block an attacker that's already been blocked by your firewall? Because they will continue to beat on your door till they find something they can brute force or exploit. So lets use their initial scanning to identify hostile intent and block.
http://doc.emergingthreats.net/bin/view/Main/WhatEveryIDSUserShouldDo
It would make sense to this noob ;D
Nice to see that most things in this topic are also mirrored in that page. Too closely mirrored, if you catch my drift ;). Now if they had the same spirit about deleting their outdated rules, then we would all be happy ;D
And yes, that's what the recommended unused ports rule (in this topic and that page) does. It identifies people that are port scanning you, but maybe managed to get a list of open ports before they were banned. Cutting off their access before them noticing that you have open ports and try to connect to those, is a sane way of preventing them from getting onto your network. If you know that they are malicious, why even let them in the network in the first place?
My recommended rule was detecting ALL traffic to unused ports. His rule detects traffic that is attemping to be established. What if the "attacker" decides to scan in an unconventional way? You should never see traffic to those ports, end of story. If even a single packet arrives at those ports, then it is malicious, since you did not ask for it.
Didn't have time to read the entire page, but from quickly going through it it looks like he is recommending a similar set as to what is described in this topic. Suricata on pfsense belongs in the network gateway category, and as such should be responsible for protecting the network proactively if it can, or reactively if it cannot (encrypted connections terminated to internal servers for example). From suricata's/pfsense's point of view, it should try to make the network conform to specific requirements, like the requirement to contact specific DNS servers.
What I will comment on though is the section "Systems That Should Never Surf the Web". This is the typical wrong approach to using an IDS/IPS system. If you don't want those systems to surf the web, use what the firewall is designed to do: Be a glorrified router that routes according to specific rules, and block those hosts using a solution as close to the network as possible. If I were responsible for systems that shouldn't surf the web, then I would just air-gap them instead. It's the closest to the network you can be, there isn't actually a network (connecting them to the Internet), a separate physical intranet is acceptable, since not everybody has ninjas sworn in blood oaths to get into their networks.
But shouldn't the firewall be used for unused ports as well? From the inside of the network, absolutely yes. From the outside of the network you need the sentry (suricata) as high on the walls as possible. Bonus points if you can give him binoculars as well. The more he can see, the faster he will alert the rest of the town (pfsense) that danger is coming. The faster the town is warned, the faster the gates will be locked (host added to banned hosts). Ask yourself, what use is the sentry on top of the wall 1km away, monitoring the market stall thieves in the center of the town? Why the medieval thinking? If you haven't yet read the Art of War, you don't belong in the network security field.
-
I was looking at the Suricata Package and I don't see where the PORT Scanning Pre-Processor is configured? Is this option available in Suricata? or is it expected to be released in the 2.0x releases?
Along with what jflsakfja and Matt Jonkman (ET) have said, here is some more good advice:
http://dcid.me/notes/2013-jul-08
-
Quotes taken from http://dcid.me/notes/2013-jul-08 unless otherwise stated. Don't sue me to death :P
"And that’s a hard spot to be on. If you read all recent cases of APT, 100% of them started with zero-days sent via very targeted phishing emails. How do you protect against that?"
With the only way you can defend against that. Take a baseball bat with you when you are going on your tour around the office educating people not to click on every link/download every file sent to them via email. I got this right up to the point where (certain) people don't even answer phones from unknown numbers. Yes users can be educated, it's only a matter of which finger will be broken first. And yes, I'm being 100% serious."Unfortunately, very few companies have that level of monitoring and security enabled. Very few would be able to detect a user trying to increase their privileges or even detect any anomaly from where he is logging in from. They can have a firewall and an IDS, but nobody looks at them. They are just so noisy that it is very easy to miss the important activity."
More work for security "experts", more people to pick on for me ;D. A person (key word) should never be expected to watch logs for intrusion. EVER. If you are an industry leader and recommend you watch your logs closely, then all hope is lost for you. Please consider a career selling hotdogs instead. It's a lot easier than trying to convince the world you know anything about network security.
I do NOT care what the security industry is recommending about logs. It's a case of the right way (watch the logs), the wrong way (don't watch the logs) and my way. My way is setting up automatic monitoring of the logs and alert the sysadmins automatically when the monitoring detects anomalies. Did the webserver restart in the middle of night? Which user requested the restart? From where were they connected to the system? What other commands were ran in the last 10 minutes of them being logged in?
Watch the IDS? Who in their right mind watches an IDS? Have you seen the volume of data it logs in realtime? The key to keeping your fire-breathing dragon (suricata, snort is dead, stop feeding it) on the leash is to look at the blocked hosts every now and then. Sort their alerts alphabetically, take out the common suspects (unused ports rule for example, should be the largest volume) then take a close look at what the other blocks say. Make this a habit instead of wasting hours of company time reading what others did last night on fb/twitter/other + "thing". My way? If the IDS bans a host with an alert other than the usual suspects, drop me an email alerting me to this.
Sidenote to the above couple of paragraphs. You can safely skip this.
Got a call today from a client of mine. He told me that the router must have blocked him again, because he tried to ping the webhosting server to find out its IP. The conversation went something like this:Client: "Hi, how are you?"
Me: "Hello, I'm good, how about you?"
Client: "Fine. Hey the router must have blocked me."
Me: "Why?"
Client: "I tried to ping the webserver that X is hosted on, and after a single reply all traffic was cut off."
Me: "That means the security system did it's job correctly. Doesn't windows have a command similar to the "host" command on linux? Why did you ping it?"
Client: "It's the easiest way to get the IP. My IP is XX.XX…"
Me: "Wait, hold on, I'm on the second password, 1 more to go"
Client: "You should allow 4 pings, that would make it easier"
Me: "No. I get a few hundred thousand pings per day from China,Romania,Russia, I'm good thank you. Use the proper command to get the IP. On linux it's host, on windows I dunno, don't have any experience with "that"" (exact phrase removed, this is a public forum, even visited by minors)
Client: Doing other things while I try to find the password to log on to the router. We said something about this in the beginning of the guide (I think, I'm getting old :p). If you know the passwords to your systems, you are doing it wrong (I should trademark that phrase).
Me: "ok, what's your IP?"
Client: "XX.XXX.XXX.XXX"
Me: "Hm... yea, you pinged it using windows" BOFH like clickety-click
Client: "Ok thanks, it's working now"
Me: "Happy to help, if you have any other problems give me a call."See? It's only a matter of which finger you'll break first, trust me.
"I will certainly do a full post about it, but what I learned is that you can’t really block all attacks. You can’t even detect all of them. Your software will have vulnerabilities. You will make mistakes. You will get owned one day!"
Started securing networks/systems when I was 10 years old. I'm 27 now, and that day has not yet come. It's a record I'm doing my best to keep, thank you very much."What you need is a system to alert and raise red flags when that does happen, so you can respond. The “you just got owned” alerting system. And those are not hard to setup, but requires a different mindset."
My points exactly ;DComputers have become extremely good at one thing: Doing the same thing over and over without making a mistake. Set up your network/systems so that EVERYTHING is logged to syslog. From temperatures, to disk performance change (I get a couple of seek performance changed a day, must really replace that disk, the head actuator is getting weak), to users logging in, to users logging out, commands being ran by users, scheduled tasks, EVERYTHING.
Filter through the noise by discarding unneeded messages. For example, a host's resync with a mariadb galera cluster causes (about) 30 lines of syslog messages. It should only generate a single line from that particular host, and a line from each of the cluster members seeing the host joining.Keep the log messages to a manageable volume, then set up automatic monitoring for those logs. If something is suspicious, contact a sysadmin to have it looked at. If one particular sysadmin logs from networks X and Y, and suddenly logs in from network Z in the middle of the sahara desert, then something fishy is going on.
And as stupid as this may sound, it will actually save you when a judge asks you "WHAT?". Keep >forensic< evidence trails. Yes, which pc connected to what, under what user, what commands were given and all that, BUT make sure those can actually STAND in a court of law. If I was a consultant for the prosecution, I would provide evidence showing that the authenticity of the logs submitted cannot be questioned. If i was a consultant for the defense, I would provide evidence showing that those logs that were submitted earlier as unquestionable evidence showing that X is guilty, cannot be actually checked to be sure that they weren't manually typed up and submitted.
We already got pretty far with this guide and the help of the pfsense devs, package maintainers, other forum members. If we keep this up, not one of the security industry "leaders" will have a job. Think of the children/cyber/terrorism/Russia ;D
I should really finish that internal book for The Company: "Building sentient AI security systems. Their applications and limitations." aka the "How to build the Matrix guide".
An example of this is an automated system we use at The Company. It takes a list of the servers and their uses. It then decides what each system should run, sets it up accordingly, and starts monitoring it. Good events are slowly ignored, bad events are evaluated and future systems are set up to resist them (if possible). We had a few "near employee firing" experiences, but it slowly learned to behave ;D
To the disbelievers, you can also design the same system. You think the technology still isn't there? puppet/chef/nagios (or others)/fail2ban/logwatch/syslog/ssh/network-booting/not booting servers unless their specific usb key is plugged in (HDD encrypted, of course). VPN the logs to another location and print them on a dot-matrix, just for the hell of it. Connect the dots and stop questioning everything I say ;D. If you are really creative, you can even set up your systems to be as simple as a message popping up "Hey, go plug USB key XXXXXX into server YYYYYY, it needs to restart". Or spend the $200 it takes to do it using an actuator ;) Taking care of the systems then becomes a mob the floor, stare at the screen for pretty graphs to dip/raise.
-
I think it was obvious that you wouldn't look at every single log and every single IDS alert. It is true thou that people can setup these systems and get drowned out by the minutia.
However, this is not what he is saying. Its important to filter those logs and those alerts from the IDS so you are only seeing the important ones. Setting up tripwires so that if and when someone does get in, or someone on the inside does something, it will trip an alarm.
It all great to put up blocking system to stop maliciousness from getting in, but as the article articulated, you will make a mistake or someone will, or a zero-day and something gets past your security. Nothing is impenetrable.
Tools like OSSEC are good to have running on servers so that it can alert on file changes or brute forces inside your network. I run Security Onion running full packet capture immediately after my Firewall. So when you have an issue, you can atleast have a bread crumb trail so you can see what was accessed and infiltrated or attempted to be. These logs and pcaps can determine whether someone just snooped around or if they actually downloaded/uploaded anything.
If you look at most network intrusions, its not the first hack that made any damage. Most likely a single event won't be catastrophic. So if you have detection on the inside, they will most likely trip an alarm that will allow you to root out an intruder before they do damage.
As with age, I never judge the length of time someone has been doing something as a sign of wisdom. People do jobs for their entire life; unfortunately some of them never had it right in the first place.
-
I was looking at the Suricata Package and I don't see where the PORT Scanning Pre-Processor is configured? Is this option available in Suricata? or is it expected to be released in the 2.0x releases?
Along with what jflsakfja and Matt Jonkman (ET) have said, here is some more good advice:
http://dcid.me/notes/2013-jul-08
I'm not a Suricata expert yet, but to the best of my knowledge there is no equivalent of Snort's sf_portscan preprocessor in Suricata. There are text rules (ET Scan rules come to mind) that can detect most port scans, though.
Bill
-
Give me a ping, Vasili. One ping only.
-
Hi,
Trying to code a custom rule and getting an error. The rule is basically to block the traffic to closed ports, something like:
alert tcp $EXTERNAL_NET any -> any [1:1024,![XX,XX,XX,XXX]]
However, I'm getting an error:
[ERRCODE: SC_ERR_NEGATED_VALUE_IN_PORT_RANGE(56)] - Can't have a negated value in a range.I thought this was a valid syntax. What am I missing here?
Thanks for your help!
-
I thought this was a valid syntax. What am I missing here?
This is from an older manual, but I believe its still the same format.
2.2.4 Port Numbers
Port numbers may be specified in a number of ways, including "any" ports, static port definitions, ranges, and by negation. "Any" ports are a wildcard value, meaning literally any port. Static ports are indicated by a single port number, such as 111 for port mapper, 23 for telnet, or 80 for http, etc. Port ranges are indicated with the range operator ":". The range operator may be applied in a number of ways to take on different meanings, such as in Figure 2.6.
log udp any any -> 192.168.1.0/24 1:1024 log udp
traffic coming from any port and destination ports ranging from 1 to 1024
log tcp any any -> 192.168.1.0/24 :6000log tcp traffic from any port going to ports less than or equal to 6000
log tcp any :1024 -> 192.168.1.0/24 500:
log tcp traffic from privileged ports less than or equal to 1024 going to ports greater than or equal to 500
Port negation is indicated by using the negation operator "!". The negation operator may be applied against any of the other rule types (except any, which would translate to none, how Zen…). For example, if for some twisted reason you wanted to log everything except the X Windows ports, you could do something like the rule in Figure 2.7.
log tcp any any -> 192.168.1.0/24 !6000:6010
-
Hi,
Trying to code a custom rule and getting an error. The rule is basically to block the traffic to closed ports, something like:
alert tcp $EXTERNAL_NET any -> any [1:1024,![XX,XX,XX,XXX]]
However, I'm getting an error:
[ERRCODE: SC_ERR_NEGATED_VALUE_IN_PORT_RANGE(56)] - Can't have a negated value in a range.I thought this was a valid syntax. What am I missing here?
Thanks for your help!
You need to remove the regular ports from the rule and only select the negated range. It wouldn't be any use anyway to include 1:1024. If you don't allow that range, the rule will still alert for those ports, since that's what you told the IDS to do. Alert on any port other than the open ports (used ports). Any port you don't specifically allow, will generate the alert.
@G.D. Wusser Esq.: It's not a matter of one ping only Vasili. It's a matter of not using a screwdriver and a hammer to remove a 1/2" bolt. Yes it can be done, yes it's extremely useful if the head of the bolt is broken off for any reason, but it's not the right tool for the job. Use the 1/2" wrench to remove the 1/2" bolt.
To ping a host you first need to resolve the host, then ping it.
To find out the IP of a host, you just need to resolve the host.
