One of our clients has a wrong configured device which sends a wrong username. He can not find the device, so fail2ban keeps blocking him. When we add the ip to the whitelist it works, but he gets banned again, when his router sets a new ip address.
So, my idea was to set up a fail2ban filter to ignore his specific username in postfix and doevecot.
How would such a filter look like?
This is not a filter what you need, but rather an ignoreregex in jail configuration (one per jail dovecot or postfix).
Note that how the regex may look is depending on how the log-line (which cause the ban) would look.
If your log-line (which cause ban) looks for example like this:
... auth-worker(123): Info: sql(certain-user#example.de,192.0.2.1,<sessionid>): unknown user
you can add to the jail following config (in your jail.local):
[dovecot]
...
_ignore_users = (?:certain-user|some-user|another-user)#example.de
ignoreregex = sql\(%(_ignore_users)s,[^\)]*\): unknown user$
...
And fail2ban would stop banning such users if ban occurs only by this kind of messages, otherwise you have to write ignoreregex for several message formats.
Just by the way:
One of our clients has a wrong configured device which sends a wrong username. He can not find the device...
His system e. g. some of his hosts may be part of some botnet (always trying a bruteforce for some single username), so it is probably not advisable to white-list him.
When we add the ip to the whitelist it works, but he gets banned again, when his router sets a new ip address
If he has some kind of DynDns (or can configure it in his router), you can add its FQDN to ignoreip instead of IP.
Related
this is my first question here so I apologize if don't comply with the best practices.
Recently I've been a victim of a POST HTTP slow DDoS attack using different IPs on similar and different ranges on my server.
I've managed to mitigate it using fail2ban by creating a personalized filter for my specific needs:
[Definition]
failregex = ^<HOST> .*POST .*xmlrpc\.php.*
^<HOST> .*HEAD .*m.y.i.p.:80.*
ignoreregex =
These two were the most recursive attempts at my server: 'POST xmlrpc.php' request and a 'HEAD http://m.y.i.p/{phpmyadmin|phpwhatevervariation|etc...}'.
I successfully managed to block them using my local jail as this
[nginx-xmlrpc]
enabled = true
filter = nginx-xmlrpc
action = route
logpath = /var/log/nginx/access.log
maxretry = 3
findtime = 10800
bantime = 86400
The problem is that I was keeping myself locked out every so often during development. So I decided to whitelist myself. Unfortunately, my ISP provides dynamic ips, so I had to associate a hostname to zonomi and use DDNS to update my subdomain with my new assigned IP addresses every so often. I then added my hostname to my ignoreip entry on the local jail as this:
# MISCELLANEOUS OPTIONS
#
# "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not
# ban a host which matches an address in this list. Several addresses can be
# defined using space separator.
ignoreip = 127.0.0.1/8 my.hostname.sub.domain
Today I was working on the webserver and I got blocked, so I checked my hostname and it hasn't updated my IP. I manually did it and after the DNS spread over and the hostname's ip changed, I tried to access my website/server with no success.
It appears to me that either: (1) once the ban was set I would have to restart fail2ban to flush the block on my IP (which I dislike due to the fact that all the other IP's blocked are forgotten, the real threats) or (2) somehow fail2ban wasn't able to update my hostname's associated IP.
My question is: If it's (1), is there a way to lift the block automatically without restarting fail2ban or, in case it's (2), is there a way to update my hostname's ip automatically?
Does fail2ban uses IPTABLES? Should I cron a chain flush with my hostname's IP on iptables every minute?
Kindly,
A.
Fail2Ban uses iptables. As per fail2ban's documentation, it allows whitelisting based on hostname or ip addresses:
http://www.fail2ban.org/wiki/index.php/Whitelist
You should use a Dynamic DNS service, set a small TTL for your hostname (like 600 which amounts for 10 minutes). You can go even with 300 (it's not complaint with the standard but it will the job). Then check and see. If your DDNS hostname was created with a default TTL which in most of the cases for A records is between 3600 and 14400 (1 hour - 4 hours) then that might be the reason.
I'm creating a custom sign-in/sign-up in Meteor because I need to check the email format and more importantly to add a recaptcha in the sign-up form, which requires the client's ip.
So I plan to verify the captcha in Accounts.validateNewUser, but I cant figure out how to get the client's ip here.
I read an answer on how to do that, but it's not where I want to. I checked Meteor.default_server.sessions which contains all the sessions/sockets on the server. They contain information about headers, ips of all sockets. Each one has interesting stuff like:
pathname: "/sockjs/375/ibmrlwb2/xhr"
prefix: "/sockjs"
protocol: "xhr-polling"
remoteAddress: "127.0.0.1"
remotePort: 42009
But without knowing which socket is the current one, I cannot determine which ip of the current request is.
How can I know the current request url to the server? With that I can check with all the sockets on the server to infer the client's ip.
Or just simply how can I get the client's ip on the server?
I'm the maintainer of the user-status package mentioned in the other answer.
Recent/upcoming versions of Meteor have better support for managing connections as well as built-in support for grabbing IP addresses. Combined with the fact that login hooks were just merged into the devel branch today, you should be able to either handle this directly or use something that we'll add to the user-status package.
Feel free to open a pull request if there is something you need.
Getting the client's ip can be done with the user-status package. You can either use package or look through the code and see how it is being done.
I run my own sip server (asterisk). Apparently my sip server allows to perform an INVITE without doing any REGISTER first. This leads to lots of unsuccessful attacks on my server. IS there any way to allow INVITE requests only from a successfully REGISTERed clients? Through asterisk or iptables?
You need change allowguest parameter to no in your sip.conf.
Check the link below for more tips about security in asterisk:
http://blogs.digium.com/2009/03/28/sip-security/
My study so far tells me that REGISTER is only for asterisk to reach or forward the INVITES but not to authenticate an INVITE request. When an INVITE comes, asterisk tries to check the given user name and if its a valid one, it sends a 407 (Authentication required) back to the client. Then client inserts the password (encrypted) in the response and sends INVITE2 to server. Now server authenticates the user and when credentials match, proceeds with establishing the call.
Conclusion: An INVITE has no relation with REGISTER and so my idea of restricting only REGISTERED clients to send an INVITE is not possible.
As a workaround, I have written my own script. Source is at https://github.com/naidu/JailMe
Consider a real Session Border Controller which pays for itself quickly when you get hacked. However, if you want a "good enough" option then read on:
There is an iptables module called "string" which will search a packet for a given string. In the case of SIP we expect to see "REGISTER" in the first packet from any given address, so combine this with -m state --state NEW or something similar. After that, we would want keep-alive happening to ensure that connection tracking remains open (usually Asterisk sends OPTIONS, but it can send empty UDP). You want that anyway in case the client is behind NAT.
It's not the ideal solution, because iptables cannot figure out whether a registration has been successful, but at least we can insist the other guy makes an attempt at registration. One of the answers linked below shows use of the string module in iptables:
https://security.stackexchange.com/questions/31957/test-firewall-rules-linux
You could also put an AGI script into your dialplan that does some additional checking, potentially looking at IP address and whether the extension is registered... ensure the INVITE comes from the same source IP.
Fail2Ban is an easy way to block unwanted traffic! fail2ban check system logs for failed attempts, if there are too many (exceeding defined threshold) failed attempts in specified time from some remote IP then Fail2Pan consider it as attack, and then add that IP address in iptables to block any type of traffic from it. following links can help
http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk
http://www.markinthedark.nl/news/ubuntu-linux-unix/70-configure-fail2ban-for-asterisk-centos-5.html
I have been asked to get details of every user that logs into our website. Is it possible to capture the IP address of every user that logs into our website from which I can gather details using IP lookup software.
It's already captured. Check out the web logs for whatever your webserver is.
In IIS, it's likely in C:\Windows\System32\LogFiles. Apache will normally be in /var/log.
You can tweak the specifics of what it captures, but by default IP address is always included.
Unless you are explicitly required to store the ip:s yourself, I recommend using Google Analytics, which will sort out unique/returning visitors, geographical locations and so on.
I have a web application that should behave differently for internal users than external ones. The web application is available over the Internet, and therefore obviously to the internal users as well.
All the users are anonymous, not authenticated, but the page should render differently for internal users than external. What I'm doing in my code is use Request.UserHostName and then Dns.GetHostEntry. The result is then compared to a setting in my web.config (that holds something like *.mydomain.local) . If the comparison gives a positive result then I render the HTML that the internal user should see otherwise I render the HTML the external user should see.
However, my problem is that I don't always get the expected value from Request.UserHostName. on the development site I get the IP-number (?) of the machine running the browser but on the customer site I don't get the IP-number of the user machine, I get some other IP-number. The browsers don't have any proxies set or anything like that.
Should I be using something else than Request.UserHostName?
I recommend using IP addresses as well. I'm dealing with this exact same situation setting up an authentication system right now as well and the conditions described by Epso and Robin M are exactly what is happening. External users coming to the site give me their actual IP address while all internal users provide the IP of the gateway machine(router) on to the private subnet the webservers sit on.
To deal with it I just check for that one IP. If I get the IP of the gateway, I provide the internal access. If I get anything else they get the external one which requires additional authentication in my case. In yours, it would just mean a different interface.
Try Request.UserHostAddress, which returns the client's IP address. Assuming your internal network uses IP addresses reserved for LANs, it should be relatively simple to check if an IP is internal or external.
There might be a firewall that is doing some sort of NAT, to enable inside clients to use the external dns-name to reach the server.
Is the IP-number you get on customer site the same at the external customer-server ip? In that case you can hard code for that one IP-address. All internal computers behind that firewall will appear to have to same ip-address and you can classify them as "internal".
It looks like you're being returned a public facing IP Address. Get the user to go to http://www.myipaddress.com . If this is the same as the IP Address returned to your software, then this is definitely the case.
The only solution I can see to get around this is to either get them to connect to the machine holding the asp.net application via a VPN, or to use some other kind of authentication. The latter is probably the best option.
It does sound like there is a proxy between users and the server on the customer site (it doesn't need to be configured in the browser). It may be an internal or external proxy depending on your network configuration.
I would avoid using the UserHostName for what is effectively authentication as it is presented by the browser duing the request and would be easy to spoof. IP address would be much more effective as it's difficult to spoof an IP address in a TCP/IP connection (and maintain a connection). It's still weak authentication but may be sufficient in this scenario.
Even if you are using IP address, if there's a NAT proxy between client and server, you may have to accept that anything coming through that proxy is trusted (I'm assuming that external/untrusted clients don't come through that proxy).
If that isn't acceptable, you're back to other methods of authentication. Rather than requiring a logon or VPN connection, you might consider a permanent cookie or client certificates and only give those to internal clients but you would need some way of delivering those to the client. You could certainly deliver a permanent cookie based on a one-time logon. Cookies can be spoofed in a similar way in that the UserHostName can be however you've got a better opportunity to create a cookie value that is less guessable than a domain name.