# File monitoring and Obfuscation



## Deather (Jul 31, 2020)

1.Hello, I was wondering about which files a inturder would want to attack and make changes to that the system doesn't edit at all. 

2. How could you confuse the attacker by making them think that they are on a different OS and not FreeBSD?  

3. Final thing, Is there a file of which can monitor all the commands run by any user?

Note: I will be reading the HandBook soon but for right now I need answers. Also I doubt it's in the HandBook. Thank you for your help <3


----------



## Sevendogsbsd (Jul 31, 2020)

Are you doing homework or a certification test?   

No way to obfuscate what OS an attacker is ALREADY ON - a good attacker will immediately know this. The files accessed by an attacker depend entirely on their motives and the purpose of your server. If an attacker is already on your server, you have bigger issues to worry about than what files they will access though...


----------



## rootbert (Jul 31, 2020)

1.) Depends on what the attacker is up for. Use a host intrusion detection system to detect changes.
2.) Very difficult, only possible with tremendous work: you need to delete all kinds of traces of the OS, like uname, sysctl, libraries, binary format etc. ... it's maybe easier to write an own operating system. Have a look at unikernels like NetBSD Rumpkernel or other solutions
3.) https://www.freebsd.org/doc/handbook/audit.html


----------



## Mjölnir (Jul 31, 2020)

Ha! You're under-estimating the quality of the FreeBSD Handbook.
1. Replace the monitoring binary e.g. freebsd-update(8), then the victim does not detect your changes
3. RTFM `apropos accounting` & the Handbook.


----------



## Deather (Jul 31, 2020)

mjollnir said:


> Ha! You're under-estimating the quality of the FreeBSD Handbook.
> 1. Replace the monitoring binary e.g. freebsd-update(8), then the victim does not detect your changes
> 3. RTFM `apropos accounting` & the Handbook.


I will now start reading <3

How much should I read a day though?


----------



## Deather (Jul 31, 2020)

Sevendogsbsd said:


> Are you doing homework or a certification test?
> 
> No way to obfuscate what OS an attacker is ALREADY ON - a good attacker will immediately know this. The files accessed by an attacker depend entirely on their motives and the purpose of your server. If an attacker is already on your server, you have bigger issues to worry about than what files they will access though...


The only thing i'm worried about is if they get access they can disable the firewall. As it's only allowing proxy traffic. And if I can detect if someone is in my system then it will shutdown and notify me. Pulling out the files and examing, fixing and then reinstalling.


----------



## Sevendogsbsd (Jul 31, 2020)

Well, all I can say is if they are already on, your firewall is pointless at that point. I would say if you can tell someone is on your system, then a notification is good, but most attackers will be very stealthy. Unless they just want to wreak havoc and don't care. As mentioned earlier, a host based IDS is a good idea.


----------



## Deather (Jul 31, 2020)

Sevendogsbsd said:


> Well, all I can say is if they are already on, your firewall is pointless at that point. I would say if you can tell someone is on your system, then a notification is good, but most attackers will be very stealthy. Unless they just want to wreak havoc and don't care. As mentioned earlier, a host based IDS is a good idea.


I plan on making a computer board. Not sure how to do that yet but I am willing to learn. Preferably small, 512Mb ram and a decent cpu is fine. (I will test the requirements for my project later), But it will have a built in firewall on the board. So it goes through a microcontroller and into the pc, kinda like ethernet but on the board instead. And will not be able to tell the microcontroller what to do. But the firewall thing was an example. Also I read all the way to 3.2 Virtual consoles in the handbook


----------



## julp (Jul 31, 2020)

Deather said:


> The only thing i'm worried about is if they get access they can disable the firewall.


So run it [FreeBSD] with a kern.securelevel to 3?

It can be part of _System Hardening_, the subject of one of your other topics...


----------



## Deather (Jul 31, 2020)

julp said:


> So run it [FreeBSD] with a kern.securelevel to 3?
> 
> It can be part of _System Hardening_, the subject of one of your other topics...


Yeah I got that stuff. But not just the kernel can have vulnerabilities.


----------



## Alain De Vos (Jul 31, 2020)

Mounting a simple USB stick fails if kern.securevel is too high. So I don't touch it.


----------



## julp (Jul 31, 2020)

Alain De Vos said:


> Mounting a simple USB stick fails if kern.securevel is too high. So I don't touch it.


This shouldn't be too problematic as long as you have physical access to it.

If I were to accomplish the same, I would use some kind of removable media, I'd mount read-only (except /var + /tmp?) and I'd update it from an other system (when a new vulnerability is patched). At least, you keep a spare one ready to minimize downtime. But it depends of the (exact) needs.


----------



## ralphbsz (Aug 1, 2020)

Deather said:


> 1.Hello, I was wondering about which files a inturder would want to attack and make changes to that the system doesn't edit at all.


Could be nearly anything. The one time I was root-kitted (about 1999, on Linux, the attack actually failed), the attacker inserted a directory called "/usr/bin/..." (yes, three dots), which was a real directory, and contained their attack executables. I noticed the attack pretty quickly (because their root kit was so stupidly written, it tried to send mail, but with wrong parameters to the mail program, duh), and then it took me 10 minutes to find out where they were hiding their files. Note that no files were changed, only a directory entry created.

If you are wondering about files being changed: I vaguely remember that one of the daily or weekly security jobs takes checksums of all files in somewhere (like /bin or /usr/bin or similar), and reports when they change. Or is that only for setuid files? You might start by reading the periodic infrastructure.



> 2. How could you confuse the attacker by making them think that they are on a different OS and not FreeBSD?


Forget it. The fact that it is not Linux becomes immediately obvious when you look at the places things are stored. For example /usr/local being full of stuff. Or look for the difference between /etc/syconfig/... and /etc/sysctl.conf. While you can easily change the kernel to return a different answer from the uname() system call, that will A: break a lot of software, and B: immediately be noticed as fake by anyone who knows what they're doing. And then there are things that you just can't fix. Like:

```
# file /bin/ls
/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c132aa35afa3aeb96336b2241f38e2edcbc3b945, stripped
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.3, FreeBSD-style, stripped
```
So you can change the file command, the the executable loader in the kernel, and the elf linker, and nm and ... really? It just won't work.



> 3. Final thing, Is there a file of which can monitor all the commands run by any user?


What makes you think that your attackers are actually issuing commands from a shell? Today, real attackers are more likely to use things like the mail server or the web infrastructure on your machine than logins. That's why securing the machine against remote logins (things like ssh passwords) and bugs in the shell have become of little use: those things are typically so well secured, the real attacks are elsewhere.

Anyway: As you certainly know, anytime a user executes a "command" from a shell, that either runs a process, or it doesn't; the "it doesn't" case is using shell built-ins. Most damage can be done by running processes, for example "rm -f /boot/kernel/kernel", which runs the /bin/rm executable. That kind of attack you could audit by turning on process accounting (there is a handbook chapter for that). But beware: once you have process accounting on, the audit log of accounting (all process creations!) will be extraordinarily long. You will find thousands of times that someone runs for example the /bin/rm executable. Which of those are an attacker? Good luck. And then you find that someone runs "/usr/local/bin/perl foo.pl" ... and you have no idea what that did; and from inside, interpreters like perl or python or ruby can do nearly anything, without running a process. And shell builtins also don't create processes, and saying "echo foo > /boot/kernel/kernel" is just as damaging as deleting the kernel.

Have you looked at security auditing? There is a handbook chapter about that.



> Note: I will be reading the HandBook soon but for right now I need answers. Also I doubt it's in the HandBook. Thank you for your help <3


Sorry, but you have it exactly backwards. Please read the handbook. You are currently making a fool of yourself in public. That makes it quite unlikely that you will receive meaningful help.

Most of the details you are asking are in the handbook. What is not in the handbook is basics (like what is a process and what isn't), and common sense (like finding the needly in the haystack).


----------



## Deather (Aug 1, 2020)

Alain De Vos said:


> Mounting a simple USB stick fails if kern.securevel is too high. So I don't touch it.


Do you know of any FreeBSD rootkits, viruses, etc? That could be scanned for? I know theres chkrootkit and others but I think they only scan for linux rookits correct me if I'm wrong


----------



## Deather (Aug 1, 2020)

ralphbsz said:


> Could be nearly anything. The one time I was root-kitted (about 1999, on Linux, the attack actually failed), the attacker inserted a directory called "/usr/bin/..." (yes, three dots), which was a real directory, and contained their attack executables. I noticed the attack pretty quickly (because their root kit was so stupidly written, it tried to send mail, but with wrong parameters to the mail program, duh), and then it took me 10 minutes to find out where they were hiding their files. Note that no files were changed, only a directory entry created.
> 
> If you are wondering about files being changed: I vaguely remember that one of the daily or weekly security jobs takes checksums of all files in somewhere (like /bin or /usr/bin or similar), and reports when they change. Or is that only for setuid files? You might start by reading the periodic infrastructure.
> 
> ...


I already started reading the handbook. Also if you ever looked at a honeypot (you can find videos), usually they first find a vulnerability and then get a backdoor into the system. I have exploited computers for 2-3 years so- I have found tons of zero days too.

Edit: I don't care about my public image and people seem to be helping either way and i'm greatful they are.


----------



## ralphbsz (Aug 1, 2020)

gpb said:


> 3. security/tripwire or something similar.


That's the thing I was thinking about! Thank you.


----------



## ralphbsz (Aug 1, 2020)

Deather said:


> ... I have exploited computers for 2-3 years so- I have found tons of zero days too.


Just as a reality check: Typical prices for selling zero days to legitimate buyers (typically computer companies and government agencies) range from $100K to $1M; the prices are higher for mobile OSes. Typical prices for selling them to criminals tend to be significantly higher, but are often paid in a fashion that is a bit difficult to turn into fiat currency (meaning the black market is difficult to exploit efficiently).

If you have found tons of zero days, then you should just hire yourself consultants to answer these questions, you have the means.

And about honeypots: When Niels Provos was still a grad student, I tried to hire him. Sadly (for me, good for him) he went to work for the competition.


----------



## Deather (Aug 1, 2020)

gpb said:


> Then why are you asking?


Because i've dealt with script kiddies who think they are anonymous using a vpn, but then when I ask them to go to a link with a vpn or tor they don't. They did carding.

Also in a honeypots I have not seen someone check the os. they see a terminal and assume linux. So script kiddies like to do the following commands when they get inside: "apt-get install" "yum install" "pacman" etc..

I also plan on mixing the kernel with other unix's. and removing some of bsd etc.


----------



## Deather (Aug 1, 2020)

ralphbsz said:


> Just as a reality check: Typical prices for selling zero days to legitimate buyers (typically computer companies and government agencies) range from $100K to $1M; the prices are higher for mobile OSes. Typical prices for selling them to criminals tend to be significantly higher, but are often paid in a fashion that is a bit difficult to turn into fiat currency (meaning the black market is difficult to exploit efficiently).
> 
> If you have found tons of zero days, then you should just hire yourself consultants to answer these questions, you have the means.
> 
> And about honeypots: When Niels Provos was still a grad student, I tried to hire him. Sadly (for me, good for him) he went to work for the competition.


I like keeping them to myself for use, and they wouldn;t interest the government.  Maybe the company that developed them. ANd mAyBe one of them might interest a governement


----------



## rf10 (Aug 1, 2020)

Definitely study the handbook. But not for obfuscation.

There is software which can fingerprint the OS and sometimes even the hardware running on a box just by portscanning a remote box. Nmap is one example of open source but there are more sophisticated tools.

So studying is useful to be able to properly defend you box, so that the attacker does not get inside. Obfuscation and other tricks won’t have any desired effect since most passive attacks are automated. And if you piqued the interest of a government agency or a foreign state, it is game over.


----------



## mark_j (Aug 1, 2020)

The OP's got some grandiose ideas but most of them are just plain stupid. Obfuscate the OS? Seriously?

Anyone with half the desire to break into a system should be able to work out an OS in a heartbeat. Check OS macros in the compiler, the header files, logs, scripts, startup methods, etc etc etc. It might, granted, be hard to work out a specific Linux distribution, but then someone more familiar with Linux would take no time at all.

To even think you can obfuscate an OS away is, well, childishly silly. It's also a waste of time and just nonsense.

On the "file" that can monitor user activity, again you've got the wrong OS. I think Linux had sysdig a while back. No such analogue for FreeBSD. You could, of course, wrap a script around shell invoke, but I imagine the output would be a tad useless once the user begins using a GUI or even an ANSI terminal.


----------



## a6h (Aug 1, 2020)

Deather said:


> And will not be able to tell the microcontroller what to do.


Would you care to elaborate on microcontroller part. Thanks, I appreciate it.


Deather said:


> Also if you ever looked at a honeypot (you can find videos), usually they first find a vulnerability and then get a backdoor into the system


How do they match honeypot (or as Microsoft used to call them Honeymonkey) and vulnerability, to get into backdoor scene?


Deather said:


> How much should I read a day though? [...] Also if you ever looked at a honeypot (you can find videos)


Video?! you are not much of a reader, aren't you? but that's OK, you've just started to read the handbook.


Deather said:


> I have found tons of zero days too


Zero day is just a fancy/marketing name for good old term: bug, written and used by journos in Red tops and alike. They love to use the word glitch too.


Deather said:


> might interest a governement


Which government?


Deather said:


> Because i've dealt with script kiddies [...] *ANd* mAyBe one of them might interest a governement


Speaking of script kiddies, and also the way you wrote, *ANd*, which reminds me of NAND gate .../.../... I have to conclude my rant with this summary:
usually but not exclusively having a good understanding of ISA (instruction set architecture) is a line which separates the experts from script kiddies.


----------



## wolffnx (Aug 1, 2020)

Deather said:


> The only thing i'm worried about is if they get access they can disable the firewall. As it's only allowing proxy traffic. And if I can detect if someone is in my system then it will shutdown and notify me. Pulling out the files and examing, fixing and then reinstalling.



ehmmm only if the are in the root acount, also they cannot change system settings,so,dont install sudo
and choose a good root password, but for sure you already know this


----------



## ralphbsz (Aug 1, 2020)

Deather said:


> I also plan on mixing the kernel with other unix's. and removing some of bsd etc.


I don't know what to say to that. The only polite one is "good luck, you'll need it".


----------



## wolffnx (Aug 1, 2020)

gpb said:


> Security in Linux and BSD hasn't really changed since UNIX was created.  Plan 9 redesigned it.  There is no root account or superuser; only a host owner, who doesn't have any special privileges (and don't say, but Ubuntu won't let you su to root. Yeah, and? It still uses sudo to have get privileges).  Also central to Plan 9 security is the factotum, which securely holds a copy of the user’s keys and negotiates authentication protocols, on behalf of the user, with secure services around the network.
> 
> Security in Plan 9



I dont know plan 9...so..
you meant the popular "sudo su" ?


----------



## Lamia (Aug 2, 2020)

ralphbsz said:


> That's the thing I was thinking about! Thank you.


And




__





						FreshPorts -- security/aide: File and directory integrity checker
					

AIDE is Advanced Intrusion Detection Environment, a file and directory integrity checker.  It creates a database from the regular expression rules that it finds from the config file(s). Once this database is initialized it can be used to verify the integrity of the files. It has several message...




					www.freshports.org
				








						FreshPorts -- security/lynis: Security and system auditing tool
					

Lynis is an auditing tool for Unix (specialists). It scans the system and available software, to detect security issues. Beside security related information it will also scan for general system information, installed packages and configuration mistakes.  This software aims in assisting automated...




					www.freshports.org


----------



## ralphbsz (Aug 2, 2020)

gpb said:


> Security in Linux and BSD hasn't really changed since UNIX was created.


While I agree that Plan 9 was actually designed from the lessons of the past ...

Unixes have changed a lot. ACLs, capabilities, secure levels, SELinux, encrypted disks, jails/VMs/..., leaving empty pages at the end of stacks and heaps, protecting executable code against being written, ...
And people have started paying attention to it. Like auditing code, testing, having government standards, ...

So it has changed a lot since Dennis and Ken.


----------



## Mjölnir (Aug 2, 2020)

On Solaris you can have two (or more) human persons _share_ the traditional _root_ (administrator) account.  I.e. one can do some tasks (roughly related to what would be allowed for members of the _operator_ group), but all other _wheel_ members can see a log, and vital tasks need to be allowed rubber-stamped by both/all admins.  Similar to the procedure to fire an atomic missile.  Don't know how to do that on FreeBSD.  IMHO that would be a really useful enhancement. EDIT IIRC that is called _roles_, i.e. you can make the root account a _role_.  Then you can not log in as _root_ anymore, but take that _role_ when you need it.


----------



## mark_j (Aug 2, 2020)

That's correct, RBAC is its name. And it's even more fine grained than you mention. You can basically eliminate root usage entirely. Anyone interested can read up about it. Is there anything similar in FreeBSD? Unfortunately not, more's the pity. It would be a major task to undertake, given it relies on shells, programs and the kernel to be modified. More doable on *BSD than say Linux, though.

I've administered it in the past, and it's a bit of a headache to set up but once set up you can give someone the role of printer administrator, access to just the web server etc. In environments with tight security enforcement its well liked.


----------

