I have an application on my linux host that communicates via UDP to another machine via 10G ethernet. The machine on the other end does not respond to ARP requests. I am able to get it's MAC address through other means (a different interface, on
Is there a way to programmatically get this information into the arp table w/out privileged status?
I know I can on a command line issue "sudo arp -s 1.2.3.4 AA:BB:CC:DD:EE:FF" every time I power it up.
I know I can add "1.2.3.4 AA:BB:CC:DD:EE:FF" to etc/ethers
I know that as a priviledged usr/process I can issue an ioctl to SIOCSARP.
All of these mechanism's require sudo/root access. I read something about giving the application "CAP_NET_ADMIN" permissions.
I'm looking for this capability so that the end users don't need to do any of the above. It seems like, If I, w/out sudo/root, can open a socket that determines the need for this network information, there should be a way for me, w/out sudo/root, to provide it.
No, you can't edit ARP information as non-root. This makes sense, as otherwise malicious attacker would be able to modify ARP tables and completely disrupt network communication and compromise security.
The solution to your problem is to fix your network configuration.
Related
A beginner question, but I've looked through many questions on this site and haven't found a simple, straightforward answer:
I'm setting up a Linux server running Ubuntu to store a MySQL database.
It's important this server is secure as possible, as far as I'm aware my main concerns should be incoming DoS/DDoS attacks and unauthorized access to the server itself.
The database server only receives incoming data from one specific IP (101.432.XX.XX), on port 3000. I only want this server to be able to receive incoming requests from this IP, as well as prevent the server from making any outgoing requests.
I'd like to know:
What is the best way to prevent my database server from making outgoing requests and receiving incoming requests solely from 101.432.XX.XX? Would closing all ports ex. 3000 be helpful in achieving this?
Are there any other additions to the linux environment that can boost security?
I've taken very basic steps to secure my phpmyadmin portal (linked to the MySQL database), such as restricting access to solely my personal IP address.
To access the database server requires the SSH key (which itself is password protected).
A famous man once said "security is a process, not a product."
So you have a db server that should ONLY listen to one other server for db connections and you have the specific IP for that one other server. There are several layers of restriction you can put in place to accomplish this
1) Firewall
If your MySQL server is fortunate enough to be behind a firewall, you should be able to block out all connections by default and allow only certain connections on certain ports. I'm not sure how you've set up your db server, or whether the other server that wants to access it is on the same LAN or not or whether both machines are just virtual machines. It all depends on where your server is running and what kind of firewall you have, if any.
I often set up servers on Amazon Web Services. They offer security groups that allow you to block all ports by default and then allow access on specific ports from specific IP blocks using CIDR notation. I.e., you grant access in port/IP combination pairs. To let your one server get through, you might allow access on port 3000 to IP address 101.432.xx.xx.
The details will vary depending on your architecture and service provider.
2) IPTables
Linux machines can run a local firewall (i.e., a process that runs on each of your servers itself) called iptables. This is some powerful stuff and it's easy to lock yourself out. There's a brief post here on SO but you have to be careful. It's easy to lock yourself out of your server using IPtables.Keep in mind that you need to permit access on port 22 for all of your servers so that you can login to them. If you can't connect on port 22, you'll never be able to login using ssh again. I always try to take a snapshot of a machine before tinkering with iptables lest I permanently lock myself out.
There is a bit of info here about iptables and MySQL also.
3) MySQL cnf file
MySQL has some configuration options that can limit any db connections to localhost only - i.e., you can prevent any remote machines from connecting. I don't know offhand if any of these options can limit the remote machines by IP address, but it's worth a look.
4) MySQL access control via GRANT, etc.
MySQL allows you very fine-grained control over who can access what in your system. Ideally, you would grant access to information or functions only on a need-to-know basis. In practice, this can be a hassle, but if security is what you want, you'll go the extra mile.
To answer your questions:
1) YES, you should definitely try and limit access to your DB server's MySQL port 3000 -- and also port 22 which is what you use to connect via SSH.
2) Aside from ones mentioned above, your limiting of PHPMyAdmin to only your IP address sounds really smart -- but make sure you don't lock yourself out accidentally. I would also strongly suggest that you disable password access for ssh connections, forcing the use of key-pairs instead.You can find lots of examples on google.
What is the best way to prevent my database server from making outgoing requests and receiving incoming requests solely from 101.432.XX.XX? Would closing all ports ex. 3000 be helpful in achieving this?
If you don't have access to a separate firewall, I would use ip tables. There are a number of managers available for you on this. So yes. Remember that if you are using IPtables, make sure you have a way of accessing the server via OOB (short for out of band, which means accessing it in such a way that if you make a mistake in IP tables, you can still access it via console/remote hands/IPMI, etc)
Next up, when creating users, you should only allow that subnet range plus user/pass authentication.
Are there any other additions to the linux environment that can boost security? I've taken very basic steps to secure my phpmyadmin portal (linked to the MySQL database), such as restricting access to solely my personal IP address.
Ubuntu ships with something called AppArmor. I would investigate that. That can be helpful to prevent some shenanigans. An alternative is SELinux.
Further, take more steps with phpmyadmin. That is your weakest link in the security tool chain we are building.
To access the database server requires the SSH key (which itself is password protected).
If security is a concern, I would NOT use SSH key style access. Instead, I would use MySQLs native support for SSL certificate authentication. Here is now to configure it with phpmyadmin.
I am trying to use zeroMQ for communicating between 2 processes. The message contains instructions from one process for the second to execute, so that from a security perspective it is quite important that only the proper messages are sent and received.
If I am worried about 3rd parties who may try to intercept or send malicious messages to the process, am I correct in assuming that as long as my messages are sent/received on IP 127.0.0.1 i am always safe? or is there any circumstance where this can be compromised?
Thanks for the help all!
Assumptions and security are usually two things you don't want to mix. The short answer to your question is that sending or receiving traffic to localhost (127.0.0.1) will not, under default conditions, send or receive traffic outside of the local host.
Of course if the machine itself is compromised then you are no longer secure at all.
You've applied the ipc tag, which I assume means that you're using the ipc:// protocol (if not, you should be if all of the communication is happening on one box). In this case, you shouldn't be using IPv4 addresses at all (or localhost), but ipc endpoint names. See here and here.
For ipc, you're not connecting or binding to an IP or DNS address, but something much more akin to a local file name. You just need to make sure both processes refer to the same filename, and that permissions are set so that both processes can appropriately access the directory (see the ZMQ docs for a little more info there, search for ipc). The only difference between an ipc endpoint name and a filename is that you don't need to create the file, ZMQ creates the resource so both processes can communicate with the same thing.
As S.Richmond says, if your machine is compromised, then all bets are off, but there's no way to publish ipc endpoints to the internet if you use them appropriately.
Say the system is linux, I use TPC/IP protocol. When I send data to 127.0.0.1:1024 from A process, then B process get all the data.
How does the system handle these local data traffics?
Does the data go through the network interface card from A to B?
Or they are only manipulated in the memory (much faster than network interface card)?
It'll not be processed by your network card as 127.0.0.1 address is not set on any (it's on loopback device) but it'll go through whole ip stack. Benefits are that you can manipulate this traffic with iptables or iproute tools and whatever you made that way will be ready to work between remote hosts.
If you care more about performance and use only local communiaction consider AF_UNIX socket. You can find more in man socket and man unix.
Check man ipc as well.
I am doing some penetration testing, and im trying to find out, if i can get the IP address of an router if i got the bssid, or any i can get with the AIR tools?
I use Linux Kali with the Air tools atm.
I would say this is pretty damn bad if its possible. Basicly most people´s rounters can be reached through their outside IP. Even companies. :O
So far i tried:
- Passive TCPDUMP
- Active scanning
So basicly, is there a way, if so please give me a hint or the answer :-)
I am 100% refering to some sort of scanning. All kind of cracking, bruteforce, password guessing, access stealing is not what im asking about :-)
You can't do that if target access point is protected with WPA/WPA2.
This is why. Getting WiFi to work involves following steps:
Associate with target access point. If access point is using WPA/WPA2 and you don't know the password, then you cannot proceed to further steps, and certainly cannot know anything about IP address of target access point.
After association, your client (which is typically configured to use DHCP) has no IP address assigned (its IP address is 0.0.0.0). Technically, you can use sniffer at this stage to scan the network and find out IP addressed used, but most sniffers don't like to work with 0.0.0.0 address. To proceed further, your client sends DHCP request, which is served by access point. After getting successful DHCP ack with new IP address, client can proceed to next step.
After getting IP address, client can talk to access point and finally knows its IP address (it was served as default router in DHCP ack) - and that would be the answer to your question (yes, that late in the game!). However, even at that point, full network connectivity cannot be assumed. If access point implements captive portal, then your network access may be restricted until you open up web browser and (depending on wireless provider) either accept usage terms, provide some credentials or pay with credit card.
After passing captive portal, it is possible (but not common) that access point automatically re-associates and gives you completely different IP address (and access point also has different IP address now, from completely different subnet). This would mean that IP address you learned in previous steps was completely useless to you in terms of knowing actual network infrastructure.
You would need a Firewalking tool to get past the 0.0.0.0 you would essentially also need a password cracker that attempts different brute forcing to get the matching wep password for example, if there are not max tries it could work.
Let's say I want to make an application where stored data is encrypted so only my application is able to read it.
But I want the application to be accessed only if the user is on a particular network.
For instance the application is an Android app that deals with medical records in a hospital.
How to be sure that the device is connected to the network of the hospital ? The idea is that outside this network, the app won't work.
The question is not particularly related to wireless networks, wireless devices or Android, this is general to programming and network identification.
Could a certificate do that ? I'm new to this.
Does a network "identifier" could be faked ? For instance I'm pretty sure that a WiFi SSID is easy to fake.
Cheers.
More details:
Let's assume that the point of the local data is not for an "offline mode", but to avoid network latency. In that case, the data needs to remain accessible only if connected to a particular network, in case the device is stolen.
But if there is no way to be sure of the network's identity... What about a server that would answer to the question "Heya am I on the right network ?" and if no response comes out I know that I'm not on the right one ? (Or that the server just does not respond...) But, again, if the app is hacked, that can be faked too.
Interesting problem.
Generally speaking the purpose of storing data locally is so that it can be accessed while "offline".
However, I think there may be some underlying misconceptions here. Presumably the only reason you'd want to do this is to try and prevent a stolen device from giving up it's secrets. Fact of the matter is, you can't. If the device is no longer under your physical control then it's just a matter of time before it can be hacked.
If we are talking about sensitive data, it shouldn't be stored on the devices. Instead the device should retrieve the data it needs from your server when it needs it and delete it locally when no longer necessary.
The fact that you want the device to only work when connected to your local network implies that you can accomplish this goal.
As a side note, this is why things such as "remote wipe" exist. It's also why every time the device connects to your network it needs to test it's authentication and authorization. Point is if someone reports the device lost or stolen then you need to be able to ban it from your network AND, if the device supports this, remotely disable it.
Bearing in mind that it is entirely possible to pull a device from the network and therefore disable a remote wipe from executing.
With that out of the way, there is absolutely no way you can ensure the device is on a given network. All of that can be faked. It's kind of trivial to setup a router of a given name and change it's MAC to masquerade as whatever, and assign it certain IP addresses. For all intents and purposes it could be made to look exactly like an access point you have... And that's just with normal run of the mill wireless routers you can buy at your local computer store.
You could write your program so that the key to decrypt the data is stored on a server on the hospital network. If your program never stores the key, it makes it harder (although not impossible) for someone to access the device's data outside of the network.
As Chris pointed out a remote wipe would definitely be desirable. You could put in logic so that if the device ever attempts to read the data while not connected to the network, it wipes the data (this might lead to unintended wipes). Blacklisting is good too, so that if the device tries to reconnect to the network, you can essentially brick it. One thing that would be really bad is if you have a network outage, and all your devices accidentally get wiped.
Any network can duplicate another's SSID, so that's not reliable. You could start using a combination of SSID and a MAC address of a known router, but MAC addresses can be duplicated (although not on the same network) so that doesn't work either.
Frankly, unless the wireless network in question is using certificates to identify devices you're going to have no reliable way do it it, and even then this supposes you have a way in your application to get the certificate used the wifi network returns during network authentication.
Perhaps you could use IPSec tunnels. Many routers and firewalls support IPSec. What I'm thinking is something like this:
-----------------------------------
/ IPSec tunnel \
+---------+ \
A | IPSec | B Untrusted \
trusted network -------| capable |------- Networks ----------- Your application
| router | Internet, etc.
+---------+
The gateway router/firewall that provides access for the trusted network has an IPSec tunnel configured between itself and your application. On both the router and your application server, the tunnel looks like another network interface. A route on the router directs traffic for your application to the tunnel interface. A filter can be used on the router to ensure traffic is forwarded to the tunnel only if it arrives on interface A (i.e. the trusted network). Traffic arriving on interface B destined to your application can just be dropped by a filter on the router since it's obviously going the wrong way.
If your application binds its listening socket to just the tunnel interface, you'll know you're only accepting connections received over the tunnel.
You can use whatever combination of encryption and authentication mechanisms you want to to ensure the traffic is secure. Most IPSec implementations support just about anything you could want.