I have fail2ban running to protect our freeswitch servers against attack. When an IP address has too many failed logins, it gets banned.
I'd like to get notification of which account is being attacked - not just the IP address.
So a log line might be
2015-09-11 08:27:40.212155 [WARNING] sofia_reg.c:1477 SIP auth failure (REGISTER) on sofia profile 'internal' for [kloch#inbox.ru#004-2025.sb12.dmclub.org] from ip 78.31.75.181
I would like an email sent (or some php script run) that includes the [kloch#inbox.ru#004-2025.sb12.dmclub.org] bit (or even just the whole line)
Is that possible?
My guess is that it isn't, just due to the flow of data from many rows with a common host, so I'm not holding my breath! ;-)
If you configure fail2ban to use the action_mwl Action Shortcut, it will send you a mail with whois information and the full log line.
In /etc/fail2ban/jail.conf, make sure the action setting is set to:
action = %(action_mwl)s
Related
The goal of this is to redirect the traffic from a specific application (The process name matching a specific Text) to a separate gateway address without interfering with other traffic going through my main gateway, since there are network shares and other servers connected that cannot lose the connection. I have already been able to redirect specific IPs that I found in the Resource Manager, but they constantly change and sometimes parts of Programs access different servers which I cannot see until they are used, obviously.
The desired end result would be a list of IP addresses that the given Process is using. On this list I want to run a loop which basically routs the IP addresses to the other gateway:
route add IP mask 255.255.255.255 otherGateway
SysInternals TCPVcon (TCPView for console) can do that. It has a command line option to output the result as CSV.
tcpvcon [-a] [-c] [-n] [process name or PID]
Use proxy setting in app. If there is nonthing about proxy, try using ProxyCap or similar software.
Alternatively you can use ProcMon and TCPView to get all connections made by process.
But beware of
network calls can be made by child processes (ex., app.exe starts powershell that makes request)
IP addresses can change due to many reasons.
I've installed Postfix as mail server following this tutorial.
I've no problem sending emails. I would like to use the mail server to trigger a shell script each time a mail is received. To do so I've added the following code to the 'aliases' file:
myemailaccount: "|/home/pi/Desktop/TestScript/TestShell.sh"
The shell is also quite simple, I only try to generate a text file in order to know if the shell has been executed :
#!/bin/sh
echo "Let's check if this works!" > Output.txt
So I've tried to send an email to 'myemailaccount#gmail.com' waiting to see the file 'Output.txt' to be generated but nothing happens. If I run the shell from the terminal, no probs, it works.
It's seems that you have setup Postfix to send emails thru Gmail.
To receive emails from outside is another painfully road with a lot of tricky parts.
To receive emails you need a Reverse IP from you ISP and check if port 25 is visible outside. Email servers check for this ports to issue SMTP protocol verifications.
Nowadays, you also need a valid certificate to operate TLS and SSL over you server.
You can use Let's Encrypt free ones.
Don't forget to setup DKIM, SPF and MX stuff in your DNS.
You also need to setup Dovecot or Courier servers:
https://docs.gitlab.com/ee/administration/reply_by_email_postfix_setup.html
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-postfix-e-mail-server-with-dovecot
If you are confused why do you need both Dovecot and Postfix, Read This!
But you can check this solution, if you don't need too much tech:
Execute script when new email arrives (Postfix / Dovecot)
I discovered OpenSIPS and all the possibilities a few days ago. I would just use it as a simple SIP proxy to get started. Proxy between my designated UAC and my UAS (asterisk, not natted). The goal is to use a proxy to prevent bot attacks on my UAS.
After installing OpenSIPS, I tried to configure my XLITE (natted) by simply adding the proxy URL in the configuration. It works, I register and I can see in my UAS peers my extensions with proxy IP. But when I make a call, I got a forbidden error. In debug mode, the log does not talk to me, I see a lot of information but nothing about this error.
I did not make any changes to the default configuration script. Is this behavior normal?
I also tried with VM on public IP as UAC (so not named), same thing.
Thank you for your help.
Olivier
Most likely, your SIP INVITE is hitting this block:
if (!is_myself("$rd")) {
send_reply("403", "Relay Forbidden");
exit;
}
What this means is that your OpenSIPS does not consider itself responsible for the domain (or IP) that your SIP UA has placed in the Request-URI and is trying to route towards. To fix this, just whitelist the Asterisk IP as a local (recognized) domain using the alias statement:
listen = udp:*:5060
alias = 1.1.1.1
I have a machine with CoreOS 1800(or 1855) installed onto disk, and with following systemd-networkd config (there is only one network interface in the machine):
$ cat /etc/systemd/network/zz-default.network
[Network]
DHCP=yes
[DHCP]
ClientIdentifier=mac
UseMTU=true
UseDomains=true
Another notable thing is that this machine is also configured with PXE boot but PXE server will reject boot so it will finally boot from disk.
When I restart the machine, there will be two DHCP IPs allocated for it, I confirmed it by checking /var/lib/dhcpd.leases in DHCP server:
lease 100.79.223.152 {
starts 5 2018/09/28 02:34:00; ends 6 2018/09/29 02:33:59; tstp 6 2018/09/29 02:33:59; cltt 5 2018/09/28 02:34:00;
binding state active; next binding state free; rewind binding state free;
hardware ethernet 08:9e:01:d9:28:64;
option agent.circuit-id 0:5:8:b9:1:0:29;
}
lease 100.79.223.150 {
starts 5 2018/09/28 02:34:29; ends 6 2018/09/29 02:34:28; tstp 6 2018/09/29 02:34:28; cltt 5 2018/09/28 02:34:29;
binding state active; next binding state free; rewind binding state free;
hardware ethernet 08:9e:01:d9:28:64; uid "001010236001331(d";
option agent.circuit-id 0:5:8:b9:1:0:29;
}
The lease record 100.79.223.152 is requested by the PXE loader, though rejected by DHCP server.
The lease record 100.79.223.150 is requested by systemd-networkd of
CoreOS. (I can confirm it by running systemctl restart systemd-networkd and watch the leases file)
All seems fine, but the PXE lease record 100.79.223.152 cause other problem (when really PXE boot the machine and deploy another OS to it then it will get the 100.79.223.152 instead of 150, then cause other private problem).
If I install other OS which does not use systemd-networkd, then the reboot only cause 1 lease record.
You can see the lease 100.79.223.150 has a field uid "001010236001331(d", which means let DHCP server allocate IP by the uid (client identifier), currently it is actually same content of mac address, just be printed as octet.
This is the root cause of two IPs.
To prevent this two IP problem, I've tried to set deny duplicates in /etc/dhcp/dhcpd.conf in DHCP server, but nothing changes.
I was wandering that if it is possible to tell systemd-networkd not to send uid (client identifier). According to source of systemd, it is intentionally implemented to "always send client identifier",
given such condition, how can I prevent systemd-networkd from sending client identifier?
EDIT 2019/02/17: I found that I misunderstood the meaning of deny duplicates, it does not help this problem.
I remembered I had ever tested another option first but not works.
ignore-client-uids on;
The ignore-client-uids statement
ignore-client-uids flag;
If the ignore-client-uids statement is present and has a value of true
or on, the UID for clients will not be recorded. If this statement is
not present or has a value of false or off, then client UIDs will be
recorded.
https://www.isc.org/wp-content/uploads/2017/08/dhcp43.html
The DHCP server version is isc-dhcpd-4.2.4
EDIT 2019-03-12: I had some mistaken and found something, so answered this question myself. Simple answer is ignore-client-uids true; on server side works well, ClientIdentifier=mac on client side does not work well.
Have you tried setting the client identifier to (empty)?
$ cat /etc/systemd/network/zz-default.network
[Network]
DHCP=yes
[DHCP]
ClientIdentifier=
UseMTU=true
UseDomains=true
After many times of experiments, I found that only ignore-client-uids true; works constantly, all mystery disappeared., when you set it, you can confirm that no uid "....." appear in /var/lib/dhcp/dhcpd.leases` file, the server completely ignore the client identifier sent from client and just use MAC to determine how to allocate IP.
If you insist on using ClientIdentifier=mac, you can take a look at what I found:
specifying ClientIdentifier=mac (on client *.network) does let me get same IP as before. The reason why I said it does not work is probably because I have another NIC which also enabled DHCP by default hence caused a new IP.
/lib/systemd/network/zz-default.network
[Network]
DHCP=yes
[DHCP]
UseMTU=true
UseDomains=true
After I change above file to
[Network]
DHCP=no
I got only 1 and same IP as before.
The client identifier will be a string "\0x1" + MAC, you can confirm it grep uid "..." in /var/lib/dhcp/dhcpd.leasesfile, e.g.,uid "001304TDD210272"`, for any non-printable char it will be encoded as 3 digits Octal such as 304. Some client automatically generate an client identifier like this "\0x1" + "MAAS" + MAC ...
The most unfortunate thing is: once a client send client identifier, for the same MAC, if the client send anther request WITHOUT client identifier, it will get new IP.
Considering DDNS, for same MAC, the DHCP request with and without client identifier are treated as different client when DHCP server composing DNS update request for it. Simply speaking,
for DHCP request without client identifier -> server send DDNS request with a hash of the MAC -> DNS server: OK
for DHCP request with client identifier -> server send DDNS request with a hash of the client identifier -> DNS server: rejected due to the hash is not same, for security.
That is all I found, hope it helpful.
You can also check if there is configuration under the /run/.../systemd/network/*.network, I had the same issue because of netplan putting a configuration network file in the /run which is applied instead of the etc or lib one.
The solution in this case is to add the dhcp-identifier: mac in the the netplan yml configuration
Is it possible to route dns to different servers based on the protocol of the request without using a proxy server?
For example wss://example.com goes to 1 server and https://example.com goes to a different one.
In principle no, this is not possible. Although there are exceptions.
When you an application and request a network address, e.g. example.com the application will (typically) pass on a request to the OS to open a connection to that address.
Because the OS can only make a connection to an IP Address, the first thing it does is to make a DNS request to find out the address it can connect to. There is no mechanism at all, to tell that DNS request what protocol is being requested. At the point the OS makes the DNS request it is simply, 'What is the address for example.com' there is no space in the body of the message for more information.
In that sense it is not possible.
However there are a few services that use SRV records to find the server they need to connect to.
In these cases the application will say to the OS 'get me the SRV record for _somefancyservice.example.com' When it has that record, it will then send another request to the OS to open a connection the whatever it found in the SRV record.
So you could, in theory, write an application that performed the SRV record query first, and then opened a connection to whatever was returned.
I wrote a more detailed answer specifically about wss, which you may find interesting.