Drop tcpdump permissions - pcap

Even after changing the group and ownership of tcpdump to user mode, I still get the following error:
tcpdump -i eth0
tcpdump: eth0: You don't have permission to capture on that device
(socket: Operation not permitted)
ls -la /usr/sbin/tcpdump
-rwxr-x--- 1 user1 user1 830920 Apr 24 21:28 /usr/sbin/tcpdump
I know it is not good to drop the permission of tcpdump from root to user but for ease of use in my case, I would like to be able to use it from user level.
I took the hint from:
"tcpdump -w 1.pcap" works, but "tcpdump -C 100 -w 1.pcap" - permission denied
and installed AppArmor as I am using Ubuntu 12.04 LTS.
And did:
sudo aa-complain /usr/sbin/tcpdump
Still I get the same error msg. If I use "-Z" with the tcpdump command, I can drop the privileges and run tcpdump but not otherwise.
Is there a way out?
Thanks

libpcap (which tcpdump is based on) require admin privilege to set your interface into promiscuous mode. There is nothing you can do about it, the kernel won't let you/tcpdump/libpcap do that, period.
What you can do is use tcpdump without promiscuous mode, but that will severely limit its functionality: you will only see traffic directed explicitly to/from your machine, as opposed to everything that's seen on the wire, which is usually what you want to to (and is why using promisc mode is the default). In order to do that, use this tcpdump option:
--no-promiscuous-mode
Don't put the interface into promiscuous mode. Note that the
interface might be in promiscuous mode for some other reason;
hence, `-p' cannot be used as an abbreviation for `ether host
{local-hw-addr} or ether broadcast'.
For more info on promiscuous mode:
http://en.wikipedia.org/wiki/Promiscuous_mode
I quote:
Many operating systems require superuser privileges to enable
promiscuous mode.
In Linux, at the low level, this is done by setting the IFF_PROMISC flag on the netdevice via a SIOCSIFFLAGS ("set flag") ioctl. And as you can see here:
http://man7.org/linux/man-pages/man7/netdevice.7.html
... "Setting the active flag word is a privileged operation", and "using it requires an effective user ID of 0 or the CAP_NET_ADMIN capability. If this is not the case, EPERM will be returned."
So another direction may be to give your "userjoe" account the CAP_NET_ADMIN rights, but I would advice against this. Security wise it's not better, if not worst, than to be part of the sudo'ers and explictly sudo when you need to.

Related

tmux shared socket throws "access not allowed" error

I am using tmux 3.3a on an Ubuntu 22.10 system with two users, bob and alice.
Both users are members of the multiplexer group.
Bob has created a tmux session on an custom socket like so:
tmux -S /tmp/our_socket new -s our_session
and then changed the group of the socket file to multiplexer and added read/write permissions for that group:
chgrp multiplexer /tmp/our_socket
chmod g+rw /tmp/our_socket
Now alice, who is also a member of the multiplexer group, is trying to connect to this session using:
tmux -S /tmp/our_socket attach -t our_session
which throws an access not allowed error.
However when alice uses sudo-privileges, she is able to connect to the tmux session.
I do not understand why access is denied without elevated privileges, as the socket file has read/write permissions for the multiplexer group and both bob and alice are members of that group. My guess is, that it's connected to the sticky bit enabled for the /tmp directory, but I'm not sure.
I had a similar problem. It seems that the later versions of tmux have its own access check as well. So, in addition to making the socket accessible to the user you want to share the session with, you also need to tell tmux that this user is allowed.
tmux server-access -a {user_to_share_with}
For more info, see the description of tmux "server-access" command.
P.S. As a bonus, the user can be allowed read-only access only now!

How to get started with RDMA and Soft ROCE using loopback device?

For various reasons, I'm trying to get a Soft-ROCE setup working. The plan is to move to RDMA-capable hardware, later, but for now Soft ROCE is a good choice to get started. I've started with some tutorials on Infiniband APIs, and they mostly make sense. However, I haven't been able to get even a single transaction working in a loopback device.
I created an rxe device using the following command:
# rdma link add rxe_lo type rxe netdev lo
It seems to come up fine, but none of the utilities I run seem to do anything (rping, ibv_rc_pingpong, etc.).
With my loopback device, rping fails like this:
# rping -c -v -a 127.0.0.1
rdma_resolve_route: No such device
If I create Soft ROCE devices on two separate computers, and then run that over the network, rping at least works:
# rdma link add rxe_eno1 type rxe netdev eno1
# # do the same on different computer...
# rping -s -v -a 0.0.0.0
# rping -c -v -a 192.x.y.z # on other computer
Is this a futile attempt, or is there a technical reason why local loopbacks won't work with Soft RDMA? I tried this on an Ubuntu and Fedora system, with the same results.

SeLinux blocking mod-evasive (Apache) from running a command as sudo

I am trying to configure mod_evasive in my CENTOS7 server (VPS) to prevent DDOS attacks.
I followed the steps mentioned in the following tutorial. (this link) Although I am not using IPTABLES, I am using firewalld instead.
In mod_evasive, the directive to execute a shell command when an IP is blacklisted is DOSSystemCommand. But when an IP is blocked, the script I want to run which will submit the IP address to firewalld to block, is blocked by SeLinux. According to what I understood after looking at the audit.log is, SeLinux does not allow apache user to run a command as sudo. Even though this is allowed via the sudoers file.
(mod_evasive is working properly, I verified this my running the test script provided by mod_evasive. I also get the email when an IP is blocked)
Following are the specifics;
mod_evasive.conf file (only the DOSSystemCommand directive shown below)
DOSSystemCommand "sudo /var/www/mod_evasive/ban_ip_mod_evasive.sh"
I have also tried the below variation (with different users too, Ex. root user)
DOSSystemCommand "sudo -u apache '/var/www/mod_evasive/ban_ip_mod_evasive.sh %s'"
Sudoers file (only the part I have modified for this purpose [allow apache to run as sudo)
apache ALL=(ALL) NOPASSWD:ALL
Defaults:apache !requiretty
I have allowed apache to run as any user for all scripts, just for testing purposes. Initially I had restricted the command as follows
apache ALL=NOPASSWD: /usr/local/bin/myscripts/ban_ip.sh
Defaults:apache !requiretty
My ban_ip.sh file
#!/bin/sh
# IP that will be blocked, as detected by mod_evasive
IP=$1
sudo firewall-cmd --add-rich-rule 'rule family="ipv4" source address="`$IP" service name="https" reject'
I have verified that the configuration is working by running the following
sudo -u apache '/usr/local/bin/myscripts/ban_ip.sh 111.111.111.111'
The above command successfully adds the rule to firewalld.
This entire setup works when I disable SeLinux.
After I enable SeLinux the following errors appear in the audit.log
type=AVC msg=audit(1593067671.808:1363): avc: denied { setuid } for pid=3332 comm="sudo" capability=7 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=capability permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
type=AVC msg=audit(1593067671.808:1364): avc: denied { setgid } for pid=3332 comm="sudo" capability=6 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=capability permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
The following flags are set in SeLinux
httpd_mod_auth_pam
httpd_setrlimit
I am not sure why SeLinux blocks this, therefore I am skeptical to create a custom policy to allow this behavior as audit2allow suggests.
audit2allow output
#============= httpd_sys_script_t ==============
allow httpd_sys_script_t self:capability { setgid setuid };
#============= httpd_t ==============
allow httpd_t systemd_logind_t:dbus send_msg;
I feel mod_evasive would not help in stopping a DDOS if we can not block the IP rather than merely sending a 403 forbidden response to the attacker. This will still consumer the server resources.
How can I solve this and what other alternatives I can implement to mitigate DDOS and enhance my VPS protection?
thanks for your help

Obtain ssh version externally using nmap

I would like to know if I can obtain ssh version using nmap of my external vps.
nmap -p 22 sV <domainname>
result:
22/tcp filtered ssh
Is there another nmap syntax so I can obtain ssh service version?
Just want to obtain the ssh service version of my external vps.
I tried alot of nmap commands but probably there's a struggle in-between like a firewall, which causes a filtered state. My own network is behind a DrayTek Device. Maybe a possible cause?
Thanks in advance!
The nmap option --badsum is able to provide insight about the existence of a firewall. A non firewall device that runs a full network stack will silently drop a bad checksum. In the case that your scan reaches an end device, you would expect to see the same result as your -sV scan. A firewall may offer a different reply to the --badsum.
The answer to your question regarding version, is that -sV is ideal, however -A may run some scripts that return useful information. You can also run --script=sshv1 or another specific script that is ssh related. More script options are here nmap scripts.

MongoDB cannot remote access

I'm new to linux server. I install mongodb on centos 6.3. And I run the mongodb server in this command:
mongod -config /etc/mongodb.conf &
And i'm sure that I have make bind_ip to listen all ip:
# mongodb.conf
# Where to store the data.
dbpath=/var/lib/mongodb
#where to log
logpath=/var/log/mongodb/mongodb.log
logappend=true
rest = true
bind_ip = 0.0.0.0
port = 27017
But, I cannot make mongodb remote access either. my server ip is 192.168.2.24,and I run mongo in my local pc to access this mongodb, it show me this error:
Error: couldn't connect to server 192.168.2.24:2701
7 (192.168.2.24), connection attempt failed at src/mongo/shell/mongo.js:148
exception: connect failed
But, I can access this mongodb in server where mongodb install using this command:
mongo --host 192.168.2.24
So, I think it may success to make mongo remote access, but maybe something wrong with linux server,maybe firewall? So,I try to use the command to check the port whether open for remote access:
iptables -L -n | grep 27017
nothing is returned, then I add port to iptalbes using this command:
iptables -A INPUT -p tcp --dport 27017 -j ACCEPT
iptables -A OUTPUT -p tcp --source-port 27017 -m state --state ESTABLISHED -j ACCEPT
and save the iptables & restart it:
iptables-save | sudo tee /etc/sysconfig/iptables
service iptables restart
I can see port of 27017 is added to iptables list, but it still not work at all. I think it may not success in opening the port of 27017. How should I do for it? I'm new to linux server,by the way my linux server pc is offline. So it can't use the command about "yum". please give me solution in detail. Thanks so much.
It seems like the firewall is not configured correctly.
Disclaimer: Fiddling with firewall settings has security implications. DO NOT USE THE FOLLOWING PROCEDURE ON PRODUCTION SYSTEMS UNLESS YOU KNOW WHAT YOU ARE DOING!!! If in the slightest doubt, get back to a sysadmin or DBA.
The problem
Put simply, a firewall limits the access to services like MongoDB running on the protected machine by unauthorized parties.
CentOS only allows access to ssh by default. We need to configure the firewall so that you can access the MongoDB service.
The solution
We will install a small tool provided by CentOS < 7 (version 7 provides different means), which simplifies the use of iptables, which in turn configures netfilter, the framework of the Linux kernel allowing manipulation of network packets – thus providing firewall functionality (amongst other cool things).
Then, we will use said tool to configure the firewall functionality so that MongoDB is accessible from everywhere. I can't give you a more secure configuration, since I do not know your network setup. Again, use this procedure on production systems at your own risk. You have been warned!
Installation of system-config-firewall-tui
First, you have to log into your CentOS box as root, which allows installation and deinstallation of packages and change system-wide configurations.
Then, you need to issue (the dollar sign denotes the shell prompt)
$ yum -y install system-config-firewall-tui
The result should look something like this
Configuration of the firewall
Next, you need to start the tool we just installed
$ system-config-firewall-tui
which will create a small command line GUI:
Do not simply disable the firewall!.
Press Tab or →| respectively, until the "Customize" button is highlighted. Now press ↵. In the next screen, highlight "Forward" and press ↵. You now should be in a screen called "Other Ports",
in which you highlight "Add" and press↵. This brings you to a screen "Port and Protocol" which you fill like shown below
The configuration explained: MongoDB uses TCP for communicating with the clients and it listens on port 27017 by default for a standalone instance. Note that you might need to change the port according to the referenced list in case you do not run a standalone instance or replica set.
The next step is to highlight "OK" and press ↵, which will seemingly clear the inputs. However, the configuration we just made is saved. So we will press "Cancel" and return to the "Other Ports" screen, which should now look like this:
Now, we press "Close" and return to the main screen of "system-config-firewall-tui". Here, we press "Ok" and the tool asks you if you really want to apply those the changes you just made. Take the time to really think about that. ;)
Pressing "Yes" will now modify the firewall rules executed by the Linux kernel.
We can verify that by issuing
$ iptables -L -n | grep 27017
which should result in the output below:
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:27017
Now you should be able to connect to your MongoDB server.