Welcome to my world
/etc/init.d/postgresql92 rebuild /etc/init.d/postgresql92 start
When ssh into a server I want to start directly tmux or use an existing session.
ssh example.local -t "tmux a || tmux"
While trying to connect to an older esxi server I got the error message Unable to negotiate with 1.2.3.4 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss
I was wondering.
The solution $EDITOR ~/.ssh/config
Host 1.2.3.4
User root
HostKeyAlgorithms=+ssh-dss
How to do things with iptables. Safety first: How to reset everything.
sudo iptables -F sudo iptables -X sudo iptables -t nat -F sudo iptables -t nat -X sudo iptables -t mangle -F sudo iptables -t mangle -X
sudo iptables -A INPUT -p tcp -s localhost --dport 3306 -j ACCEPT #mysql allow local sudo iptables -A INPUT -p tcp --dport 3306 -j REJECT --reject-with tcp-reset #mysql
The “REJECT –reject-with tcp-reset” looks to the outside like there is no service running. A “DROP” will show that there is a firewall / iptables working.
Blocking an IP range
sudo iptables -A bannedDownloader -s 14.120.0.0/16 -j DROP
Disallow NTP queries
sudo iptables -A INPUT -p udp -s localhost --dport 123 -j ACCEPT #ntp allow local sudo iptables -I INPUT -p udp --dport 123 -j REJECT #ntp
Block timestamp
sudo iptables -I INPUT 1 -p ICMP --icmp-type timestamp-request -j DROP sudo iptables -I INPUT 1 -p ICMP --icmp-type timestamp-reply -j DROP sudo iptables -A INPUT -p icmp --icmp-type 13 -j DROP
This is more for me than others. Sometimes I forget things like this.
ssh -D 8888 mario@example.com Browser: Socks Proxy localhost 888
ssh -L 9090:localhost:9090 user@proxyhost -i SSHKEY ssh -L 9090:localhost:9090 -N user@TARGETSYSTEM
A feature of the apache webserver is that it allows to to create a SSH connection through a transparent proxy / firewall. This is a stealth technic so no one will see it even in a large company network. Only IPoAC is able to interference this.
If you have internet access to port 80 (http) or 443 (https) you can establish a SSH connection to one of that ports. Proxys want the users to surf the web. most of the proxyes will only let their users through the paths they know safe (or whatever filtering their administrators may have set). In the best scenario, the proxy will not allow one particular HTTP method called CONNECT. This method is the one used for SSL / TLS protocol. It establishes a tunneled connection between the client and a remote server, through the proxy server. Since it is used by SSL / TLS, some proxys will let the CONNECT method free to certain sites, and most probably only on port 443.
Apache plus mod_proxy module will let us set up an HTTP server listening on port 80, and at the very same time an HTTP proxy. The proxying part is done by mod_proxy. This module turns Apache into a fully functional HTTP forward-proxy and reverse-proxy. the exciting feature of mod_proxy is its ability to handle the CONNECT method. It will even handle it if the transparent proxy, at the boundaries of our enterprise network, does not allow the CONNECT method. This, because we will talk GET and POST with Apache, the CONNECT thing happens inside Apache, and outside of the control of the enterprise proxy. The end result: we can use the CONNECT method.
Client side
server side
This is an example virtual host configuration which I used for testing this implementation.
<VirtualHost *:80> ServerName proxy.mydomain.com ProxyRequests On AllowCONNECT 22 <Proxy *> Order deny,allow Deny from all </Proxy> <ProxyMatch (host1|host2)\.mydomain\.com> Order deny,allow Deny from all #Now we allow only our IP to access. Note that this IP must be the public IP address of the enterprise proxy: Allow from 222.22.22.100 </ProxyMatch> # This directive enables DNS lookups so that host names can be logged. The value Double refers to doing double reverse DNS lookup. #That is, after a reverse lookup is performed, a forward lookup is then performed on that result. At least one of the IP addresses in the forward lookup must match the original address. It is paranoid but is a good security measure HostnameLookups Double ErrorLog /var/log/apache2/proxy.error.log CustomLog /var/log/apache2/proxy.access.log common </VirtualHost>
And now, the final step: configure our browser to use 127.0.0.1 on port 8080 as proxy. Finally we can login to our SSH server and try pointing our browser to any website we know blocked by the enterprise transparent proxy!
I know I left the part setting up apache and proxy, but this isn’t a tutorial for noobs ;-)
This is the BEST part of using Apache. You can set it up as normal web server, serving some webpage. This way whoever point to mydomain.com will see a normal and harmless website, and won’t be able to distiguish it from a non-proxying server.
Heute Nacht bin ich mal wieder von meinem embedded Linux aufgewacht, wie schon einmal. Nach der letzten Attacke hatte fail2ban installiert, was erstaunlich einfach ging.
sudo apt-get install fail2ban
sudo nano /etc/fail2ban/jail.conf
sudo /etc/init.d/fail2ban restart
Fertig! Das war es schon.
Und dennnoch blinkte die LED unaufhörtlich in der Nacht. Über 100 IP adressen, die gehackt haben bis endlich ruhe war. Alle anderen computer waren ausgeschaltet, so dass die anderen Ports vom Portforwarding beim scan zumindest closed oder filtert anzeigen müssen. So viel Ernergie wegen einem offnen SSH port bei einer IP die sich alle 24 Stunden ändert? Mich wundert, dass der kleine NSLU2 nicht aufgegeben hat bei einem solchen DDOS, immerhin dauert es schon mal 3,5 Stunden um alleine nmap zu compilieren ;-) Naja 266 MHz und 32 MB RAM sind auch nicht gerade viel, aber als Eingang in mein Netzwerk hat es für mich immer gereicht. Fragt sich nur, was ich als nächstes gegen einen solchen Angriff machen kann. Fail2ban scheint da nicht mehr zu reichen. Ideen?
Eigentlich sollte man meinen, dass ein embedded linux leise bis ohne Geräusche arbeitet. So eigentlich auch der Fall bei mir. Ich hatte mir ein NSLU2 gekauft und dann die Firmware mit Debian geflasht, um ein vernünftiges Linux darauf zu haben, nicht die originale Firmware mit all den Einschränkungen. Die Installation hatte anders als im internet angegeben nicht 4 Stunden, sondern ganze 6 Stunden gedauert, trotz einer guten Internetverbindung und obwohl ich den Prozessor auf 266 MHz schon erhöht hatte, mittels Entfernen eines Widerstandes der die CPU nut ausbremst. Keine Ahnug warum Cisco Systems das gemacht hat. Da ich anstelle einer externen Festplatte einen 8 GB Flash USB Stick gewählt habe und der NSLI2 keinen Lüfter besitzt, ist gar nichts zu hören. Absolute Stille selbst bei Vollast.
Wie dem auch sei, heute bin ich mitten in der Nacht davon aufgewacht. Irgent etwas blickte sehr hell in meinem Zimmer. Zu nächst dachte ich es sei eine der Netzwerkkarten von den Computer, die eine Verbindung zum switch haben und wegen WOL immer aktiv sind, auch wenn die PCs ausgeschaltet sind. Das war es aber nicht. Die blaue Diode vom dem USB Stick am NSLU2 blickte unaufhörlich. Normalerweise blinkt die nur ganz selten, denn außer einem SSH server läuft nichts aus dem NSLU2. Ich habe dann das Gerät so gedreht, dass jene Diode nicht in in Richtung meines Bettes leuchtet und habe mich wieder hingelegt.
Heute morgen hat sich dann mein Verdacht bestätigt, warum da so viel Aktivität war. Da hat jemand 8 Stunden lang versucht sich auf dem SSH server einzuhacken. Naja die brute force methode klappt halt nicht, wenn root sich gar nicht einloggen kann und der einizige Benutzer, der sich einloggen kann keinen gewöhnlichen Usernamen hat. Aufgeweckt hat es mich trotzdem und das obwohl kein Mux von sich gibt.