So I'm baffled, no dynamic IP is activated on either the router side or my local desktop side. I have to change my IP in Azure almost twice a day. I'm getting scared as it might be a security issue. I tried to write into a chat and it told me that I'm not allowed to use it, because I'm using a proxy, which I don't, not even VPN, so I'm asking you what I should do or if I should be scared?
(scanned the PC and there were no issues)
IPs are not likely to change like that for residential users, you can double check however by logging into your modem and determining the IP of your WAN. This won't reveal the proxied IPs/etc, but what your ISP sent you.
If that's changing then sure, no issues but odd.
Now if that's fixed and it's still changing, you may have a proxy installed and forgot to turn it off.
I'd not worry personally but you could be subject to MITM man in the middle stuff. Best you can do is sort this and if you deem it to be MITM to just change passwords/etc ezpz.
I never use honeypot before. But, I have a task from my lecture, that I should use a honeypot for detecting hackers attacks.
I searched in journals, tutorials and articles. I tried using honeydrive3 and used the honeypot Kippo. When I tried that, and I attack by myself, it works, the detailed of attack is served. But, when I told that to my lecturer, he said it was not what he wanted.
The workflow he want is, we use the honeypot and then we try that to some websites. But, when the attacker scanning or do something to that web IP address, it must deflect to the honeypot, it means that the attacker really attacks the real website.. and I really don't know what to do.
You either misunderstood what the lecturer wanted, or what he wants does not make sense.
You can only analyze traffic sent to your IP (or an IP you control), it is not possible for you to "deflect the traffic" from a generic IP address.
What you did is correct: putting in place the honeypot, and then sending some traffic to it.
The next step would be to expose it to Internet to get malicious traffic (directed to your IP) but you must be very careful as the whole machine is likely going to get successfully attacked. It must not have any connection to your (home|uni|private) network, because (I am being frank reading your question), you stand no chance to secure it for the time being.
I would go for a cloud hosted machine which I would then kill.
So here is an approach I was thinking of:
PROBLEM:
- after you have done everything possible to secure your servers and client app. I wanted to add an extra layer to make sure even if a user looses access to their data, they can only really affect their own little space in a shared database. (obvisouly authentications are in place but this is the basis of the authenticatino model)
SOLUTION I HAD IN MIND:
- I wanted to add a "hidden" field that stores users IP addresses.
This means when a user does the normal password and usenrame entry, they also have to verify whether the machine they are using is their own, and thus we store that IP address by taking it from their request.
Later if they need to log in again they can, but if they want to retrieve data, the look up on the router server will recieve the IP from the request, add that onto the message as part of the filter parameters.
Once it queries the database if the combination of IP + data that users wants is found then it sends that back.
If a different IP is detected then no data exists in the server so nothing is sent back. which would initially be done on login and would trigger a mail to the user to verify the machine they are using is trusted.
Is there an easier way? is this overegging?
Thanks,
Alex
Tried ip-request module in Express, works fine, but wanted to know if there was a potential security threat with the way I am using this and it will be implemented before proceding.
First off, an IP address your server sees is often not the actual IP address of the computer the user is on because there is often a NAT device or proxy in between that maps a private network IP address of the user's machine to a public IP address for use on the internet. This would be true whether you were using a computer on your home network, using a computer at work, connected via WiFi at Starbucks, etc...
User Computer (private IP 192.168.1.x) => Gateway (some public IP address) => Your server
If the same computer connected to your server the same way over and over, it "might" be assigned the same public IP address every time it does so. But, in other circumstances it might not.
If the same computer is mobile at all (phone, laptop, tablet) and connects to the internet in different ways (WiFi, cellular), then it may show as a different IP address every time it connects from a different location.
So, in these days of lots of mobile devices and a user that may even access a service from more than one device, an IP address is just NOT a good measure of whether this is a risk or not.
Furthermore, in the case of shared NAT such as a WiFi hotshot or connecting from a corporate network, it's possible for lots of different users to all appear to be coming from the same public IP address.
I would not suggest using IP address at all as any security indicator. You will just get lots of false indicators of an invalid IP address that changed since last access and you may even get false positives where a different user appears on the same IP address as a legit user. In these days of NAT and mobility, there is no one-to-one correspondence between a public IP address and a user. Trying to pretend there is will cause all sorts of problems.
I am dealing with an application that is protected by a firewall and only allows access from certain IP-Addresses (which are application webservers).
Its a bit delicate and it would be much hassle to introduce another authentication/protection layer.
My understanding of networking is not great because its not my subject, but in my Head I made up the following scenario:
Someone knows the IP-Address of one of our application servers and wants to fake it to get access to the other application which he knows the listening socket and protocol of.
So he alters the Header of his IP packets to have the Webserver IP as transmitter.
What happens next?
A: His ISP rejects the packet and says "Hey, that is not the IP address you were assigned from me." - Problema Solved
B: The ISP passes the packet on to the next level (his up-link...)
Lets assume the ISP has been compromised or the packet is passed on without inspection (I don't know whether that's the case)
What happens next?
A: The carrier rejects the Packet and says "Hey, that IP is not in the range of IP we agreed you are operating on!" - Now if my webserver isnt operated by the same ISP that my attacker compromised - Problema solved
B: The ISP doesn't inspect the packet or is compromised and forwards it to his up-link.
Now I am quite sure that IP addresses ARE inspected and filtered when passing a router. Otherwise it would be total anarchy.
So to put this straight: An Attacker that wants to fake my IP-Address needs to compromise the VERY same ISP that is in charge of the IP-Range my Webserver operates in - or this ISP does not do packet inspection.
Is this correct?
Okay now I imagine my server is located in an office and its ISP is a regional cable company.
What would be the steps necessary to send packets from my IP address to another internet IP?
(Of course I am only asking to get aware of the risks and choose proper protection!)
I imagine locating the routing station which is often in some small container at the side of the street that is only protected by a lock. Going in there. Swapping cables or plugging yourself into.
Will this most likely work if you know what you are doing or is there some encrypted handshake with keys stored on the real offices modem that is required to built an authenticated connection?
I am talking about today's standards in cable internet.
Last thought: So if my origin server is not some household ISP that has its stations vulnerable on the street i should be pretty safe, right?
I remember that NFS servers relies on IP authentication ONLY as a default. Because this is pretty common - are there any examples where NFS servers got hacked by faking IP addresses?
I realise that this question is put very very vagly. This is because I am not sure about anything I am saying here. I just wanted to give some input where I think the cave-eats could be, so they can be confirmed or eliminated.
Overall I am grateful for any comment and your personal thoughts about that subject!
Now I am quite sure that IP addresses ARE inspected and filtered when passing a router.
This assumption is incorrect, despite your level of sureness. "Egress filtering", which is the name of this, is generally not done.
The major protection against widespread spoofing of IP addresses is that the attacker would not recieve any response packets - they would all be routed back to the host that is legitmately using the IP address being spoofed. This kind of attack is known as "blind spoofing", because the attacker is working blind.
In order to send data on a TCP connection, you must be able to finish the TCP "three-way handshake". This requires knowing the initial sequence number used by the opposite end - and since TCP initial sequence numbers are chosen reasonably randomly1, this prevents a blind spoofing attack from being able to do this. (Note also that this does not apply to UDP - without some kind of application layer preventative, UDP is at significant risk from blind spoofing).
If the attacker can see the replies coming back (say, because he is sniffing the uplink or the local network of your server), then this also doesn't apply - spoofing TCP connections in this case is not just possible but trivial.
1. These days, anyway - this wasn't always the case.
Inside a LAN it depends on how your routers/switches/hubs are configured. But I think spoofing should be possible quite often.
I don't think the IP address is inspected. Thus you can send UDP packets with forged sender IP. But you won't receive the answer since the server will send it to the real owner of that IP.
This means you can't simply fake an IP in TCP since establishing the connection needs a handshake.
You can forge the IP of somebody if the response will go through your router. So a network admin can fake all IPs inside his LAN, an ISP all IPs inside his net, and a carrier can fake IPs on many international connections, provided they get routed through him.
Finally there is the possibility of abusing BGP to modify the routes for that IP to go through your computer. But not everybody has access to BGP, you probably need to become an ISP to get it. And then the manipulation will probably be detected because BGP route changes are monitored.
I'm planning to deploy an internal app that has sensitive data. I suggested that we put it on a machine that isn't exposed to the general internet, just our internal network. The I.T. department rejected this suggestion, saying it's not worth it to set aside a whole machine for one application. (The app has its own domain in case that's relevant, but I was told they can't block requests based on the URL.)
Inside the app I programmed it to only respect requests if they come from an internal I.P. address, otherwise it just shows a page saying "you can't look at this." Our internal addresses all have a distinct pattern, so I'm checking the request I.P. against a regex.
But I'm nervous about this strategy. It feels kind of janky to me. Is this reasonably secure?
IP filtering is better than nothing, but it's got two problems:
IP addresses can be spoofed.
If an internal machine is compromised (that includes a client workstation, e.g. via installation of a Trojan), then the attacker can use that as a jump host or proxy to attack your system.
If this is really sensitive data, it doesn't necessarily need a dedicated machine (though that is best practice), but you should at least authenticate your users somehow, and don't run less sensitive (and more easily attacked) apps on the same machine.
And if it is truly sensitive, get a security professional in to review what you're doing.
edit: incidentally, if you can, ditch the regex and use something like tcpwrappers or the firewalling features within the OS if it has any. Or, if you can have a different IP address for your app, use the firewall to block external access. (And if you have no firewall then you may as well give up and email your data to the attackers :-)
I would rather go with SSL and some certificates, or a simple username / password protection instead of IP filtering.
It depends exactly HOW secure you really need it to be.
I am assuming your server is externally hosted and not connected via a VPN. Therefore, you are checking that the requesting addresses for your HTTPS (you are using HTTPS, aren't you??) site are within your own organisation's networks.
Using a regex to match IP addresses sounds iffy, can't you just use a network/netmask like everyone else?
How secure does it really need to be? IP address spoofing is not easy, spoofed packets cannot be used to establish a HTTPS connection, unless they also manipulate upstream routers to enable the return packets to be redirected to the attacker.
If you need it to be really secure, just get your IT department to install a VPN and route over private IP address space. Set up your IP address restrictions for those private addresses. IP address restrictions where the routing is via a host-based VPN are still secure even if someone compromises an upstream default gateway.
If your application is checking the IP Address, then it is extremely vulnerable. At that point you don't have any protection at the router which is where IP filtering really needs to be. Your application is probably checking HTTP header information for the sending IP address and this is extremely easy to spoof. If you lock the IP address down at the router, that is a different story and will buy you some real security about who can access the site from where.
If are you are doing is accessing the application internally, then SSL won't buy you much unless you are trying to secure the information from parties internal to the organization, or you require client certificates. This is assuming you won't ever access the site from an external connection (VPNs don't count, because you are tunneling into the internal network and are technically part of it at that point). It won't hurt either and isn't that hard to setup, just don't think that it is going to be the solution to all your problems.
IP Whitelisting is, as others have mentioned, vulnerable to IP spoofing and Man-in-the-Middle attacks. On an MITM, consider that some switch or router has been compromised and will see the "replies". It can either monitor or even alter them.
Consider also vulnerabilities with SSL encryption. Depending on the effort, this can be foiled in a MITM as well, as well as the well-known gaffs with the reuse of the primes, etc.
Depending on the sensitivity of your data, I would not settle for SSL, but would go with StrongSWAN or OpenVPN for more security. If handled properly, these will be a lot less vulnerable to a MITM.
Reliance on whitelisting alone (even with SSL) I would consider "low grade", but may be sufficient for your needs. Just be keenly aware of the implications and do not fall into the trap of a "false sense of security".
If it's limited by IP address, then although they can spoof the IP address, they won't be able to get the reply. Of course, if it's exposed to the internet, it can still get hit by attacks other than against the app.
Just because all your internal IPs match a given regex, that doesn't mean that all IPs that match a given regex are internal. So, your regex is a point of possible security failure.
I don't know what technology you used to build your site, but if it's Windows/ASP.net, you can check the permissions of the requesting machine based on its Windows credentials when the request is made.
Like all security, it's useless on it's own. If you do have to put it on a public-facing webserver, use IP whitelisting, with basic username/password auth, with SSL, with a decent monitoring setup, with an up-to-date server application.
That said, what is the point in having the server be publicly accessible, then restrict it to only internal IP addresses? It seems like it's basically reinventing what NAT gives you for free, and with an internal-only server, plus you have to worry about web-server exploits and the likes.
You don't seem to gain anything by having it externally accessible, and there are many benefits to having having it be internal-only..
My first thought on the ressource issue would be to ask if it wouldn't be possible to work some magic with a virtual machine?
Other than that - if the IP addresses you check up against are either IPs you KNOW belongs to computers that are supposed to access the application or in the local IP range, then I cannot see how it could not be secure enough (I am actually using a similiar approach atm on a project, although it is not incredibly important that the site is kept "hidden").
A proper firewall can protect against IP spoofing, and it's not as easy as say spoofing your caller ID, so the argument /not/ to use IP filtering because of the spoofing danger is a bit antiquated. Security is best applied in layers, so you're not relying on only one mechanism. That's why we have WAF systems, username+password, layer 3 firewalls, layer 7 firewalls, encryption, MFA, SIEM and a host of other security measures, each which adds protection (with increasing cost).
If this is a web application you're talking about (which was not clear from your question), the solution is fairly simple without the cost of advanced security systems. Whether using IIS, Apache, etc. you have the ability to restrict connections to your app to a specific target URL as well as source IP address - no changes to your app necessary - on a per-application basis. Preventing IP-based web browsing of your app, coupled with IP source restrictions, should give you significant protection against casual browsing/attacks. If this is not a web app, you'll have to be more specific so people know whether OS-based security (as has been proposed by others) is your only option or not.
Your security is only as strong as your weakest link. In the grand scheme of things, spoofing an IP is child's play. Use SSL and require client certs.
It became useful first to distinguish among different kinds of IP vpn based on the administrative relationships, not the technology, interconnecting the nodes. Once the relationships were defined, different technologies could be used, depending on requirements such as security and quality of service.
Maybe this will help ? I've been looking for the same answer, and found this stackoverflow as well as this idea from Red Hat Linux Ent. I'll try it soon. I hope it helps.
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP
Where 0/24 is the LAN range you want to protect. The idea is to block "internet" facing (Forward) devices from being able to spoof the local IP network.
Ref: http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-firewall-ipt-rule.html